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

Stefan Dösinger stefandoesinger at gmail.com
Mon Nov 25 12:23:40 CST 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2013-11-25 18:21, schrieb Henri Verbeet:
> 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.
The usage hint is gone from GL_ARB_buffer_storage. Do you really think
it matters? Do we have any evidence that suggests that using one PBO
to download and upload data causes problems? Even if it does cause
problems we should check if it causes more problems than using one
surface to download and upload in d3d9.

You know the AMD GPU and r600g driver pretty well. Is there anything
in the hw or driver that suggests that the usage really matters and/or
that using a PBO for PACK_BUFFER and UNPACK_BUFFER causes problems?

> 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.
Most applications that use UpdateSurface / UpdateTexture that I've
worked with in the command Stream development use DISCARD on the
sysmem surface. I'd expect the application to stall on native d3d as
well if it doesn't use DISCARD, but it is difficult to test.

The exception here are intro videos. Apps do all sorts of stupid
things, including just using a D3DPOOL_MANAGED texture and calling it
a day. It doesn't really matter because pure video playback doesn't
queue up lots of commands anyway.

The one thing that matters performance-wise is not stalling the
pipeline on map. I have not seen a single application that uses
D3DPOOL_DEFAULT D3DUSAGE_DYNAMIC textures with DISCARD, except for one
case of intro video playback. Not sure which game this was, I'd have
to re-check them all. Even the applications that use UpdateSurface /
UpdateTexture in real rendering don't stream a lot of data compared to
the use of dynamic buffers, usually it's a texture update every other
frame.

According to my testing, the only applications that profit from
PBOs(in their current state, and in my cs tree) are Warcraft 3 and
UT2004. They abuse backbuffer->map(READONLY) as a glFinish
replacement, and loading the data into a PBO instead of sysmem gives
them a ~10% performance boost.

> 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.
I plan to add a BO pool to the command stream patches to handle
DISCARD, but I think that's only partially related to what you've
considered.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSk5WsAAoJEN0/YqbEcdMwr7AP+QGOK7WWNbe07foHaa1G4GPq
2EWpJUnLbxVySZISO70gIrbrE8LPlJf5gQpi1b8UdyUrYTIkp9AFiSpcQYKTtwLE
RO4SmwDA3h2OfSbAdjFiVFeZQ1C2oBBdxq1sGx/s9cZcgtXZ/dcaOkyxeEAqkJT2
KhPt4Aaoibv4i3kUXhhBo7x87Rl4qqFRPxe8XLFvkTXJ2OpibyQEV9pYkxmvSkjY
BrtV1b3Nt3WXRoSfKsgqWUBx+QlxRVNhO3BaTq6tXvdVq5sF+Mr9gS5hIeyPnkC1
H2UQv79bYybGVlupcCvZV6mxaEVig+krlIGxTyge90wPWuxqwNWJzyl03Jg2dqpk
/5uIZyuj877yciNnOY8NhU/5vBIFESZrNH4zWcV6n1TB6Jc2pkGlfw20uj8Zs5Ei
BkRMD3EuLhoTL6zG6k+Etmzwrex2qielEM7GNBGlbxxeLEJ+otCQkTTCeItTk62w
yRtoIWZTp76a0N82XHKXHVl2C99Wxxr4N5lfu7XJeqJ6SPPxi/XRz0Q9o/l1kPQC
98Buc1FYQtR19go3ogETlKCIp7hB6FXzzIgebdPcoG0YBV+11dIiCzT1gAu5r9BO
3mE53y3NiEl5TAzeuEdPZOiPtKBVTj3QmV6texOTE/hU/lJyKal3FqqZTHXT0QCD
TKlJhfAzO1tGEptUf9GQ
=G+/U
-----END PGP SIGNATURE-----



More information about the wine-devel mailing list