On Wed, Feb 18, 2015 at 06:19:08PM +0000, Damien Lespiau wrote: > On Wed, Feb 18, 2015 at 03:16:06PM +0000, Nick Hoath wrote: > > Signed-off-by: Nick Hoath <nicholas.hoath@xxxxxxxxx> > > That looks reaaaally drastic and without explanations nor W/A > documentation that looks wrong. > > Couldn't it be the virtual addresses that need to be on 32 bits? within > a 64bits PPGTT address space? Also this W/A is listed for BDW/CHV. Right > now, we have no way of telling what kind of buffer we're being asked to > relocate into the address space, so there's no way to selectively ensure > some of those buffers end up with a virtual address that remains in the > lower 4GB. I915_GEM_DOMAIN_INSTRUCTION is commonly used for all indirect state by mesa, so we could restrict the wa to objects with that reloc. Which means that all the render/texture crap can still be relocated anywhere, which is the majority. Of course that means a full audit of mesa/ddx/libva to make sure we don't break anything. And if there would be breakage we need to make 48bit address spaces opt-in. But yeah restricting all objects and then also applying that restriction to physical objects is _really_ drastic. So please double-check that this is about physical addresses and not virtual addresses. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
