[RFC 4/4] drm: Add NVIDIA Tegra support

Alex Deucher alexdeucher at gmail.com
Thu Apr 12 07:12:31 PDT 2012


On Thu, Apr 12, 2012 at 10:09 AM, Alex Deucher <alexdeucher at gmail.com> wrote:
> On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding
> <thierry.reding at avionic-design.de> wrote:
>> * Alex Deucher wrote:
>>> On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
>>> <thierry.reding at avionic-design.de> 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


More information about the dri-devel mailing list