On Thu, Apr 12, 2012 at 10:09 AM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding > <thierry.reding@xxxxxxxxxxxxxxxxx> wrote: >> * Alex Deucher wrote: >>> On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding >>> <thierry.reding@xxxxxxxxxxxxxxxxx> wrote: >>> > In other words I would like to use the Tegra hardware to render content into >>> > a framebuffer (using potentially the 3D engine or HW accelerated video >>> > decoding blocks) but display that framebuffer with a CRTC registered by a >>> > different driver (perhaps provided by a PCIe or USB device). >>> > >>> > I think such a setup would be possible if the CRTC registration can be >>> > decoupled from the DRM driver. Perhaps sdrm even supports that already? >>> >>> You should be able to do something like that already with dma_buf and >>> the drm prime infrastructure. There's even a drm driver for the udl >>> USB framebuffer devices. >> >> Using DRM PRIME requires user-space to be involved. I was thinking more along >> the lines of allowing a dumb DRM driver that only provides a CRTC to register >> with another driver so that it shows up as an output for the latter DRM >> device. > > Even then it could get tricky with synchronization depending on the hw. > >> >> Then again, having user-space control this may be more flexible. Performance- >> wise both should be about the same, right? What I don't quite understand yet >> is how the DMABUF would be synchronized on both ends. Is there some infra- >> structure to account for it or would I have to export two buffers and flip >> them during the vblank of the "consumer"? > > Performance should be about the same. The tricky part is > synchronization. dma_buf is for sharing. There are ideas to make > generic sync objects, but for now, it's up to the userspace components > to handle it. Some example code: http://lists.freedesktop.org/archives/dri-devel/2012-April/021182.html Alex -- 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
