NVIDIA Posts Tegra Gallium3D Patch For K1+ Support
NVIDIA has out a wonderful Thanksgiving surprise... New Mesa code for Tegra K1 GPUs and newer!
While NVIDIA has already pushed Nouveau Gallium3D support patches for Tegra K1 after providing Tegra K1 DRM/KMS kernel driver support, there's more code coming out today.
NVIDIA's Thierry Reding sent out a nearly two thousand line Mesa patch that introduces a new Tegra Gallium3D driver. This "Tegra" code at gallium/drivers though isn't a complete 3D driver -- the Tegra K1+ still use the NVIDIA NVC0 Gallium3D driver for the actual rendering. This patch sets up a screen and forwards on the work to the Nouveau Gallium3D driver given that the Tegra K1 uses a Kepler-derived graphics processor. This work is needed since the GPU and display are exposed as separate devices by this NVIDIA ARM SoC.
Thierry explains the work in this patch message:
While NVIDIA has already pushed Nouveau Gallium3D support patches for Tegra K1 after providing Tegra K1 DRM/KMS kernel driver support, there's more code coming out today.
NVIDIA's Thierry Reding sent out a nearly two thousand line Mesa patch that introduces a new Tegra Gallium3D driver. This "Tegra" code at gallium/drivers though isn't a complete 3D driver -- the Tegra K1+ still use the NVIDIA NVC0 Gallium3D driver for the actual rendering. This patch sets up a screen and forwards on the work to the Nouveau Gallium3D driver given that the Tegra K1 uses a Kepler-derived graphics processor. This work is needed since the GPU and display are exposed as separate devices by this NVIDIA ARM SoC.
Thierry explains the work in this patch message:
Tegra K1 and later use a GPU that can be driven by the Nouveau driver. But the GPU is a pure render node and has no display engine, hence the scanout needs to happen on the Tegra display hardware. The GPU and the display engine each have a separate DRM device node exposed by the kernel.
To make the setup appear as a single device, this driver instantiates a Nouveau screen with each instance of a Tegra screen and forwards GPU requests to the Nouveau screen. For purposes of scanout it will import buffers created on the GPU into the display driver. Handles that userspace requests are those of the display driver so that they can be used to create framebuffers.
This has been tested with some GBM test programs, as well as kmscube and weston. All of those run without modifications, but I'm sure there is a lot that can be improved.
TODO:
- use Nouveau headers to get at the prototype for creating a screen
- implement enough support to seamlessly integrate with X
- refactor some of the code to be reusable by other drivers
18 Comments