You can do the transform in shader but you can’t _blend_ in shader…that’s why we use sRGB – in some cases the color transform is in shader. (If you can get the dedicated hw to do it, you also save ALU.)

I haven’t yet got around to actually look at the difference, but from reading the documentaion, the major change is that the entire framebuffer is using non-linear sRGB, and every blend operation requires two conversions (to linear for blending, and then back to sRGB) of every affected fragment.

Effectively, the difference appears to be due to the nonlinearity of the entire framebuffer, which of course would be most obvious on high-contrast elements like runway lights where falloff occurs in a rather narrow “halo”.

With that complexity in mind, would it not make more sense to have the shader for such point lights take care of that nonlinearity?

Hi Alberto,

I can’t deny my last paragraph was snarky and rude, and for that I apologize. But having spent the number of hours I have spent going through hell to make ATI cards perform as good as possible only to read that I have failed to deliver what I promise because ATI cards put out crazy colors when sRGB is enabled (something I really can’t fix), what can I say – your comment really frustrated me.

But I do think the _intent_ of my original post was correct even if the way I said it was rude. The intent was this: none of us should react too severely about these things. Fixing driver issues takes time, the beta isn’t final, ATI will issue new drivers, so wait and see before you throw the sim out, because we really are trying to make it as good as possible.

But in the end the choice is yours; if you think that the value proposition of X-Plane is not there, that is your opinion and not something for me to argue with.

Thanks for your detailed explanation of the problem.
In your original blog post this sounds very different – if I may quote you: “We may have to disable functionality when we identify this driver set”. Disable functionality !! That sounds quite different, doesn’t it ?
You could have left it at clearing up the missunderstanding you caused by talking about “disabling functionality” instead of “changing the color falloff of runway lights”. But you decided to take the mickey out of me with your last paragraph, which leaves a bitter taste when I think in which state this overpriced piece of software still is in nine months after it’s release.
Ah forget it, I’m out of here.

The ATI performance bug isn’t really a bug, it’s just not fast. On 10.10r1 if you have to turn down clouds, it’s because you’re out of fill rate. On 10.05r1 we don’t use the fastest driver path.

It changes the color fall off curve of the runway lights. We think with sRGB is better – otherwise we wouldn’t use it, but the sim is still quite functional without it. Run with –no_srgb and observe the runway lights. 🙂

Would disabling sRGB have any impact other than calibration issues on calibrated gear?

Well, I can appreciate why Albert expects the sim to work well — and this is why we put so much effort into making sure that the sim works on all cards, no matter what the driver situation. This is also why we intend to come up with an acceptable solution before we finalize 10.10.