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.