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);
pgp4BH8i8Lqw6.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
