On Tue, Feb 19, 2013 at 3:55 PM, Michel Dänzer <mic...@daenzer.net> wrote: > On Die, 2013-02-19 at 15:48 +0100, Marek Olšák wrote: >> On Tue, Feb 19, 2013 at 3:28 PM, Michel Dänzer <mic...@daenzer.net> wrote: >> > On Die, 2013-02-19 at 14:04 +0100, Marek Olšák wrote: >> >> On Tue, Feb 19, 2013 at 11:02 AM, Michel Dänzer <mic...@daenzer.net> >> >> wrote: >> >> > >> >> > Really, what I don't understand is why r600g doesn't seem affected by >> >> > this... at least on my RS880 it's passing the piglit tests this change >> >> > fixes with radeonsi. So maybe I'm just missing some magic bit for >> >> > radeonsi. >> >> >> >> RGB formats do fail fbo-blending-formats with r600g/redwood here. >> > >> > Okay. >> > >> > >> >> However the alpha channel can sometimes contain 1 in memory even if >> >> the format is RGBX. Off the top of my head, glClear, glTex[Sub]Image, >> >> glCopyTex[Sub]Image always set alpha to 1. >> > >> > Well, but they shouldn't for these formats. :) The memory corresponding >> > to X* channels should remain unchanged. I'm working on a separate patch >> > for that for radeonsi. >> >> I think the only way you could do that is to set the colormask to RGB. > > Exactly. > >> Doesn't it have a negative effect on performance if some channels are >> masked out? > > It might, but I don't see that we really have a choice. If the app / > state tracker doesn't want to preserve those bits, it should use a > non-X* format.
We do have a choice: let's do nothing. ReadPixels and GetTexImage always set the alpha to one, and we can patch the blend state manually to get correct RGB blending. What could possibly be broken if the alpha is modified by the hardware? Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
