Tissuegl

[crow_riot]

as said in the lemonboy news thread, i'd work out a proof of concept lib using opengl, that creates a virtual framebuffer for 2d drawing to avoid tearing.
the good thing - it works.
the bad thing - the performance. it's awfully slow, i only get around 40fps

i can only think about one optimization atm, but that only works with deeper knowledge of the pollux hardware (manual!): the texture is created in user memory atm, then uploaded by glTexSubImage2D. if there is a way to directly write into the memory that GL uses for it's texture, the whole glTexSubImage2D can be avoided.

source is here: http://crow.riot.org/wiz/tissueGL-src.tgz
i'm using codeblocks for lazyness, so there's no makefile...

test binary is here: http://crow.riot.org/wiz/tissueGL-bin.tgz
it clears the screen to a light gray and draws a moving rectangle which bounces off the boundaries. be aware that you need to have libopengles installed, and that i'm using firmware 1.1.0 ... exit with menu button...

anyway, maybe it's useful for someone - if not, i had some nice time implementing it

 

[trentg]

Writing to texture memory is made possible in gl with extensions like FBOs and Pbuffers. The libopengles_lite.so on Wiz exports some symbols for manipulating and creating Pbuffers. Unfortunately I haven't been able to get them to actually work... If anybody has had success with pbuffers on the wiz please tell us how! Or if the implementation is just broken, GPH, please fix (or get magiceyes to fix it, as IIRC it's their lib), this is a MUST HAVE to make opengl at all useful these days.

 

[sbock]

I'm not quite sure if this is of any use but the libopengl_lite.so we use seem to be older than the one delivered with the GPH firmware.
Unfortuneatly non of the hombrew programs work with the new lib. But the upcomming commercial game "Propis" only works with the "new" version of libopengl_lite. So something must be different with this lib. I don't know if it's really improved or if there're only minior changes...



http://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,0,0,0,23,132

 

[crow_riot]

i've got the propis lib installed on my wiz, for developing the 3d engine and this stuff, it works fine. the stuff trentg mentions (offscreen rendering) don't work with that either. so that's still a matter of investigation how to get that working.

 

[sbock]

