[Mesa-dev] [RFC] i965: Fix border color on Sandybridge and Ivybridge.

[Kenneth Graunke]

On 01/20/2012 12:19 PM, Eric Anholt wrote:
> On Fri, 20 Jan 2012 04:16:00 -0800, Kenneth Graunke<kenneth at whitecape.org>  wrote:
>> While reading through the simulator, I found some interesting code that
>> looks like it checks the sampler default color pointer against the bound
>> set in STATE_BASE_ADDRESS.  On failure, it appears to program it to a
>> bogus but in-bound value.
>>
>> So I decided to try programming a legitimate bound, and lo and behold,
>> border color worked.  Unfortunately, it's not entirely reliable: piglit
>> tests (such as tex-border-1) will still fail if you run them in a loop.
>>
>> +91 piglits (or thereabouts).
>>
>> This patch causes serious regressions and should not be pushed as-is.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28924
>> Signed-off-by: Kenneth Graunke<kenneth at whitecape.org>
>
> SO AWESOME.  Also, it fixes lightsmark on ivb!  I was meaning to write a
> FS hack to test my theory that border color was lightsmark's problem (it
> sure looked like it), and you beat me with a fix.
>
>> -       OUT_BATCH(1); /* Dynamic state upper bound */
>> +       /* Dynamic state upper bound.  Although the documentation says that
>> +	* programming it to zero will cause it to be ignored, that is a lie.
>> +	* If this isn't programmed to a real bound, the sampler border color
>> +	* pointer is rejected, causing border color to mysteriously fail.
>> +	*/
>> +       OUT_BATCH(((uintptr_t) intel->batch.bo + intel->batch.bo->size) | 1);
>
> You're stuffing some userspace pointer into this field.  It doesn't have
> any relation to the GPU address.  You were looking for:
>
>         OUT_RELOC(intel->batch.bo,
> 		 I915_GEM_DOMAIN_INSTRUCTION, 0,
> 		 intel->batch.bo->size | 1);

Yeah :) As soon as I posted that, ickle pointed it out and I rewrote it 
to do what you said.  Oops.   With that change, do I have your R-b?