[Mesa-dev] [PATCH 01/12] i965: Assign PS kernel start pointers when we decide which kernels to use

Ben Widawsky ben at bwidawsk.net
Mon Aug 11 23:39:13 PDT 2014


On Mon, Aug 11, 2014 at 11:18:36PM -0700, Ben Widawsky wrote:
> On Mon, Aug 11, 2014 at 10:40:25PM -0700, Kenneth Graunke wrote:
> > On Monday, August 11, 2014 07:53:11 PM Ben Widawsky wrote:
> > > On Mon, Aug 11, 2014 at 05:29:31PM -0700, Kristian Høgsberg wrote:
> > [snip]
> > > > diff --git a/src/mesa/drivers/dri/i965/gen8_ps_state.c b/src/mesa/drivers/dri/i965/gen8_ps_state.c
> > > > index 3d6d7f0..f58d49c 100644
> > > > --- a/src/mesa/drivers/dri/i965/gen8_ps_state.c
> > > > +++ b/src/mesa/drivers/dri/i965/gen8_ps_state.c
> > > > @@ -134,7 +134,7 @@ static void
> > > >  upload_ps_state(struct brw_context *brw)
> > > >  {
> > > >     struct gl_context *ctx = &brw->ctx;
> > > > -   uint32_t dw3 = 0, dw6 = 0, dw7 = 0;
> > > > +   uint32_t dw3 = 0, dw6 = 0, dw7 = 0, ksp0, ksp2 = 0;
> > > 
> > > Should ksp0 and ksp2 be uint64_t? I realize the current code is broken
> > > anyway. (/me makes note for no reloc branch).
> > 
> > It's not necessary.  The kernel start pointers are relative to Instruction State Base Address, which we set to the start of a buffer that contains all of the shader programs.  That buffer isn't going to be bigger than 4GB, so the offsets will always fit in 32 bits.
> > 
> > --Ken
> 
> I was mostly thinking of a future with the ability to OUT_BATCH64, or
> OUT_BATCH_KERNEL the pointer (and as a readability thing). I agree it
> doesn't have any real impact.
> 
> One of the paths I was considering with the no reloc thing was to always
> set the state base addresses to be 0 (for everything), and in that case
> the kernel start pointer very well could be > 4GB. There are other ways
> to solve that problem of course, but I felt compelled to justify.
> 

On further consideration, even if you malloc the shader and use that
address, > 4G is a possibility.

-- 
Ben Widawsky, Intel Open Source Technology Center


More information about the mesa-dev mailing list