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.
--
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
