Uploading Textures onto 2700G (X50v)

[drgoldie]

hi all,

i need to display a video background in 3D mode (OpenGL ES) on the X50v.

i found out that uploading textures with glTexSubImage2D() is *VERY* slow. using glTexImage2D() is faster and limits me to power-of-two images which i could live with.

uploading one texture image of 256x256 every frame results in a framerate of 21fps which is not that much considering that nothing besides rendering one quad is done (rendering that quad without uploading is really fast, ~250fps).

currently i'm using

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, imgWidth,imgHeight, 0, GL_RGB, GL_UNSIGNED_SHORT_5_6_5, nImage->getPixels());

for uploading the texture image. does anybody know if this is the ideal pixel format for the 2700G or if another format gives more performance?

something completely different: since i just need to fill the video memory wondered if it was possible to somehow directly access it. i know that there is no glWritePixels in ES but maybe there is some other device specific method...

thanks a lot,
Daniel

[Mr X]

Check this thread here http://www.aximsite.com/boards/showthread.php?t=64704
and maybe talk to Tala about how he did it.

[hm]

Check this thread here http://www.aximsite.com/boards/showthread.php?t=64704
and maybe talk to Tala about how he did it.

Doesn't the 2700G have a dedicated video api? I don't know if it works in conjunction with ogles, though.

- hm

[drgoldie]

Doesn't the 2700G have a dedicated video api? I don't know if it works in conjunction with ogles, though.

i don't require video decoding. all i need is showing the current content of a camera in the background. so the images are already decoded and in RGB565.

seems as if Tala found a way to directly access video memory and also found out how the 2700G aranges its texture memory. while i would prefer a portable solution it's fine for me to do it like that for now...

Daniel

[drgoldie]

i just found this very interesting documentation:
http://msdn.microsoft.com/library/en-us ... reness.asp

the last section (GAPI Legacy Support) explains how to directly access video memory (bypassing GAPI). the sourcecode of PocketSNES (http://leggnet.com/emulamer) shows how to use it properly.

this does not tell me yet how to directly access the texture memory (i'm missing information on how it is aranged and which internal format it uses) but since Tala managed to implement it, this obviously means that one can directly write into OpenGL ES's graphics memory without interfering with rendering.

i still think it's a shame that Tala's code is 7x faster than the default glTexImage2D() function. what did they do wrong?

Daniel

[torus]

i still think it's a shame that Tala's code is 7x faster than the default glTexImage2D() function. what did they do wrong?

SCNR...

They probably looks somewhat like this:

Code: Select all

1  2  3  4  5  6	for (int x=0; x<widht; x++) for (int y=0; y<height; y++) {   RGBQUAD color = GetPixel (data, x, y);   PutPixel (texture, x,y,color); }
	6 lines; 4 keywds; 2 nums; 30 ops; 0 strs; 0 coms    Syntactic Coloring v0.4 - Dan East

[Digby]

The texture loader may be swizzling the data so that it's stored internally in a different format (usually done to be more cache-friendly when texel fetching). For texture maps this isn't such a big deal, but for an application such as yours which is changing the texture contents per-frame it could kill your performance.

Also, from knowledge gleened from my Dreamcast days, the tile-based rendering hardware such as the MBX-Lite does not like you changing textures per-frame, as that causes a flush (and stall) of the CPU waiting on (the normally asynchronous operation of the graphics chip) to finish. You might consider "double-buffering" your textures and alternate between them every other frame. This allows the hardware to continue to render using the current texture, while you're updating the other texture to be used in the following frame.

Rather than make wild guesses as how to access texture memory directly, you really should contact the PowerVR Developer Relations folks and ask them what would be the best way to update textures quickly. I've found them to be a very helpful bunch.

[drgoldie]

alternating the textures did not change a thing.

Daniel

[Tala]

@Daniel : You have mail

In short, the 2700Gs memory is available for read and write access mapped into virtual user space at the address GET_RAW_FRAMEBUFFER returns. This includes all device registers.
As digby correctly noted, the textures get swizzled for better cache behaviour. If you find your texture in memory you can directly modify it. I implemented a simplified Boyer-Moore algorithm for the pattern search.

this obviously means that one can directly write into OpenGL ES's graphics memory without interfering with rendering.

The problem might be, that it is hard to tell, when it will be safe to update the texture, since OpenGL is inherently asynchronous. Not that it crashes or so, but you will get some tearing like effect, when updating while it is drawing. A safe bet is a framerate of around 30fps, otherwise you might consider double buffering the textures.

Tala

[greenfrog]

Does someone wrote a question about the slowdown in the glTexSubImage2D to Intel or the PowerVR-Guys? it is very unusual of such a big difference, because glTexSubImage2D should only write a buffer to the displayMemory...

or am i wrong?

[drgoldie]

i contacted them and they seemed quite interested but never replied further more.

btw: i changed my code to use 32-bit write access when pushing the texture data into video memory which gave another boost of rougly 2.5 times (seems as if the video memory is uncached). consequently for the case of uploading only a sub-image my code is (very) roughly 20x faster than the original opengl routine.

bye,
DANIEL

[Mr X]

is code available :) ?

[drgoldie]

hmm, to be honest the code is quite a mess (and only works for square textures). i did not plan to publish it.

in fact Tala did most of the work by finding out the recursive manner in which the pixels are stored...

Daniel

[clintsinger]

Hi Tala,

Any chance you are willing to share an example of what you did? It seems like a fascinating technique. I understand from your previous post what you did but it would be great to see how you did it.


It seems like you have the best way to change a texture at runtime.

Cheers,
Clint

[mm40]

Did you try glDrawImage? Since its not a texture it won't be swizzling the data and should be as fast as a direct copy, assuming the source data is in the correct format and alignment, and its fully OpenGL compliant.