That's really interesting. Do you have a clue what is different with this version? Is the performance better (or worser)? And what may be the reason most of the hombrew applications don't run with this lib? (e.g. Pickle's demos, GLQuake etc.)

 

[trentg]

wizGLES seems to date back to before the new lib, and those apps use it. The new lib has an extra undefined function which was not implemented in wizGLES. A little disassembly was needed to figure out what it was supposed to do. I think I discussed it with Pickle but I'm not sure whether he added the function to wizGLES yet or not.

 

[Pickle]

wizGLES seems to date back to before the new lib, and those apps use it. The new lib has an extra undefined function which was not implemented in wizGLES. A little disassembly was needed to figure out what it was supposed to do. I think I discussed it with Pickle but I'm not sure whether he added the function to wizGLES yet or not.

Latest version/source should be here http://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,0,0,0,46,188

 

[trentg]

Yeah, that has the GetDisplayDirection function in wizGLES, so if the programs compiled with older versions of wizGLES were recompiled with the new code, then everything could use the new libopengles_lite.so. I'm still not satisfied with it though... I'm hopeful that there will be another release of the opengl lib with working pbuffers or fbos. I sound like a broken record but that's important to me if I'm going to keep using opengl on wiz.

 

[crow_riot]

(back on topic ) i'll continue working on the tearing fix. i had one idea to make direct access available: i'd create a special footprint texture, upload it as a whole using the given gl functionality and then scan the memory for the footprint. seems easy.

questions for linux gurus here:
would this be safe?
and what memory region is used by the 3d hardware to store the textures in?

*edit reformatted*

 

[crow_riot]

gave this a try yesterday. direct memory access works as i expected it (i love mmap! )

but: i realized that the memory layout of the textures is not linear but block-wise. each block takes 64x32 bytes. don't have in mind how many blocks are per line right now (google "parallel texture caching" for reasonable explanations why so).
when uploading a texture (linear in memory), this needs to be converted into that block structure, which obviously drastically reduces performance.

so there are some things left to try

• directly draw into texmem using a LUT to convert x/y to block-x-y
• 'invent' some faster method to copy the linear framebuffer to the block texture memory

 

[Exophase]

gave this a try yesterday. direct memory access works as i expected it (i love mmap! )

but: i realized that the memory layout of the textures is not linear but block-wise. each block takes 64x32 bytes. don't have in mind how many blocks are per line right now (google "parallel texture caching" for reasonable explanations why so).
when uploading a texture (linear in memory), this needs to be converted into that block structure, which obviously drastically reduces performance.

so there are some things left to try

• directly draw into texmem using a LUT to convert x/y to block-x-y
• 'invent' some faster method to copy the linear framebuffer to the block texture memory

As far as I understand it Pollux actually has both a linear and a swizzled memory map for its texture space. It should be possible to use this to get a linear view of the texture. I suggest you scan the address space more if you haven't exhausted it yet.

Using a LUT on your draws wouldn't make much sense if you're just trying to get around tearing. It'd be faster to apply rotation as you draw.

 

[crow_riot]

gave this a try yesterday. direct memory access works as i expected it (i love mmap! )

• directly draw into texmem using a LUT to convert x/y to block-x-y
• 'invent' some faster method to copy the linear framebuffer to the block texture memory

As far as I understand it Pollux actually has both a linear and a swizzled memory map for its texture space. It should be possible to use this to get a linear view of the texture. I suggest you scan the address space more if you haven't exhausted it yet.

Using a LUT on your draws wouldn't make much sense if you're just trying to get around tearing. It'd be faster to apply rotation as you draw.

thanks for the input.
i was fiddling around some time again, to find my texture in memory. a simple memdump and a hex editor helps a lot sometimes . i was not able to find a linear representation of the texture within the memory used by the 3d entity, but an even more weird memory layout for textures:

• the whole texture (512x256x16bpp) is split up into iirc 3 memory blocks, not contiguous.
• each line is split up into 32 byte pieces
• each piece is then layouted in a 4x8 byte block
• blocks of the same line are sparse, not contiguous, 2 blocks of the same line are are 'near' in memory (see 'code' below)

L(ine), B(lock) as 32 bytes.

+----+----+----+----+----+----+----+----+
+ L0 + L1 + L0 + L1 + L2 + L3 + L2 + L3 +
+ B0 + B0 + B1 + B1 + B0 + B0 + B1 + B1 +
+----+----+----+----+----+----+----+----+

... and so on.

so from my point of view, to get around tearing, there's no sense to (ab)use (GPHs,MES?) opengl implementation to make it fast.

another thing left to try: i use the opengl lib that comes for the propis demo. maybe they got some special implementation driver (why should there else be another one?) that matches their requirements, and check for the texturemem layout created by that one ...


*edit*
found a link explaining the 4x8 layout: http://msdn.microsoft.com/en-us/library/ms792922.aspx

 

[Exophase]

i was not able to find a linear representation of the texture within the memory used by the 3d entity

What address range is this exactly?

EDIT: Looked through docs more, and while you there are address space regions to let you get around the 64x32 arrangement it looks like the 4x8 one is inherent to all textures. Guess we're out of luck afterall.

 

[crow_riot]

i was not able to find a linear representation of the texture within the memory used by the 3d entity

What address range is this exactly?

EDIT: Looked through docs more, and while you there are address space regions to let you get around the 64x32 arrangement it looks like the 4x8 one is inherent to all textures. Guess we're out of luck afterall.

still if you're interested in the address range (just quick copy paste from the GLES init code)

#define	MEM1_PHYS	0x03000000
#define	mem1size	0x00800000
#define	mem1virt	(void*)0xb1000000

#define	MEM2_PHYS	( MEM1_PHYS + mem1size)
#define	mem2size	mem1size
#define	mem2virt	(void*)((unsigned int)mem1virt + mem1size)

it's inside the second memory block.

but sadly, as u already said, i think it's a dead end where we're heading to, trying fast 2d with the 3d entity ...

 

[crow_riot]

quick news ... got a swizzling function that seems to work. needs to be tested on the wiz... if it works i will update the src and binaries

 

[Exophase]

Yeah, it looks like you're right about the swizzling, the 64x32 block part is avoidable through memory map abstraction but the 4x8 block swizzling is totally unavoidable. Shame.

Swizzling textures may be faster (than software) if you want scaling too, but for just rotation for fixing the tearing this isn't going to be an attractive alternative. Unfortunately :/

 

[crow_riot]

Yeah, it looks like you're right about the swizzling, the 64x32 block part is avoidable through memory map abstraction but the 4x8 block swizzling is totally unavoidable. Shame.

Swizzling textures may be faster (than software) if you want scaling too, but for just rotation for fixing the tearing this isn't going to be an attractive alternative. Unfortunately :/

the direct write to texture memory with swizzling is working now. the performance gain is nice, i get around 60fps (i *think* vsync is automatically on?) i'll take a look and try to get it integrated into lemonboy (any help?) to check how it performs in a 'real world environment' to see if it is of any use...

 

[crow_riot]

I've updated the bin and src archives to reflect the recent changes. added drawtext on the sample for FPS display. if anyone test it, would be nice to let me know about performance on other

 

[sbock]

I get 57 fps with my Wiz. I tried both libopengles_lite.so, they work both but no difference in fps output.
But nevertheless thanks for this. At least there is a proof of concept now available. Perhaps there is room for improvement with future versions of libopengles. I read there is a new firmware for the Wiz in the pipeline which should be available "soon" with many fixes for the lib (e.g. adding multi texturing etc.)

What about adding parts of your code to native OpenGL applications like GLQuake? Would this be possible or do you think the performance drop will be similar?

 

[crow_riot]

i've just updated the archives again. i changed the display timings with notaz' pollux_set routines, and now i get about 100hz. so the ~57fps which i also get were merely due to vsync.

*edit*
thanks sbock for trying it out, because it shows it also works on other B)