On Wed, Dec 9, 2015 at 2:15 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Wed, Dec 9, 2015 at 11:23 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> On Wed, Dec 9, 2015 at 11:18 AM, Deve <dev...@gmail.com> wrote: >>> This patch indeed seems to not have a sense. I just added it to the bug >>> report as a suggestion that it works for me after this modification. Emil >>> Velikov said that I should send it to the mailing list. >>> >>> Here is how it works in Supertuxkart: >>> We create rtt with following parameters: >>> >>> DepthStencilTexture = generateRTT(res, GL_DEPTH24_STENCIL8, >>> GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8); >>> >>> Then, during rendering scene, we do: >>> >>> glEnable(GL_FRAMEBUFFER_SRGB); >>> glBindFramebuffer(GL_FRAMEBUFFER, 0); >> >> OK, so this is the "winsys" framebuffer (GL has some term for it, >> sorry, I don't remember what it is... perhaps it's even winsys). This >> is created based on parameters of your selected GLX visual. For >> example, when I run glxinfo, I see (on nouveau; the list on intel will >> be different but comparable): >> >> 480 GLX Visuals >> visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav >> id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat >> ---------------------------------------------------------------------------- >> 0x021 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None >> 0x022 24 dc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None >> ... >> 0x343 24 tc 0 32 0 r . . 8 8 8 8 . s 0 0 0 0 0 0 0 0 0 None >> 0x344 24 tc 0 32 0 r . . 8 8 8 8 . s 0 0 0 16 16 16 16 0 0 Slow >> 0x345 24 tc 0 32 0 r y . 8 8 8 8 . s 0 0 0 0 0 0 0 0 0 None >> 0x346 24 tc 0 32 0 r y . 8 8 8 8 . s 0 0 0 16 16 16 16 0 0 Slow >> >> Note how some of them have srgb, others don't (and have various >> differences in their various other properties). EGL has something >> similar I believe, but tbh I don't remember the specifics. That's the >> mesaVis->sRGBCapable bit below. If you need an sRGB-capable visual, >> are you sure you're picking one? This would be somewhere well before >> any actual rendering takes place. >> >> If you're not sure whether you need an sRGB-capable visual or not, try >> making sure you pick a *non-srgb* visual in a working configuration >> and see if it breaks. > > Right, so looking at your code with in more detail, you probably just > require a stencil visual, which, in combination with this patch, makes > you skip this one. > > However I noticed that i965/hsw and probably others don't expose *any* > sRGB-capable GLX visuals/fb configs! Pretty sure that's not good... > but GLX, sRGB, and visuals are not exactly my strong point, hopefully > someone a bit more clued in can comment.
I suspect that something like this may be the right thing for the intel driver... no reason not to expose sRGB-capable visuals when it so happens that alpha == 0. Also probably the same treatment should be done for BGR565... sRGB encoding will matter even more there, and from the looks of it, all gens support that. diff --git a/src/mesa/drivers/dri/i965/intel_screen.c b/src/mesa/drivers/dri/i965/intel_screen.c index cc90efe..75f2cce 100644 --- a/src/mesa/drivers/dri/i965/intel_screen.c +++ b/src/mesa/drivers/dri/i965/intel_screen.c @@ -1003,9 +1003,10 @@ intelCreateBuffer(__DRIscreen * driScrnPriv, rgbFormat = MESA_FORMAT_B5G6R5_UNORM; else if (mesaVis->sRGBCapable) rgbFormat = MESA_FORMAT_B8G8R8A8_SRGB; - else if (mesaVis->alphaBits == 0) - rgbFormat = MESA_FORMAT_B8G8R8X8_UNORM; - else { + else if (mesaVis->alphaBits == 0) { + rgbFormat = MESA_FORMAT_B8G8R8X8_SRGB; + fb->Visual.sRGBCapable = true; + } else { rgbFormat = MESA_FORMAT_B8G8R8A8_SRGB; fb->Visual.sRGBCapable = true; } _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev