+Frank, who's also working on the pvr uAPI. Hi, On Thu, 22 Dec 2022 14:21:07 -0800 Matthew Brost <matthew.brost@xxxxxxxxx> wrote: > The code has been organized such that we have all patches that touch areas > outside of drm/xe first for review, and then the actual new driver in a separate > commit. The code which is outside of drm/xe is included in this RFC while > drm/xe is not due to the size of the commit. The drm/xe is code is available in > a public repo listed below. > > Xe driver commit: > https://cgit.freedesktop.org/drm/drm-xe/commit/?h=drm-xe-next&id=9cb016ebbb6a275f57b1cb512b95d5a842391ad7 > > Xe kernel repo: > https://cgit.freedesktop.org/drm/drm-xe/ Sorry to hijack this thread, again, but I'm currently working on the pancsf uAPI, and I was wondering how DRM maintainers/developers felt about the new direction taken by the Xe driver on some aspects of their uAPI (to decide if I should copy these patterns or go the old way): - plan for ioctl extensions through '__u64 extensions;' fields (the vulkan way, basically) - turning the GETPARAM in DEV_QUERY which can return more than a 64-bit integer at a time - having ioctls taking sub-operations instead of one ioctl per operation (I'm referring to VM_BIND here, which handles map, unmap, restart, ... through a single entry point) Regards, Boris
