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
