[Mesa-dev] [PATCH 2/2] i965: handle gl_PointCoord for Gen4 and Gen5 platform

Yuanhan Liu yuanhan.liu at linux.intel.com
Sun Feb 26 23:37:08 PST 2012


On Thu, Feb 23, 2012 at 02:37:06PM +0800, Yuanhan Liu wrote:
> On Tue, Feb 21, 2012 at 11:59:17AM -0800, Eric Anholt wrote:
> > On Sun, 19 Feb 2012 13:31:33 +0800, Liu Aleaxander <aleaxander at gmail.com> wrote:
> > > On Sun, Feb 19, 2012 at 8:54 AM, Eric Anholt <eric at anholt.net> wrote:
> > > > On Sat, 18 Feb 2012 23:07:32 +0800, Liu Aleaxander <aleaxander at 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
> 
> Thanks for the info.
> 
> Well, I was trying to figure out why this patch doesn't work when the
> urb read lenght per each attribute is set to 2 at calculate_urb_setup(),
> but it does work when set to 4. I may not quite understand the urb
> layout now; and I'm trying to figure it out.

OK, finally, I guess I understand that now. And I wrote another
patch to fix this issue. And this time we don't need to write a single
PS shader to handle it thus it's much cleaner than this patch.

Thanks,
Yuanhan Liu



More information about the mesa-dev mailing list