Talk:GLdc

Note about "fast_path"

so heres the story of "fast_path". its not something i wrote, its not "new" its more just an idea that has minor code in multiple places that forms together to create performant vert submission the pvr has many formats it natively "knows" and can consume and ONLY those. these are expressly laid out in DCDBSysArc990907e.pdf on page 186. in short though, most commonly used for most things 3D is polygon type 3

you get: 3d coordinates, texturing, color and some other minor control flags. very versatile and only 32 bytes per vert (so 3x4 bytes for position + 2x4 bytes for UV is 20 bytes + 1x4 Bytes for vertex colors = 24 bytes, 10 bytes "wasted") kgl, GLdc, glx, etc... generally all use this format in the end for final vertex submission to pvr (because you need to choose one, and this one is great). the idea of "fast_path" is since we are touching our 3d data anyways and then building "some" format, why not go directly to the format we need in the end? Then GLdc has code in it to determine fairly well when you are submitting something that is polygon type 3 aka pvr_vert_t aka glvert_fast_t, and instead of touching the data at all, it just immediately store queue copies it to final buffer to await submission. on other platforms, it basically just looks like an interleaved (but strided) array of data which also works fairly well. --Neo (talk) 13:34, 28 January 2020 (CST)