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