On Sat, 18 Feb 2012 23:07:32 +0800, Liu Aleaxander <aleaxan...@gmail.com> wrote: > This patch add the support of gl_PointCoord gl builtin var for platform > gen4 and gen5(ILK). > > We can get the point start coord and the current pixel coord from PS > payload, and the only left element needed is the point size. Then handle > that in SF thread. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45975 > Piglit: glsl-fs-pointcoord and fbo-gl_pointcoord > > NOTE: This is a candidate for stable release branches.
> + /*
> + * Window coordinates in an FBO are inverted, which means coord in Y
> + * must be inverted, too.
> + */
> + if ((ctx->Point.SpriteOrigin == GL_LOWER_LEFT) != render_to_fbo) {
> + pntcoord.negate = true;
> + emit(BRW_OPCODE_ADD, pntcoord, pntcoord, fs_reg(1.0f));
> + }
In the FS, it should be looking at the data in the key instead of
ctx->whatever, to be sure that statechanges are handled correctly.
(Though, given that point sprite coordinate flippinng is handled in the
SF code, I'd think we would handle it the same way for pointcoord too).
> + /*
> + * gl_PointCoord is a FS instead of VS builtin variable, thus is not
> + * included in c->nr_setup_regs. But FS need SF do the interpolation,
> + * so that here padding the interpolation for gl_PointCoord in last.
> + */
> + if (c->key.do_point_coord)
> + c->nr_setup_regs++;
So you're writing an extra attribute of setup, but you haven't increased
the size of the URB entry. If the URB full except for pointcoord, you'd
end up writing over the next URB entry and probably hanging the GPU. If
you correctly allocate the URB size and that gets reflected in
urb_read_length, you should be able to read your new attribute.
pgpU0q3gK9inb.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
