xf86-video-tegra or xf86-video-modesetting?

[Terje Bergström]

On 25.11.2012 00:54, Lucas Stach wrote:
> As much as I dislike to say this, but forking the modesetting driver to
> bring in the Tegra specific 2D accel might be the best way to go for
> now. Especially looking at the very limited resources available to
> tegradrm development and NVIDIAs expressed desire to do as few changes
> as possible to their downstream work.

Which changes to downstream work would these be? What changes would help
in getting the acceleration support into mode setting driver?

We've done quite a lot of changes in downstream nvhost to help
upstreaming, and I'll keep downstream nvhost as close to upstream as
possible when/if nvhost wiggles its way into upstream. But you might be
talking about something else.

> We don't have any standard DRM IOCTLs for doing acceleration today. The
> single fact that we are stitching together command streams in userspace
> for execution by the GPU renders a common interface unusable. We don't

Command streams for Tegra 2D are easiest to stitch together in user
space. We have discussed the possibility to implement some simple
operations in kernel, too, f.ex. using 2D to clear or copy a memory
region. But in the end there are not too many reasons to implement that
in kernel versus doing it in user space.

Do we have to even attempt standardizing the IOCTLs? The standardization
could happen in libdrm level. We've already implemented some common 2D
operations for Tegra 2D, but we haven't yet solved the question that
where should we put the code in - in our internal tree it's now inside
libdrm. None of the other GPUs supported by libdrm implement
acceleration inside libdrm, so if we follow that, we'll just provide
libtegradrm with the 2D operations. That'll require a Tegra specific
modesetting driver.

Path of least resistance?

Terje