On 25 November 2013 17:01, Stefan Dösinger stefandoesinger@gmail.com wrote:
I've attached the current state of the surface patches for reference. Patches 2 and 26 are simpler without PBOs, and I'll have to duplicate patches 27-29, 33, 41 and 50 in surface.c and then delete or move the code in separate patches.
I'd appreciate it if you could take a look at the entire patchset and see if there's anything else you don't like conceptually or if there's another major reordering you want.
Ok, but it may take a while.
I think it's also worth pointing out that the way the volume code uses PBOs isn't a whole lot better than what the surface code does.
How would you prefer PBOs to work?
I haven't quite decided yet. One consideration is that if we want the usage hint to glBufferDataARB() to make sense, we can't necessarily use the same PBO both for downloading and uploading data. Another is essentially the various variants of d3d10's UpdateSubResource(), and d3d9's GetRenderTargetData() / GetFrontBufferData(). We'd obviously like to avoid stalling on those, but it's not clear to me if that's always possible. For example, always creating PBO's for sysmem surfaces and then uploading from there probably isn't going to work very well if the application just creates a single sysmem surface and uses that for updating different default pool surfaces with UpdateSurface(), unless perhaps it also uses DISCARD on the sysmem surface. Perhaps that's ok, but I don't think we really know at this point. At some point I considered a scheme where the device has a pool of PBOs and the resource update function grab one from there when needed. That probably has its own problems, but I haven't thought it all the way through either.