Silly things kill SDL/MiniGL performance on the WB screen

This forum is for general developer support questions.
capehill
Posts: 24
Joined: Sun Jun 18, 2017 1:07 pm

Silly things kill SDL/MiniGL performance on the WB screen

Post by capehill »

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 :D
Last edited by capehill on Mon Aug 28, 2017 8:08 pm, edited 1 time in total.

User avatar
Raziel
Posts: 966
Joined: Sat Jun 18, 2011 4:00 pm
Location: a dying planet

Re: Compositing kills SDL/MiniGL performance on the WB scree

Post by Raziel »

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

xenic
Posts: 1165
Joined: Sun Jun 19, 2011 12:06 am

Re: Compositing kills SDL/MiniGL performance on the WB scree

Post by xenic »

Raziel 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.
I don't see how your issue will get any attention from anyone unless you provide a link to a game that can
be tested to confirm the problem you describe.
AmigaOne X1000 with 2GB memory - OS4.1 FE

User avatar
Raziel
Posts: 966
Joined: Sat Jun 18, 2011 4:00 pm
Location: a dying planet

Re: Compositing kills SDL/MiniGL performance on the WB scree

Post by Raziel »

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
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

User avatar
broadblues
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 591
Joined: Sat Jun 18, 2011 2:40 am
Location: Portsmouth, UK
Contact:

Re: Compositing kills SDL/MiniGL performance on the WB scree

Post by broadblues »

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.
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 ?

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?

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?
I wouldn't call 30Mb plenty, more like just enough :-)

User avatar
Hans
AmigaOS Core Developer
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

Post by Hans »

Decided to check in on this forum for the first time in months...
broadblues wrote:
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.
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 ?
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:
capehill 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?
I wouldn't call 30Mb plenty, more like just enough :-)
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.

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.

capehill
Posts: 24
Joined: Sun Jun 18, 2017 1:07 pm

Re: Compositing kills SDL/MiniGL performance on the WB scree

Post by capehill »

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?

User avatar
Raziel
Posts: 966
Joined: Sat Jun 18, 2011 4:00 pm
Location: a dying planet

Re: Compositing kills SDL/MiniGL performance on the WB scree

Post by Raziel »

...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

capehill
Posts: 24
Joined: Sun Jun 18, 2017 1:07 pm

Re: Compositing kills SDL/MiniGL performance on the WB scree

Post by capehill »

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?

User avatar
Hans
AmigaOS Core Developer
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

Post by Hans »

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)?
I'm afraid not.
capehill wrote:If graphics.library still uses an ancient pager, should there be a ticket for improving it?
IIRC, one already exists.
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?
Yes, interrupts are enabled.

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...


Raziel wrote:...or finally support the whole gfx ram available on a gfx card, instead of only 128 MB...
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.

Hans
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.

Post Reply