On to, 2016-08-11 at 12:02 +0100, Chris Wilson wrote:
> On Thu, Aug 11, 2016 at 01:53:40PM +0300, Joonas Lahtinen wrote:
> >
> > On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> > >
> > > @@ -2019,9 +2023,9 @@ populate_lr_context(struct i915_gem_context *ctx,
> > > RING_INDIRECT_CTX(engine->mmio_base), 0);
> > > ASSIGN_CTX_REG(reg_state, CTX_RCS_INDIRECT_CTX_OFFSET,
> > > RING_INDIRECT_CTX_OFFSET(engine->mmio_base), 0);
> > > - if (engine->wa_ctx.obj) {
> > > + if (engine->wa_ctx.vma) {
> > > struct i915_ctx_workarounds *wa_ctx = &engine->wa_ctx;
> > > - uint32_t ggtt_offset = i915_gem_obj_ggtt_offset(wa_ctx->obj);
> > > + u32 ggtt_offset = wa_ctx->vma->node.start;
> > lower_32_bits()?
> I considered, I didn't to keep the changes to a minimum plus I've a
> slight unease about making it seem like we don't care about the upper 32
> bits.
>
> static inline u32 i915_ggtt_offset(vma)
> {
> GEM_BUG_ON(upper_32_bits(vma->node.start));
> return lower_32_bits(vma->node.start);
> }
>
I was about to suggest this, it could maybe even take u64, depending on
how the respective locations look after the VMA overhaul.
Regards, Joonas
> is possibly overkill but stops me feeling uneasy about the
> seeming truncation. Is this something that UBSAN detects?
> -Chris
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
