On Friday, August 22, 2014 07:30:37 AM Chris Wilson wrote: > On Thu, Aug 21, 2014 at 08:11:23PM -0700, Ben Widawsky wrote: > > The primary goal of these patches is to introduce what I've started > > calling, "prelocations" on Broadwell. A prelocation is like a > > relocation, except not. When a GPU client specifies a prelocation, it is > > instructing the kernel where in the GPU address the buffer should be > > mapped. The mechanic works very similarly to a relocation except it uses > > the execbuffer object to obtain the offset, and bind if needed. > > You are mixing two APIs. One to preallocate an offset at creation > and one to presume relocations during execbuffer. I'd much rather keep > the flexible execbuffer approach outlined and first submitted a couple of > years ago. > > > If a GPU > > client uses only prelocations, the relocation process can be entirely > > skipped. This sounds like a big win initially, > > Close to zero if the client uses existing interfaces. > -Chris Chris, I don't know if you've seen Ben's libdrm and Mesa patches, but with a few patches to libdrm and virtually zero Mesa changes, he's apparently eliminated our need to do any relocations for the 3D driver. It wasn't invasive at all---I was surprised. With both the CPU and GPU using 48-bit addressing, using the same virtual address on both sides and never changing it seems quite appealing. I'm not sure why we would need to do anything different than that. As I understand it, we still need to let the kernel know what buffers we need pinned during the course of the batchbuffer, since we can't take a page fault and fetch them as needed. Reusing the existing relocation list but just not doing relocations seems like a simple way to do that without having to invent much new API... What is the 'flexible execbuffer' approach you mention from a few years back? I don't remember hearing about it (sorry)... --Ken
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
