[Mesa-stable] Request for update of commits proposed for stable branch

Deucher, Alexander Alexander.Deucher at amd.com
Mon Jul 29 15:51:27 PDT 2013


> -----Original Message-----
> From: Carl Worth [mailto:cworth at cworth.org]
> Sent: Monday, July 29, 2013 6:29 PM
> To: Deucher, Alexander
> Cc: Stellard, Thomas; Marek Olšák; mesa-stable at lists.freedesktop.org
> Subject: RE: Request for update of commits proposed for stable branch
> 
> "Deucher, Alexander" <Alexander.Deucher at amd.com> writes:
> > I'll take a look this week.  Thanks!
> 
> Any update here, Alex?

Sorry, you released the last update before I had had a chance to look at it and I figured it was too late at that point.

> 
> >> commit 49c1fc7044eaaa5c2dca05ff4a709be8e3636871
> >> Author: Alex Deucher <alexander.deucher at amd.com>
> >> Date:   Tue Mar 19 18:11:20 2013 -0400
> >>
> >>     r600g: don't emit SQ_DYN_GPR_RESOURCE_LIMIT_1 on cayman
> 
> I looked a bit at this one, and I couldn't find any mention of
> SQ_DYN_GPR_RESOURCE_LIMIT_1 in the function of interest (on the 9.1
> branch). So I'm guessing there's nothing to be done here, (we can't
> remove code that doesn't exist).

Yeah, that one can be dropped.

> 
> >> commit 4539f8e20af286d1f521eb016c89c6d9af0b801c
> >> Author: Alex Deucher <alexander.deucher at amd.com>
> >> Date:   Fri May 3 09:56:31 2013 -0400
> >>
> >>     r600g: don't emit surface_sync after FLUSH_AND_INV_EVENT
> 
> This one is harder for me to trivially reject.
> 
> There's code in the 9.1 branch that's similar-ish to the code being
> modified by the patch, but it's clearly different, so it's not obvious
> to me what should be done.
> 
> I'm going to skip both of these commits for the imminent 9.1.6 release,
> and unless you advocate specifically, I won't look at these again for
> future 9.1 releases.

You can skip this one as well.  The flush code has changed too much in the master branch so we'd need to pull a number of changes back.  With 9.2 imminent, we can just leave the old flush code in 9.1 unless Tom or Marek have any objections.

Alex




More information about the mesa-stable mailing list