Christoph, You're talking about something entirely different. I was trying to explain that a correct swizzled border color is *impossible* on r600 and later chipsets. I think your hardware is actually good and can do swizzled border color with a little bit of driver work you refuse to do. :) You have the option, we don't. The fact D3D doesn't have sampler swizzling actually explains a lot.
In any case, all radeon drivers should be able to pass the normal (unswizzled) border color tests. Marek On Mon, Apr 8, 2013 at 1:01 PM, Christoph Bumiller < e0425...@student.tuwien.ac.at> wrote: > On 08.04.2013 12:03, Marek Olšák wrote: > > On Mon, Apr 8, 2013 at 11:29 AM, Michel Dänzer <mic...@daenzer.net > > <mailto:mic...@daenzer.net>> wrote: > > > > On Fre, 2013-04-05 at 17:36 -0400, j.gli...@gmail.com > > <mailto:j.gli...@gmail.com> wrote: > > > From: Jerome Glisse <jgli...@redhat.com <mailto:jgli...@redhat.com > >> > > > > > > Most test pass, issue are with border color and swizzle. > > > > FWIW, those issues are there with non-compressed formats as well. I'm > > afraid we might need to change the hardware border colour depending > on > > the swizzle. > > > > > > I don't think so. The issue with the swizzled border color seems to be > > a bad hardware design decision present since r600 rather than a > > hardware bug. I tried fixing it for older chipsets with no success. I > > doubt the hw designers fixed this for SI. The problem is the hardware > > tries to guess what the border color swizzle is from the combined > > pipe_format+sampler view swizzle combination. You need 2 texture > > swizzle states in the texture unit for the border color to be swizzled > > correctly, because texels must be swizzled by the pipe_format swizzle > > and sampler view swizzle, but the border color must be swizzled by the > > sampler view only. The main problem is that the hardware internally > > tries to undo the pipe_format swizzle in a way that just doesn't work. > > I don't remember the exact swizzles being used by hardware, but I got > > crazy cases like if I set texture swizzle to ywzx, the border color > > will be ywyy. There is no way to access those zx components of the > > border color for that specific swizzling. For some cases, the hardware > > succeeds in guessing what the border color should be, e.g. if I set > > texture swizzle to .zyxw, the returned border color will be .xyzw (and > > that would be correct if the swizzle came from pipe_format, and > > incorrect if the swizzle came from sampler view). > > > > It was easy with r300, because I could just undo pipe_format swizzling > > before passing the border color to the hardware. > > > > Ah yes, border colour swizzle, it's a problem on NV, too. Because the > border colour isn't getting swizzled at all [as far as we know]. > The main issue is the separation of samplers and textures in gallium, if > that wasn't the case samplers and textures would be coupled and the > sampler state could be set according to texture view state (if it's just > OpenGL; and if it's just D3D there's no swizzle). > So, I just leave it broken, I can't destroying the elegant separation > because of such an unimportant detail, that hurts too much. > > (Also, if someone was to use multiple samplers and views in gallium and > index them dynamically, I'd have to set up all combinations of textures > and samplers, which is simply ridiculous. > And now I'm going to look for some secret sampler setup bit that says > "swizzle according to texture view state". Maybe looking into the future > of OpenGL someone's been wise enough to add that. But then, I'd have the > sample problem as you. An intensity texture simply doesn't have separate > values for R,G,B,A.) > > Possible solution: > Maybe the state tracker could just do the swizzling, because it knows > that samplers and views are coupled, and it knows the swizzle ? > > > Marek > > > > > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
