I have a simple 2D game that renders with SDL+MiniGL (Sam440ep + M9 Radeon).
Game is playable on both 16/32-bit custom screen, or 16-bit WB screen, but if I change my WB to 32-bit mode with compositing effects, frame rate drops from playable to ~2. With no compositing enabled, performance is ok.
I have debugged that the bitmaps given to MiniGL are always same format as the destination bitmap. So, in 32-bit case format is 6 and in 16-bit case format is 10.
As far as I can see, I have still plenty of VRAM still left (~30MB). Is there something that I could do on application or SDL(2) side to improve performance?
For the reference, here is SwapWindow code:
https://sourceforge.net/p/sdl2-amigaos4 ... ngl.c#l335
Same problem happened also with SDL1. http://amigaworld.net/modules/newbb/vie ... m=9#730146
EDIT: changed title
Silly things kill SDL/MiniGL performance on the WB screen
Silly things kill SDL/MiniGL performance on the WB screen
Last edited by capehill on Mon Aug 28, 2017 8:08 pm, edited 1 time in total.
Re: Compositing kills SDL/MiniGL performance on the WB scree
I am very interested in a solution as that also seems to be the affecting reason why some engines/games in ScummVM are awfully slow.
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Re: Compositing kills SDL/MiniGL performance on the WB scree
I don't see how your issue will get any attention from anyone unless you provide a link to a game that canRaziel wrote:I am very interested in a solution as that also seems to be the affecting reason why some engines/games in ScummVM are awfully slow.
be tested to confirm the problem you describe.
AmigaOne X1000 with 2GB memory - OS4.1 FE
Re: Compositing kills SDL/MiniGL performance on the WB scree
I stopped bothering doing extra work just to get a confirmation or rejection, too much hassle as the persons in charge tend to simply ignore me...(not talking about you obviously)
I'll watch this space and draw my own conclusions
I'll watch this space and draw my own conclusions
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
- broadblues
- AmigaOS Core Developer
- Posts: 600
- Joined: Sat Jun 18, 2011 2:40 am
- Location: Portsmouth, UK
- Contact:
Re: Compositing kills SDL/MiniGL performance on the WB scree
What screen resolution? Compositing effects are limited by max texture size and there may not be much head room between the screen size and the texture size, and so if window bitmaps are max screen size that might cause slow downs if the bitmaps round up to a larger than texture size. On a SAM Flex with R9250 this will happen if using FullHD, might happen earlier on a plain 440ep ?capehill wrote:I have a simple 2D game that renders with SDL+MiniGL (Sam440ep + M9 Radeon).
Game is playable on both 16/32-bit custom screen, or 16-bit WB screen, but if I change my WB to 32-bit mode with compositing effects, frame rate drops from playable to ~2. With no compositing enabled, performance is ok.
How fast does blender run? I ask as that takes the SDL part out of the eqation amd blender shows no slow down on my SAM-Flex
Does this issue only occur on a 440ep M9 combination?
I wouldn't call 30Mb plenty, more like just enoughAs far as I can see, I have still plenty of VRAM still left (~30MB). Is there something that I could do on application or SDL(2) side to improve performance?
- Hans
- AmigaOS Core Developer
- Posts: 703
- Joined: Tue Dec 21, 2010 9:25 pm
- Location: New Zealand
- Contact:
Re: Compositing kills SDL/MiniGL performance on the WB scree
Decided to check in on this forum for the first time in months...
Remember that the ~30 MB free space includes space freed up by bitmaps/textures temporarily paged out. A 32-bit 1920x1080 bitmap alone is already ~8 MB (or 12.5% of 64MB, and 27% of 30MB)).
@capehill
Try lowering your screen resolution first to see if the frame-rate jumps back up. Game-wise, you could try reducing the size of your textures, using 16-bit instead of 32-bit textures, using compressed textures or some combination thereof.
NOTE: Texture compression is available on old Radeons only, so a fallback is needed for Radeon HD users.
Hans
Max compositing size is limited by the hardware's max texture size (2048x2048 on old Radeons). The frame-rate drop sounds a lot like the machine is running out of VRAM. This happens very easily with compositing enabled and graphics cards with smaller amounts of VRAM (like the Sam 440ep).broadblues wrote:What screen resolution? Compositing effects are limited by max texture size and there may not be much head room between the screen size and the texture size, and so if window bitmaps are max screen size that might cause slow downs if the bitmaps round up to a larger than texture size. On a SAM Flex with R9250 this will happen if using FullHD, might happen earlier on a plain 440ep ?capehill wrote:I have a simple 2D game that renders with SDL+MiniGL (Sam440ep + M9 Radeon).
Game is playable on both 16/32-bit custom screen, or 16-bit WB screen, but if I change my WB to 32-bit mode with compositing effects, frame rate drops from playable to ~2. With no compositing enabled, performance is ok.
It also depends on how fragmented the remaining 30 MB is. Warp3D allocates VRAM in large blocks. If there's block of free space large enough for the allocation, then it'll still fail and defragging and paging will occur. This means copying bitmaps to/from RAM, which is slow. Picasso96 is pretty brain-dead about choosing which bitmaps to page out, so it can page out something that will be needed again soon, causing thrashing which slows things down even more.broadblues wrote:I wouldn't call 30Mb plenty, more like just enoughcapehill wrote: As far as I can see, I have still plenty of VRAM still left (~30MB). Is there something that I could do on application or SDL(2) side to improve performance?
Remember that the ~30 MB free space includes space freed up by bitmaps/textures temporarily paged out. A 32-bit 1920x1080 bitmap alone is already ~8 MB (or 12.5% of 64MB, and 27% of 30MB)).
@capehill
Try lowering your screen resolution first to see if the frame-rate jumps back up. Game-wise, you could try reducing the size of your textures, using 16-bit instead of 32-bit textures, using compressed textures or some combination thereof.
NOTE: Texture compression is available on old Radeons only, so a fallback is needed for Radeon HD users.
Hans
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
Re: Compositing kills SDL/MiniGL performance on the WB scree
Textures used by the game are quite small, 2 are 500 KB and one is 1000 KB. I could try 16-bit versions of course.
Can I somehow get some statistics from VRAM usage (fragmentation, paging)?
If graphics.library still uses an ancient pager, should there be a ticket for improving it?
Can I somehow get some statistics from VRAM usage (fragmentation, paging)?
If graphics.library still uses an ancient pager, should there be a ticket for improving it?
Re: Compositing kills SDL/MiniGL performance on the WB scree
...or finally support the whole gfx ram available on a gfx card, instead of only 128 MB...
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Re: Compositing kills SDL/MiniGL performance on the WB scree
I changed the WB screen to 640*480*32bit mode and game is still way too slow (like 3 FPS), when compositing is enabled. I will try to implement 16-bit textures next.
Checked also the monitor icon and interrupts are enabled. That's INTERRUPTS=Yes, right?
Checked also the monitor icon and interrupts are enabled. That's INTERRUPTS=Yes, right?
- Hans
- AmigaOS Core Developer
- Posts: 703
- Joined: Tue Dec 21, 2010 9:25 pm
- Location: New Zealand
- Contact:
Re: Compositing kills SDL/MiniGL performance on the WB scree
I'm afraid not.capehill wrote:Textures used by the game are quite small, 2 are 500 KB and one is 1000 KB. I could try 16-bit versions of course.
Can I somehow get some statistics from VRAM usage (fragmentation, paging)?
IIRC, one already exists.capehill wrote:If graphics.library still uses an ancient pager, should there be a ticket for improving it?
Yes, interrupts are enabled.capehill wrote:I changed the WB screen to 640*480*32bit mode and game is still way too slow (like 3 FPS), when compositing is enabled. I will try to implement 16-bit textures next.
Checked also the monitor icon and interrupts are enabled. That's INTERRUPTS=Yes, right?
How much free VRAM do you have when the screen resolution is dropped to 640x480? With that little space taken up with textures, perhaps something else is going on. I wonder what, though, because I'm pretty sure that there's SDL based OpenGL games/software that work just fine with compositing enabled. IIRC, Neverball is SDL based...
We'll get there eventually, although that won't help users of older Radeon cards (and the Radeon M9) that genuinely have less than 256 MiB.Raziel wrote:...or finally support the whole gfx ram available on a gfx card, instead of only 128 MB...
Hans
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.