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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev