On Sun, 19 Feb 2012 13:31:33 +0800, Liu Aleaxander <aleaxan...@gmail.com> wrote: > On Sun, Feb 19, 2012 at 8:54 AM, Eric Anholt <e...@anholt.net> wrote: > > On Sat, 18 Feb 2012 23:07:32 +0800, Liu Aleaxander <aleaxan...@gmail.com> > > wrote: > >> + /* > >> + * 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. > > That's maybe the place I don't understand quite well so far. Say, you > write attributes into URB from SF thread to FS. I did increase the > urb_read_length in wm_state. Is that the allocation you mean? Should > I, say, allocate size for extra attributes just for FS in SF stage? If > so, would you please tell me how? Since if I understand correctly, the > urb_read_length in SF_STATE is counted from the attributes from VF > stage. Thus at least urb_read_length in SF stage is not the right > place for me to touch, right?
urb_entry_size in the SF is the size of what the SF outputs and is what determines how much space is allocated by brw_urb.c
pgpWdNMPE6Jeq.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
