Streams vs. GBM: The Fight Continues Over NVIDIA's Proposed Wayland Route
It's been over one month since NVIDIA presented their proposed Weston patches for supporting Wayland with NVIDIA's Linux binary driver but the discussion over their proposed approach remains heated.
NVIDIA's proposed changes for Wayland compositors has been rather controversial and largely comes down to the current compositors relying upon the GBM (Generic Buffer Manager) versus the approach preferred by NVIDIA of utilizing EGLStreams and friends. NVIDIA believes that the current GBM API won't offer the best buffer allocation on their hardware, among other concerns.
NVIDIA has been pushing for Wayland compositor developers to support both GBM and their approach, in an effort to figure out the superior solution and ideally make improvements to that for the benefit of both parties. However, that's more work involved for the desktop environments and others developing Wayland compositors as there is another code-path to then develop, test, and support. While NVIDIA has said in the mailing list that supporting both paths would just affect the compositors, it's looking like that going this route could affect more than that: namely the toolkits being used by compositors.
Mike Blumenkrantz and Carsten Haitzler of the Enlightenment project and who have long been involved in bringing their environment to Wayland have come out this week with these concerns.
"You're proposing your stream-based approach which would exist alongside the current standard (and universally-used) GBM. Additionally, in order to run on your specific brand of hardware, all toolkit and compositor authors would need to implement your proposed streams functionality otherwise only software rendering would be available? If this is true then it seems a bit strange to me that, despite still speaking in hypothetical terms about future developments in both GBM and streams, you're stating that GBM cannot be improved to match the functionality of your proposed approach and are instead advocating that everyone who has already written support for GBM now also support streams. As someone with more than a casual interest in both toolkit and compositor development, I'd like to see the best approach succeed, but I don't see any fundamental blocker to providing the functionality you've described in GBM, and I'm not overly enthusiastic about someone requiring even more work from those who write toolkits and compositors, especially when having 'full' Wayland support is already such an enormous undertaking," wrote Blumenkrantz in the aforelinked mailing list message.
Long story short, it looks like it could be a while before there is a mutual agreement among NVIDIA and Wayland developers over a proper implementation.
NVIDIA's proposed changes for Wayland compositors has been rather controversial and largely comes down to the current compositors relying upon the GBM (Generic Buffer Manager) versus the approach preferred by NVIDIA of utilizing EGLStreams and friends. NVIDIA believes that the current GBM API won't offer the best buffer allocation on their hardware, among other concerns.
NVIDIA has been pushing for Wayland compositor developers to support both GBM and their approach, in an effort to figure out the superior solution and ideally make improvements to that for the benefit of both parties. However, that's more work involved for the desktop environments and others developing Wayland compositors as there is another code-path to then develop, test, and support. While NVIDIA has said in the mailing list that supporting both paths would just affect the compositors, it's looking like that going this route could affect more than that: namely the toolkits being used by compositors.
Mike Blumenkrantz and Carsten Haitzler of the Enlightenment project and who have long been involved in bringing their environment to Wayland have come out this week with these concerns.
"You're proposing your stream-based approach which would exist alongside the current standard (and universally-used) GBM. Additionally, in order to run on your specific brand of hardware, all toolkit and compositor authors would need to implement your proposed streams functionality otherwise only software rendering would be available? If this is true then it seems a bit strange to me that, despite still speaking in hypothetical terms about future developments in both GBM and streams, you're stating that GBM cannot be improved to match the functionality of your proposed approach and are instead advocating that everyone who has already written support for GBM now also support streams. As someone with more than a casual interest in both toolkit and compositor development, I'd like to see the best approach succeed, but I don't see any fundamental blocker to providing the functionality you've described in GBM, and I'm not overly enthusiastic about someone requiring even more work from those who write toolkits and compositors, especially when having 'full' Wayland support is already such an enormous undertaking," wrote Blumenkrantz in the aforelinked mailing list message.
Long story short, it looks like it could be a while before there is a mutual agreement among NVIDIA and Wayland developers over a proper implementation.
87 Comments