On Friday, May 4, 2018 1:16:29 AM PDT Kenneth Graunke wrote: > On Friday, May 4, 2018 12:39:12 AM PDT Chris Wilson wrote: > > Quoting Kenneth Graunke (2018-05-04 08:34:07) > > > On Thursday, May 3, 2018 11:53:24 PM PDT Chris Wilson wrote: > > > > Quoting Kenneth Graunke (2018-05-04 02:12:40) > > > > > This isn't strictly necessary, but anyone running Cannonlake will > > > > > already have Kernel 4.5 or later, so there's no reason to support > > > > > the relocation model on Gen10+. > > > > > > > > /o\ gvt. Need I say more? > > > > -Chris > > > > > > Yes. What's the deal with GVT? > > > > Their current restrictions involve forcing the use of a 32b > > aliasing-ppgtt. Not that they support cnl+ yet, so they might remember > > to lift that restriction in time. > > -Chris > > Wow, that's really miserable. So, we can't actually depend on real > PPGTT existing? Do you know if/when they might fix this? > > This seriously wrecks a lot of my plans if we can't assume PPGTT > and have to deal with relocations for all of eternity. Jason and I > have been planning on doing PPGTT-only drivers for months. We figured > that full PPGTT had been working since Gen8 and surely would be viable > on anything modern. If it weren't for enterprise kernels, I would have > required this all the way back to Gen8 in a heartbeat. > > --Ken
Okay, whew, it looks like we were wrong. There's a bit of confusing
code in the kernel:
if (intel_vgpu_active(dev_priv)) {
/* GVT-g has no support for 32bit ppgtt */
has_full_ppgtt = false;
has_full_48bit_ppgtt =
intel_vgpu_has_full_48bit_ppgtt(dev_priv);
}
But Joonas explained that this means GVT-g does support full PPGTT
with 48-bit addresses, it just never did the 32-bit only thing.
So, I think we're fine here after all.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
