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 -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
