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);
}
is possibly overkill but stops me feeling uneasy about the
seeming truncation. Is this something that UBSAN detects?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
