It is currently Mon Apr 24, 2017 8:17 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Thu Mar 02, 2017 12:48 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3824
Is this a case of glTexImage2D vs glTexSubImage2D?
There's a huge difference between those two. One is a memory allocation and garbage collection call, and the other one just updates a texture.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Thu Mar 02, 2017 3:28 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 799
Location: Pennsylvania, USA
Dwedit wrote:
Is this a case of glTexImage2D vs glTexSubImage2D?
There's a huge difference between those two. One is a memory allocation and garbage collection call, and the other one just updates a texture.


I'm actually not sure what is actually going on OpenGL wise, as I'm using LibGDX, which is a thin layer above OpenGL. At a high level, however, I am aware that the bottleneck was because I had been storing 8 textures in the gpu (4 copies of each pattern table, one for each attribute, for background and sprites) and, when drawing the nametable and sprites, it was switching between these textures quite frequently, which is an expensive operation. So I rewrote the code which generates images from the ppu to use just one texture rather than 8...the speed boost was phenomenal, went from 23fps on an old phone of mine to 60fps.


Top
 Profile  
 
PostPosted: Thu Mar 02, 2017 3:44 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18183
Location: NE Indiana, USA (NTSC)
Would it help to use a pixel shader for palette lookup so that you don't have to store eight copies of the pattern table in memory at once?


Top
 Profile  
 
PostPosted: Thu Mar 02, 2017 4:24 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 799
Location: Pennsylvania, USA
tepples wrote:
Would it help to use a pixel shader for palette lookup so that you don't have to store eight copies of the pattern table in memory at once?


I actually do use a fragment shader to interpret the textures I'm generating, which does perform a palette lookup on a texture that is 32 pixels wide by 1 pixel tall. I actually encode the pixel value, attribute, and bg or spr in the rgb values of the actual textures. Without the shader turned on, everything looks sickly greenish/red/blue hues, haha.

I've been trying to think of a way to delegate all of the ppu decoding to the shader since that is performed in parallel on the gpu for each pixel (afaik), however the bandwidth needed for uploading 8k to the gpu every frame, though small, might be prohibitive? I'm not sure. #longtermgoals. It'd be neat if I could get that to work though, because then suddenly live CHR-RAM updates would be possible. Right now, I can only support it during transitions.


Top
 Profile  
 
PostPosted: Thu Mar 02, 2017 10:58 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3824
Just peeking around... What are you actually doing to draw stuff?

https://github.com/libgdx/libgdx/blob/m ... xture.java
In that file, function GLTexture::uploadImageData, I see only calls to texImage2D, nothing to subimage.

https://github.com/libgdx/libgdx/blob/m ... xture.java
But in Texture::draw, it does call texSubImage2D.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Fri Mar 03, 2017 6:58 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 799
Location: Pennsylvania, USA
The PPU graphics data is generated pixel by pixel into a LibGDX Pixmap (only on startup for CHR-ROM based games, or during transitions when graphics are off for CHR-RAM games...live updates not supported), which is converted into a Texture, which then is converted into TextureRegions (one for each chr tile of each pattern table/attribute combination for bg and spr). Finally, Sprite objects are created from TextureRegions. I don't know what's going on at a lower level than this (never did OpenGL before, so I'd probably not easily understand what the library's doing)---just that if I were to use multiple Textures from which to derive TextureRegions/Sprites, if I'm not careful with how many times I switch between using those Textures it slows down drawing a lot. I actually was able to obtain a temporary speed up by sorting drawing by attribute so the 8 textures I had previously been generating would only get switched to once, each. Having rewritten this so only 1 master texture is used, I don't have to do this sorting anymore so it both gets me the speedup and keeps the code simple.


Top
 Profile  
 
PostPosted: Fri Mar 03, 2017 7:40 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 799
Location: Pennsylvania, USA
On a related topic to the OP...

Premature optimization truly is the root of all evil. For most of the duration of this project, I had been executing the cpu on a background thread. Apparently on Android devices this is a bad idea. Just for the hell of it, I experimented with synchronously advancing the cpu in the render thread. Now games which were performing decently but with a lot of stuttering are now very close to being buttery smooth even on my oldest phone.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group