Silly things kill SDL/MiniGL performance on the WB screen

This forum is for general developer support questions.

Silly things kill SDL/MiniGL performance on the WB screen

Postby capehill » Sat Aug 19, 2017 4:51 pm

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 9:08 pm, edited 1 time in total.
capehill
 
Posts: 17
Joined: Sun Jun 18, 2017 2:07 pm

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

Postby Raziel » Sat Aug 26, 2017 5:23 pm

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.
If slaughterhouses had glass walls, everyone would be a vegetarian. ~ Sir Paul McCartney
-
Did everything just taste purple for a second? ~ Philip J. Fry
-
Ain't got no cash, ain't got no style, ladies vomit when I smile. ~ Dr. John Zoidberg
User avatar
Raziel
 
Posts: 753
Joined: Sat Jun 18, 2011 5:00 pm
Location: A haunted Castle somewhere in the Bavarian Mountains

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

Postby xenic » Sat Aug 26, 2017 6:24 pm

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
xenic
 
Posts: 1018
Joined: Sun Jun 19, 2011 1:06 am

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

Postby Raziel » Sat Aug 26, 2017 8:51 pm

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
If slaughterhouses had glass walls, everyone would be a vegetarian. ~ Sir Paul McCartney
-
Did everything just taste purple for a second? ~ Philip J. Fry
-
Ain't got no cash, ain't got no style, ladies vomit when I smile. ~ Dr. John Zoidberg
User avatar
Raziel
 
Posts: 753
Joined: Sat Jun 18, 2011 5:00 pm
Location: A haunted Castle somewhere in the Bavarian Mountains

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

Postby broadblues » Sat Aug 26, 2017 9:48 pm

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
broadblues
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 461
Joined: Sat Jun 18, 2011 3:40 am
Location: Portsmouth, UK

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

Postby Hans » Sun Aug 27, 2017 1:26 am

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.
User avatar
Hans
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 703
Joined: Tue Dec 21, 2010 10:25 pm
Location: New Zealand

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

Postby capehill » Sun Aug 27, 2017 2:30 pm

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?
capehill
 
Posts: 17
Joined: Sun Jun 18, 2017 2:07 pm

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

Postby Raziel » Sun Aug 27, 2017 8:00 pm

...or finally support the whole gfx ram available on a gfx card, instead of only 128 MB...
If slaughterhouses had glass walls, everyone would be a vegetarian. ~ Sir Paul McCartney
-
Did everything just taste purple for a second? ~ Philip J. Fry
-
Ain't got no cash, ain't got no style, ladies vomit when I smile. ~ Dr. John Zoidberg
User avatar
Raziel
 
Posts: 753
Joined: Sat Jun 18, 2011 5:00 pm
Location: A haunted Castle somewhere in the Bavarian Mountains

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

Postby capehill » Sun Aug 27, 2017 8:28 pm

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?
capehill
 
Posts: 17
Joined: Sun Jun 18, 2017 2:07 pm

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

Postby Hans » Mon Aug 28, 2017 5:07 am

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.
User avatar
Hans
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 703
Joined: Tue Dec 21, 2010 10:25 pm
Location: New Zealand

Next

Return to General Developer Support

Who is online

Users browsing this forum: No registered users and 3 guests