[PATCH 3/5] wined3d: Temporarily remove surface PBO support.

Henri Verbeet hverbeet at gmail.com
Mon Nov 25 11:21:57 CST 2013


On 25 November 2013 17:01, Stefan Dösinger <stefandoesinger at 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.



More information about the wine-devel mailing list