Display lists

[uberjack]

Has anyone tried using display lists (not GU_DIRECT) for 2D graphics? I'm curious as to how well this works. In my experience, I found out that I couldn't store texture rendering (GU_SPRITE) in a display list; and even with simple GU_LINES or GU_POINTS rendering, every now and then I get palette corruption and the odd artifact. I'm starting to think that it's probably safer to do direct rendering instead (though speed gained by using display lists will be sorely missed)

[a_noob]

Theres nothing wrong with using display lists for 2D ;)

[jean]

Display list in general are just something like an abstraction layer shorcut. I mean: when you issue command to graphic hardware, the CPU has to do a whole lot of conversions to make your commands understandable by "GPU". Once you have a bunch of commands converted, why to do it again each frame?? (moreover: in PCs where GPUs have their own memory, why should you re-upload data every time?) Because of this, lists exist. So the short answer is : if it's not good, it's not bad anyway. Only thing i'm uncertain about this is PSP specific implementation of matrix algebra; i mean: in traditional PC 3D accelerators, you can issue a display list after some transformations (that always take to a single transformation matrix) and have your list transformed as well before getting drawn. Looking in pspGE and PSPGU sources we can see explicit transformations performed by VFPU and not by graphic hardware....so i could't tell at wich point in the pipeline display lists are implemented on PSP...maybe they're only something that mimc real GPU's behaviour to make devs feeling more comfortable with it...but i really don't know

[Raphael]

Looking in pspGE and PSPGU sources we can see explicit transformations performed by VFPU and not by graphic hardware....

You're misunderstanding the "matrix transformations" it seems. The code in pspGL and sceGU only contains methods of creating rotation, translation and scaling matrices and multiplying them together. The transformation of the vectors by those matrices is still done in hardware, so as long as the matrix is set before the call of the display list it works. IIRC you can also just set your matrix inside your list, in which case just the final output matrix will be stored inside the list, so you also save up on all the matrix calculations for each call to the list.

[uberjack]

Display list in general are just something like an abstraction layer shorcut. I mean: when you issue command to graphic hardware, the CPU has to do a whole lot of conversions to make your commands understandable by "GPU". Once you have a bunch of commands converted, why to do it again each frame?? (moreover: in PCs where GPUs have their own memory, why should you re-upload data every time?) Because of this, lists exist. So the short answer is : if it's not good, it's not bad anyway. Only thing i'm uncertain about this is PSP specific implementation of matrix algebra; i mean: in traditional PC 3D accelerators, you can issue a display list after some transformations (that always take to a single transformation matrix) and have your list transformed as well before getting drawn. Looking in pspGE and PSPGU sources we can see explicit transformations performed by VFPU and not by graphic hardware....so i could't tell at wich point in the pipeline display lists are implemented on PSP...maybe they're only something that mimc real GPU's behaviour to make devs feeling more comfortable with it...but i really don't know

In that case, should sceGuDrawArray commands with GU_SPRITES be retained in the display list, or do textures not get stored in the list?

Another question. In OpenGL, we are not required to specify the size of the display list - just a unique constant identifying the list. How is the size of a GU display list computed, and is it possible to determine it before issuing the actual commands?

Thanks

[a_noob]

Ermm Im sure its possible but there is no function for checking, but you can make a guess based on what you have to render.

[jean]

The code in pspGL and sceGU only contains methods of creating rotation, translation and scaling matrices

oh....ok this clarifies me a lot of things....damn my quick drill-downs: i have to be more professional when i think out loud of internals... ;)