3 ms·

Of course, yeah. :) Are you a Fedora dev? Do you have an impression that NVIDIA is getting to be a bit more cooperative with the desktop Linux development comm

by pxc 5y ago

Of course, yeah. :) Are you a Fedora dev? Do you have an impression that NVIDIA is getting to be a bit more cooperative with the desktop Linux development community these days, like with the changes related to GBM that made this decision possible for Fedora?

Conan_Kudo 5y ago
Yeah, they definitely are. Though they're still not cooperative enough to make it so NVIDIA hardware has a good basic level of performance with the OSS drivers. :( While this Change currently describes the effort for GNOME, KDE Plasma is likely to also be ready for Fedora Linux 36 for this. There a couple of other blockers to deal with, but hopefully those are squared away in time...
sho_hn 5y ago
I am not so sure that GBM support was motivated primarily by the Linux desktop community. It's rather a symptom of industry-wide trends. I work in the automotive industry, where we buy high-end, high-margin SoC SKUs - not a lot of them (compared to phones, primarily), but enough to have some sway. Within the industry, most OEMs are moving toward inhouse platform-shaped development and have a desire to make their code increasingly reusable and hardware-agnostic, as well as lower integration costs for third-party app content. This drives the adoption of open source commodity stack technologies and standards like Wayland, and means hardware vendors now have to demonstrate or offer support for them - with a single code path. It then replaces vendor-proprietary stuff like nVidia's EGLStreams previously used for similar cross-process compositing use cases as Wayland is now. In the past, vendors were asked to solve the problem for the OEM as they saw fit on their hardware. I've personally requested vendors to provide GBM support on the Orin SoCs by writing it into requirements. I know nVidia previously started incorporating limited GBM support in their GPGPU product line, probably due to similar customer asks in that industry, but I don't know it well. For the Linux desktop community the takeway is that it has a massive impact beyond just the Linux desktop - by being a leader in the commodification of technologies everyone just ends up adopting, especially as embedded development trends toward a similar complexity level as desktops and phones with similar feature requirements. Accordingly it deserves support from those who have these technologies in their supply chain.
- my123 5y ago
  > I've personally requested vendors to provide GBM support on the Orin SoCs Tegra drivers (incl Xavier) already had GBM since years, with the nvgpu driver stack.
  - sho_hn 5y ago
    Yep, it's what I meant with the GPGPU line. It's used somewhat in driver assistance ECUs. Doesn't mean you don't need to explicitly spell it out in Orin requirements though :-)
- ognarb 5y ago
  > I've personally requested vendors to provide GBM support on the Orin SoCs by writing it into requirements. Thanks Eike
- pxc 5y ago
  Thanks for enlightening me on the real interests driving this! Glad to see NVIDIA working in alignment with more open standards either way. :)

by pxc 5y ago

Conan_Kudo 5y ago

Yeah, they definitely are. Though they're still not cooperative enough to make it so NVIDIA hardware has a good basic level of performance with the OSS drivers. :( While this Change currently describes the effort for GNOME, KDE Plasma is likely to also be ready for Fedora Linux 36 for this. There a couple of other blockers to deal with, but hopefully those are squared away in time...

sho_hn 5y ago

I am not so sure that GBM support was motivated primarily by the Linux desktop community. It's rather a symptom of industry-wide trends. I work in the automotive industry, where we buy high-end, high-margin SoC SKUs - not a lot of them (compared to phones, primarily), but enough to have some sway. Within the industry, most OEMs are moving toward inhouse platform-shaped development and have a desire to make their code increasingly reusable and hardware-agnostic, as well as lower integration costs for third-party app content. This drives the adoption of open source commodity stack technologies and standards like Wayland, and means hardware vendors now have to demonstrate or offer support for them - with a single code path. It then replaces vendor-proprietary stuff like nVidia's EGLStreams previously used for similar cross-process compositing use cases as Wayland is now. In the past, vendors were asked to solve the problem for the OEM as they saw fit on their hardware. I've personally requested vendors to provide GBM support on the Orin SoCs by writing it into requirements. I know nVidia previously started incorporating limited GBM support in their GPGPU product line, probably due to similar customer asks in that industry, but I don't know it well. For the Linux desktop community the takeway is that it has a massive impact beyond just the Linux desktop - by being a leader in the commodification of technologies everyone just ends up adopting, especially as embedded development trends toward a similar complexity level as desktops and phones with similar feature requirements. Accordingly it deserves support from those who have these technologies in their supply chain.

my123 5y ago
> I've personally requested vendors to provide GBM support on the Orin SoCs Tegra drivers (incl Xavier) already had GBM since years, with the nvgpu driver stack.
- sho_hn 5y ago
  Yep, it's what I meant with the GPGPU line. It's used somewhat in driver assistance ECUs. Doesn't mean you don't need to explicitly spell it out in Orin requirements though :-)
ognarb 5y ago
> I've personally requested vendors to provide GBM support on the Orin SoCs by writing it into requirements. Thanks Eike
pxc 5y ago
Thanks for enlightening me on the real interests driving this! Glad to see NVIDIA working in alignment with more open standards either way. :)