On Wed, Mar 18, 2015 at 04:57:53PM +0000, Nick Hoath wrote: > Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset hardware > workarounds require that GeneralStateOffset & InstructionBaseOffset > are restricted to a 32 bit address space. > > This is a preparatory patch prior to supporting 64bit virtual memory > allocations. > > Allow the user space to flag that a mapping can occur beyond > the 32bit limit. This allows backward compatibility and user space > drivers that haven't been enhanced to support these workarounds to > function. > > Signed-off-by: Nick Hoath <nicholas.hoath@xxxxxxxxx> Because of the libdrm buffer cache being opaque to the different users I don't see how a flag set at create time will work. Also on a very quick look all userspace is still nice and relocates indirect state with I915_GEM_DOMAIN_INSTRUCTION (well except no-reloc userspace where this is lost). Can't we just piggy-pack on top of that? Creative abuse of established abi ;-) But that's easy to resolve with an additional bit for no-reloc in execbuf to signal that it's indirect state and one flag to allow it. Upside of that approach is that we don't need to change anything in userspace, except SNA (atm the only no-reloc user). And yeah I think for this one here we need to have all the support rolled out for everyone to make sure it actually works ... Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
