[PATCH 01/10] wined3d: Introduce struct wined3d_dirty_regions.

[Stefan Dösinger]

Am 2017-04-19 um 00:33 schrieb Matteo Bruni:
> This got sidetracked quite a bit already and I'm going to make it
> worse. Sorry...
Yeah, apologies to Masanori :-\ . He stung into a hive's nest without
knowing.

> Although now with UAV the SYSMEM location isn't necessarily the most
> up to date for buffers either
That's why I used the past tense: "we only had two locations to deal
with" :-) .

> and if EXT_texture_sRGB_decode is
> supported we only use one TEXTURE location. Anyway, I agree that with
> textures it can generally get more complicated.
Yup. Except that you still have to find a way not to break rendering
without render-to-fbo (When drawable != texture) or no sRGB_decode (when
texture_srgb != texture_rgb). You can do it by just disabling partial maps.

> Maybe that's already too flexible. I'd start by only "cloning" the
> SYSMEM -> BUFFER uploading mechanism from buffers (but for SYSMEM ->
> TEXTURE) and see where we stand at that point. Yes, it's not
> particularly generic / orthogonal / nice but it probably is the most
> important case we care about fast partial texture updates.
Well, I think sysmem <-> texture and buffer <-> texture are about
equally important (managed textures, dynamic default textures, to think
in d3d9 terms). We don't need to do both at the same time on the same
resource and we don't need to worry about sysmem <-> buffer.

> I assume you specifically mean persistent maps. Those would be
> interesting to try out for sure, although it's probably quite some
> work and it should wait for the "old" buffer mapping optimizations to
> come in CSMT first.
Yeah, it would not only allow us to do maps that don't need data
transfer from the main thread, it'd also give us advantages of buffers
with constant map addresses. Though I am not sure if we can use it for
e.g. managed buffers, as a persistent map may cause a system memory or
GART fallback.

I was also once hoping that CLIENT_STORAGE_BIT would allow us to create
a GL BO around HeapAlloc'ed memory for sysmem textures (to improve
UpdateTexture by telling GL that the source pointer will remain valid
after glSubTexImage returns), but it turns out it's just one of those
"silly hint things" that don't actually guarantee any behavior. Because
we're talking about sysmem textures we still need to keep the map
pointer constant across device::reset calls, so making GL own the data
is a no-go. Having a double copy and transfering sysmem -> buffer ->
texture is pointless.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20170419/afc561b9/attachment.sig>