public inbox for linux-tegra@vger.kernel.org
 help / color / mirror / Atom feed
From: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
To: Thierry Reding
	<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
Cc: xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org,
	Dave Airlie <airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: xf86-video-tegra or xf86-video-modesetting?
Date: Sat, 24 Nov 2012 23:54:32 +0100	[thread overview]
Message-ID: <1353797672.1479.17.camel@tellur> (raw)
In-Reply-To: <20121124210916.GB27042-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>

Am Samstag, den 24.11.2012, 22:09 +0100 schrieb Thierry Reding:
> Hi,
> 
> With tegra-drm going into Linux 3.8 and NVIDIA posting initial patches
> for 2D acceleration on top of it, I've been looking at the various ways
> how this can best be leveraged.
> 
> The most obvious choice would be to start work on an xf86-video-tegra
> driver that uses the code currently in the works to implement the EXA
> callbacks that allow some of the rendering to be offloaded to the GPU.
> The way I would go about this is to fork xf86-video-modesetting, do some
> rebranding and add the various bits required to offload rendering.
> 
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.

> However, that has all the usual drawbacks of a fork so I thought maybe
> it would be better to write some code to xf86-video-modesetting to add
> GPU-specific acceleration on top. Such code could be leveraged by other
> drivers as well and all of them could share a common base for the
> functionality provided through the standard DRM IOCTLs.
> 
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
even have a common interface to allocate GPU resources suitable for
acceleration: the dumb IOCTLs are only guaranteed to give you a buffer
the display engine can scan out from, nothing in there let's you set up
more fancy things like tiling etc, which might be needed to operate on
the buffer with other engines in some way.

> That approach has some disadvantages of its own, like the potential
> bloat if many GPUs do the same. It would also be a bit of a step back
> to the old monolithic days of X.
> 
For some thoughts about how a unified accelerated driver for various
hardware devices could be done I would like to point at my presentation
at this years XDC.
However doing this right might prove as a major task, so as I already
said it might be more worthwhile to just stuff the Tegra specific bits
into a fork of the modesetting driver.

Regards,
Lucas

  parent reply	other threads:[~2012-11-24 22:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-24 21:09 xf86-video-tegra or xf86-video-modesetting? Thierry Reding
     [not found] ` <20121124210916.GB27042-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-11-24 22:54   ` Lucas Stach [this message]
2012-11-25 13:37     ` Thierry Reding
     [not found]       ` <20121125133759.GA30264-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-11-26 14:01         ` Alex Deucher
     [not found]           ` <CADnq5_PwR1P6HDZSD-UeoaKUdQzFhK3cdQ4jhEWtR9Lgb-P2hQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-11-26 23:14             ` Stephen Warren
     [not found]               ` <50B3F7C7.6040602-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-11-27  0:51                 ` Alex Deucher
2012-11-25 15:47     ` Terje Bergström
2012-11-25 11:45   ` Michal Suchanek
     [not found]     ` <CAOMqctTQGzhu3gU5hdJWKOCU0Dyk1vxCjE918PMa7aR+o1pTiQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-11-25 13:40       ` Thierry Reding
2012-11-26  2:51   ` Alex Deucher
     [not found]     ` <CADnq5_P1D7mwL6iYYbJSEBt8Ub5ejQmsMbupMNUU74d5==+gTw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-11-26  7:32       ` Thierry Reding
     [not found]         ` <20121126073234.GA17600-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-11-26  7:45           ` Dave Airlie
     [not found]             ` <CAPM=9tzfjtUVC5PrRLA3Y659ausf1j=uXp-zfMZFUXz-ir67FA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-11-26  8:13               ` Thierry Reding
2012-11-26  5:56   ` Mark Zhang
2012-11-26 17:45   ` Aaron Plattner
     [not found]     ` <50B3AACE.3050908-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-11-26 21:27       ` Thierry Reding

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1353797672.1479.17.camel@tellur \
    --to=dev-8ppwabl0hbeelga04laivw@public.gmane.org \
    --cc=airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org \
    --cc=xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox