[Mesa-dev] [PATCH 2/2] radeonsi: add support for compressed texture

[Marek Olšák]

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 <
e0425955 at 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 <michel at daenzer.net
> > <mailto:michel at daenzer.net>> wrote:
> >
> >     On Fre, 2013-04-05 at 17:36 -0400, j.glisse at gmail.com
> >     <mailto:j.glisse at gmail.com> wrote:
> >     > From: Jerome Glisse <jglisse at redhat.com <mailto:jglisse at 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 at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130408/65210ace/attachment.html>