[2/4] WineD3D: Make context_attach_surface_fbo srgb aware
stefan at codeweavers.com
Thu Sep 10 18:16:26 CDT 2009
Am Friday 11 September 2009 00:05:02 schrieb Henri Verbeet:
> I don't think SRGB_ANY is correct here. context_apply_fbo_entry() very
> much cares about which texture is attached to the FBO. If rendering to
> sRGB textures was supported properly this would depend on the sRGB
> write state, but since it isn't this should aways be SRGB_RGB.
Rendering to the RGB or sRGB copy of the surface isn't related to the srgb
write state. It's only related to how the surface is read. An application can
render to a texture with srgb writes off and read the texture with srgb read
correction on. In this case we want to render to the srgb copy, otherwise we
have to copy it later.
Whether you render to the RGB or sRGB copy doesn't affect the resulting data
written into the texture, only performance(in the sense that a copy is needed
or not needed).
> This doesn't work either. While it probably doesn't matter if the blit
> is done in RGB or sRGB space, it still needs to be the same color
> space for both surfaces (and one of those can be onscreen).
All drivers I found so far can blit between sRGB and RGB textures, and it does
what we want(doesn't change the data in the texture), so there's no problem
if we blit from an RGB onscreen surface to an sRGB offscreen surface. If this
didn't work the entire [3/4] patch would be moot.
> On a higher level, I'm not really happy with how sRGB textures
> currently fit in and how that's starting to spread to everything that
> has to deal with surfaces.
I am not happy with this either, but I don't see this issue going away anytime
soon. I'm always open to alternative suggestions though.
Two alternative ideas I had and threw away:
-> Handle this in the texture, create two set of surfaces for each texture.
Somewhat in the way the first crossover hack for this issue worked. That
causes troubles if the app updates a surface, since we have to decide in the
getSurfaceLevel call where all updates in the future will go. We'll also have
to duplicate the location management in textures.
-> Handle this in d3d9, and create two wined3d textures/surfaces/volumes.
Sounds nice at first because ddraw, d3d8 and as far as I can see d3d10 don't
have this problem in the same way d3d9 does. But it would run into the same
issues as the idea above, we'd have to duplicate the location management in
d3d9, and maybe duplicate the stateblock management in d3d9(to keep track of
D3DSAMP_SRGBTEXTURE, I am not sure if a GetSamplerState call is enough)
-> Some more generic system of having multiple GL textures per d3d
texture/surface. I was thinking about that when we had issues with a texture
being read on different samplers with different sampler states. However, I
never had a good idea what this might look like, nor how this would be more
elegant in the end.
More information about the wine-devel