On 4 March 2016 at 17:38, Lucas Stach <l.st...@pengutronix.de> wrote:
> Am Freitag, den 04.03.2016, 17:20 +0000 schrieb Daniel Stone:
>> Hi,
>>
>> On 4 March 2016 at 16:08, Lucas Stach <l.st...@pengutronix.de> wrote:
>> > Am Freitag, den 04.03.2016, 15:09 +0000 schrieb Daniel Stone:
>> >> Thanks for taking this on, it looks really good! I just have the one
>> >> question though - did you look at the EGLDevice extension? Using that
>> >> to enumerate the GPUs, we could create the gbm_device using the KMS
>> >> device and pass that in to the EGLDisplay, with an additional attrib
>> >> to pass in an EGLDevice handle to eglGetPlatformDisplay. This could
>> >> possibly be better since it is more independent of DRM as the API, and
>> >> also allows people to share device enumeration/selection code with
>> >> other platforms (e.g. choosing between multiple GPUs when using a
>> >> winsys like Wayland or X11).
>> >>
>> > I have not looked at this in detail yet, but I think it's just an
>> > extension to the interface outlined by this series.
>> >
>> > If we require the KMS device to have a DRI2/Gallium driver it should be
>> > easy to hook up the EGLDevice discovery for them.
>> > Passing in a second device handle for the KMS device is then just the
>> > EGL implementation calling gbm_device_set_kms_provider() on the render
>> > GBM device, instead of the application doing it manually.
>>
>> It turns the API backwards a bit though ...
>>
>> Right now, what we require is that the GBM device passed in is the KMS
>> device, not the GPU device; what you're suggesting is that we discover
>> the GPU device and then add the KMS device.
>>
>> So, with your proposal:
>> gbm_gpu = gbm_device_create("/dev/dri/renderD128");
>> egl_dpy = eglGetDisplay(gbm_gpu);
>> gbm_kms = gbm_device_create("/dev/dri/card0");
>> gbm_device_set_kms_provider(gbm_gpu, gbm_kms);
>>
>> i.e. the device the user creates first is the GPU device.
>>
>> With EGLDevice, we would have:
>> gbm_kms = gbm_device_create("/dev/dri/card0");
>> egl_gpus = eglGetDevicesEXT();
>> egl_dpy = eglGetPlatformDisplay(gbm_kms, { EGL_TARGET_DEVICE, egl_gpus[0] });
>>
>> So, the first/main device the user deals with is the KMS device - same
>> as today. This makes sense, since GBM is the allocation API for KMS,
>> and EGL should be the one dealing with the GPU ...
>>
> Right, my API design was from my view of GBM being the API to bootstrap
> EGL rendering, but defining it as the KMS allocation API makes a lot
> more sense, when you think about it.
>
>> Maybe it would make sense to reverse the API, so rather than creating
>> a GBM device for the GPU and then linking that to the KMS device -
>> requiring users to make different calls, e.g. gbm_bo_get_kms_bo(),
>> which makes it harder to use and means we need to port current users -
>> we create a GBM device for KMS and then link that to a GPU device.
>> This would then mean that eglGetPlatformDisplay could do the linkage
>> internally, and then existing users using gbm_bo_get_handle() etc
>> would still work without needing any different codepaths.
>
> Yes, this will make the implementation inside GBM a bit more involved,
> but it seems more natural this way around when thinking about hooking it
> up to EGLDevice. I'll try it out and send an updated RFC after the
> weekend.
>
While I'm more inclined to Daniel's suggestion, I wonder why people
moved away from Thierry's approach - creating a composite/wrapped dri
module ? Is there anything wrong with it - be that from technical or
conceptual POV ?I believe it has a few advantages over the above two proposals - it allows greater flexibility as both drivers will be tightly coupled and can communicate directly, does not expand the internal/hidden ABI that we currently have between GBM and EGL, could (in theory) work with GLX. Thoughts ? -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
