On Fri, May 16, 2014 at 03:45:24PM +0100, Chris Wilson wrote:
> On Fri, May 16, 2014 at 04:27:34PM +0200, Daniel Vetter wrote:
> > On Fri, May 16, 2014 at 12:36:09PM +0100, Chris Wilson wrote:
> > > On Mon, May 12, 2014 at 06:40:43PM +0200, Daniel Vetter wrote:
> > > > I think as soon as we have th
On Fri, May 16, 2014 at 04:27:34PM +0200, Daniel Vetter wrote:
> On Fri, May 16, 2014 at 12:36:09PM +0100, Chris Wilson wrote:
> > On Mon, May 12, 2014 at 06:40:43PM +0200, Daniel Vetter wrote:
> > > I think as soon as we have the golden context stuff from Mika we could
> > > drop our usage of rest
On Fri, May 16, 2014 at 12:36:09PM +0100, Chris Wilson wrote:
> On Mon, May 12, 2014 at 06:40:43PM +0200, Daniel Vetter wrote:
> > I think as soon as we have the golden context stuff from Mika we could
> > drop our usage of restore_inhibit. We only need that to avoid the hw
> > getting angry if the
On Mon, May 12, 2014 at 06:40:43PM +0200, Daniel Vetter wrote:
> I think as soon as we have the golden context stuff from Mika we could
> drop our usage of restore_inhibit. We only need that to avoid the hw
> getting angry if the context state is illegal afaik.
Apart from the contexts being over 1
On Thu, May 08, 2014 at 01:18:40PM +0300, Ville Syrjälä wrote:
> On Thu, May 08, 2014 at 12:54:47PM +0300, Ville Syrjälä wrote:
> > On Wed, May 07, 2014 at 11:59:23PM +0300, Abdiel Janulgue wrote:
> > > On Wednesday, May 07, 2014 02:49:31 PM Ville Syrjälä wrote:
> > > > I quickly cobbled together a
On Thu, May 08, 2014 at 12:54:47PM +0300, Ville Syrjälä wrote:
> On Wed, May 07, 2014 at 11:59:23PM +0300, Abdiel Janulgue wrote:
> > On Wednesday, May 07, 2014 02:49:31 PM Ville Syrjälä wrote:
> > > I quickly cobbled together a hsw version of this and gave it a whirl on
> > > one machine. Seems to
On Wed, May 07, 2014 at 11:59:23PM +0300, Abdiel Janulgue wrote:
> On Wednesday, May 07, 2014 02:49:31 PM Ville Syrjälä wrote:
> > I quickly cobbled together a hsw version of this and gave it a whirl on
> > one machine. Seems to work just fine here, and no lockups when switching
> > between hw and
On Wednesday, May 07, 2014 02:49:31 PM Ville Syrjälä wrote:
> I quickly cobbled together a hsw version of this and gave it a whirl on
> one machine. Seems to work just fine here, and no lockups when switching
> between hw and sw binding tables. Did you get the lockups on hsw even
> with rendercopy?
On Wed, May 07, 2014 at 02:49:31PM +0300, Ville Syrjälä wrote:
> I quickly cobbled together a hsw version of this and gave it a whirl on
> one machine. Seems to work just fine here, and no lockups when switching
> between hw and sw binding tables. Did you get the lockups on hsw even
> with renderco
I quickly cobbled together a hsw version of this and gave it a whirl on
one machine. Seems to work just fine here, and no lockups when switching
between hw and sw binding tables. Did you get the lockups on hsw even
with rendercopy?
Here's my hsw version:
>From 17eeb8021815e2c18d6ba9b2185a37904296
On Wednesday, May 07, 2014 12:38:04 AM Ville Syrjälä wrote:
> On Tue, May 06, 2014 at 10:48:02PM +0300, Abdiel Janulgue wrote:
> > Use on-chip hw-binding table generator to generate binding
> > tables when the test emits SURFACE_STATES packets. The hw generates
> > these binding table packets inter
On Tue, May 06, 2014 at 10:48:02PM +0300, Abdiel Janulgue wrote:
> Use on-chip hw-binding table generator to generate binding
> tables when the test emits SURFACE_STATES packets. The hw generates
> these binding table packets internally so we don't have to
> allocate space on the batchbuffer.
>
>
Use on-chip hw-binding table generator to generate binding
tables when the test emits SURFACE_STATES packets. The hw generates
these binding table packets internally so we don't have to
allocate space on the batchbuffer.
Signed-off-by: Abdiel Janulgue
---
lib/gen8_render.h | 13 +++
13 matches
Mail list logo
