Just to clear this up a bit: I tried this using OpenGL 3.0's framebuffer entry points: same problem. Same problem also appears using a renderbuffer to back the FBO, rather than a texture.

What does fix the problem is using GL_RGBA as the internalformat for the colour attachment rather than GL_RGB. The sized GL_RGB8 also triggers the issue, but GL_RGBA8 doesn't.

Using GL_RGBA is good enough for my purposes, but I'll leave this open as it does seem to actually be a bug.

-- David

Right now, you're just getting lucky.  In current Mesa, with the scaled blit support, one of your workarounds fails.  I suspect once we do format conversions, the new workaround will fail.

Here's the problem I see:

The window system framebuffer is srgb-capable, internally "SARGB8".  You don't have GL_FRAMEBUFFER_SRGB set, so you're not expecting srgb encoding, but we only look at the framebuffer's format when blitting, so you get encoding.

The source is not srgb (internally XRGB8888 or ARGB8888), so you're not expecting srgb decoding.  We don't do srgb decoding.

Thus, a conversion is happening on your data when you didn't expect it.

The GL 3.2 spec seems to indicate that we shouldn't ever do srgb encode or decode.  This seems pretty weird -- it means you can't blit from an actually-linear texture to an actually-srgb window correctly, which is an undesirable property.

The 4.3 spec says we should pay attention to GL_FRAMEBUFFER_SRGB on the destination, but only ever look at the format (aka GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING) on the source.  This seems pretty crazy, since it means that a GL_EXT_framebuffer_blit-using application that doesn't know about srgb would get their stuff srgb-encoded when copying from one part of a framebuffer object to another!

I'm not sure what the right resolution is here.  Hey CC list, what do you think?

We talked about things the other day, and I'd missed this code:

   src.brw_surfaceformat = dst.brw_surfaceformat;

So there shouldn't be any mismatched encode/decode happening in blorp, ever.

Mesa master just got a big overhaul of format handling in the blit path -- you should be getting the same byte values showing up in your window system framebuffer (test using xmag) as you have in your palette.  Is that what you are seeing?

Okay, I just grabbed latest Mesa git [9.3.0-devel (git-396c69b)] and sat down with xmag. The behaviour is a bit more consistent, though it's not perfect.

Long story short, the colours I see (and register with xmag) are correct (i.e. no sRGB encode/decode happens) when I create the texture backing the FBO with the GL_RGBA format, and incorrect with the GL_RGB format.

What has changed is that the behaviour is now the same (always correct or always incorrect) with both scaled and 1:1 blits.

One thing that I noticed is that glxinfo is not showing up any FBConfigs or Visuals with sRGB enabled — should it be? I still get a "1" from glGetIntegerv(GL_FRAMEBUFFER_SRGB_CAPABLE_EXT, ...), and sRGB encode seems to work fine.

-- David

I see that the recent OpenGL spec update clarifies that BlitFramebuffer should only do sRGB encode/decode when GL_FRAMEBUFFER_SRGB is enabled.

This inspired me to do a bit more spelunking (with git 50370e483ba). I'm only getting issues when using the blorp blit engine — both the BLT engine path and _mesa_meta_BlitFramebuffer work fine. I poked around a bit in the blorp blit code, but don't really understand what's going wrong. It does work fine if you don't linearize the render target format in brw_blorp_surface_info::set(), though I'm sure it'll break other things.

I've uploaded the output from INTEL_DEBUG=blorp debug here: http://davidgow.net/stuff/omnispeak_blorp_debug.txt

Hope it helps!

-- David

Blit path got large overhaul in summer, is this now fixed/same/worse?

Related with some dEQP tests failures, I looked recently at the sRGB conversions while blitting. The current status is that no color space conversions are done: neither sRGB decoding when reading, nor sRGB encoding when writting.

However, OpenGL specifications since 4.4 and OpenGL ES 3.0
say otherwise, and indicate that color space conversions should be applied when needed.

Before proceeding with this bug, we would need to take a decission regarding what it is the expected behaviour in this case. I've recently sent an e-mail to mesa's mailing list: http://lists.freedesktop.org/archives/mesa-dev/2015-February/077681.html but I haven't received an answer so far.

Notice that this also affects some dEQP tests for GLES3 that are failing because they expect the sRGB encoding/decoding to be done.

I think Ken fixed this with his series ending in commit 3190c7ee97 which was commited on August 8th and is in mesa-13.0.0. I have replayed your trace and it looks like http://davidgow.net/stuff/mesa-omnispeak-srgb-stretch.png (which I think is what you were saying is what you thought was the correct behavior.)

Marking fixed. Please reopen if I've made an error or mesa-13.0.0 does not fix the issue.