On 01/20/2012 12:19 PM, Eric Anholt wrote:
On Fri, 20 Jan 2012 04:16:00 -0800, Kenneth Graunke<[email protected]>
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<[email protected]>
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?
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
