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

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

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

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.

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.

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.

So what do other people think?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: xf86-video-tegra or xf86-video-modesetting?

[Lucas Stach]

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

Re: xf86-video-tegra or xf86-video-modesetting?

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3438 bytes --]

On Sat, Nov 24, 2012 at 11:54:32PM +0100, Lucas Stach wrote:
> 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.

So true. But I'm not sure if it's a good excuse to not do things the
right way, even if it ends up being more work. If the general situation
can be improved then I think it's worth the effort.

> > 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.

With the common base that could be shared I meant all the modesetting
code and framebuffer setup that xf86-video-modesetting already does.
I've been wanting to add support for planes as well, which comes with
another set of standard IOCTLs in DRM.

Rewriting all of that in different drivers doesn't seem very desirable
to me and sounds like a lot of wasted effort. And that's not couting the
maintenance burden to keep up with the latest changes in the generic
modesetting driver.

> > 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.

One major advantage of putting this into the modesetting driver is that
as more hardware support is added common patterns might emerge and make
it easier to refactor things into generic code.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: xf86-video-tegra or xf86-video-modesetting?

[Alex Deucher]

On Sun, Nov 25, 2012 at 8:37 AM, Thierry Reding
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> On Sat, Nov 24, 2012 at 11:54:32PM +0100, Lucas Stach wrote:
>> 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.
>
> So true. But I'm not sure if it's a good excuse to not do things the
> right way, even if it ends up being more work. If the general situation
> can be improved then I think it's worth the effort.
>
>> > 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.
>
> With the common base that could be shared I meant all the modesetting
> code and framebuffer setup that xf86-video-modesetting already does.
> I've been wanting to add support for planes as well, which comes with
> another set of standard IOCTLs in DRM.
>
> Rewriting all of that in different drivers doesn't seem very desirable
> to me and sounds like a lot of wasted effort. And that's not couting the
> maintenance burden to keep up with the latest changes in the generic
> modesetting driver.
>

You don't really end up rewriting it, most people just copy the
modesetting driver, change the name, and start adding acceleration; in
which case, the work is already done.  Also, the generic code doesn't
change much.  Based on other ddxes, you rarely have to change the
modesetting and framebuffer code.  Most of the work ends up being the
device specific acceleration and memory management code.
Also, depending on what hardware is available, I'm not sure
traditional 2D engines will gain much over shadowfb other than hw
accelerated buffer swaps for GL.  In my opinion something like glamor
is the best bet for mapping legacy X APIs on to modern GL hw.

Alex

Re: xf86-video-tegra or xf86-video-modesetting?

[Stephen Warren]

On 11/26/2012 07:01 AM, Alex Deucher wrote:
> On Sun, Nov 25, 2012 at 8:37 AM, Thierry Reding
> <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
...
>> With the common base that could be shared I meant all the modesetting
>> code and framebuffer setup that xf86-video-modesetting already does.
>> I've been wanting to add support for planes as well, which comes with
>> another set of standard IOCTLs in DRM.
>>
>> Rewriting all of that in different drivers doesn't seem very desirable
>> to me and sounds like a lot of wasted effort. And that's not couting the
>> maintenance burden to keep up with the latest changes in the generic
>> modesetting driver.
>>
> 
> You don't really end up rewriting it, most people just copy the
> modesetting driver, change the name, and start adding acceleration; in
> which case, the work is already done.  Also, the generic code doesn't
> change much.  Based on other ddxes, you rarely have to change the
> modesetting and framebuffer code.  Most of the work ends up being the
> device specific acceleration and memory management code.
> Also, depending on what hardware is available, I'm not sure
> traditional 2D engines will gain much over shadowfb other than hw
> accelerated buffer swaps for GL.  In my opinion something like glamor
> is the best bet for mapping legacy X APIs on to modern GL hw.

Rather than have every driver cut/paste the modesetting code, can't the
modesetting core of the DDX be pulled out into a utility library or
similar, so that it can just be compiled/linked into all the DDXs
without actually duplicating the code? That way there's no code
duplication, but each DDX can still be flexible about all the
HW-specific code without making a monolithic DDX.

Re: xf86-video-tegra or xf86-video-modesetting?

[Alex Deucher]

On Mon, Nov 26, 2012 at 6:14 PM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
> On 11/26/2012 07:01 AM, Alex Deucher wrote:
>> On Sun, Nov 25, 2012 at 8:37 AM, Thierry Reding
>> <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> ...
>>> With the common base that could be shared I meant all the modesetting
>>> code and framebuffer setup that xf86-video-modesetting already does.
>>> I've been wanting to add support for planes as well, which comes with
>>> another set of standard IOCTLs in DRM.
>>>
>>> Rewriting all of that in different drivers doesn't seem very desirable
>>> to me and sounds like a lot of wasted effort. And that's not couting the
>>> maintenance burden to keep up with the latest changes in the generic
>>> modesetting driver.
>>>
>>
>> You don't really end up rewriting it, most people just copy the
>> modesetting driver, change the name, and start adding acceleration; in
>> which case, the work is already done.  Also, the generic code doesn't
>> change much.  Based on other ddxes, you rarely have to change the
>> modesetting and framebuffer code.  Most of the work ends up being the
>> device specific acceleration and memory management code.
>> Also, depending on what hardware is available, I'm not sure
>> traditional 2D engines will gain much over shadowfb other than hw
>> accelerated buffer swaps for GL.  In my opinion something like glamor
>> is the best bet for mapping legacy X APIs on to modern GL hw.
>
> Rather than have every driver cut/paste the modesetting code, can't the
> modesetting core of the DDX be pulled out into a utility library or
> similar, so that it can just be compiled/linked into all the DDXs
> without actually duplicating the code? That way there's no code
> duplication, but each DDX can still be flexible about all the
> HW-specific code without making a monolithic DDX.
>

If someone has the time to look into it further, it could probably be
done.  I'm not sure there would be much to share at the end however.

Alex

Re: 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

Re: xf86-video-tegra or xf86-video-modesetting?

[Michal Suchanek]

Hello,

On 24 November 2012 22:09, Thierry Reding
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:

> 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.
>
> 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.
>

You can always make the tegra part a submodule if you think putting it
into the driver directly is too monolithic.

Thanks

Michal

Re: xf86-video-tegra or xf86-video-modesetting?

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

On Sun, Nov 25, 2012 at 12:45:07PM +0100, Michal Suchanek wrote:
> Hello,
> 
> On 24 November 2012 22:09, Thierry Reding
> <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> 
> > 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.
> >
> > 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.
> >
> 
> You can always make the tegra part a submodule if you think putting it
> into the driver directly is too monolithic.

Good point. I suppose it could also be made selectable at compile time,
similar to how things are done in libdrm. I'm not particularly worried
about the monolithic aspect, but I wanted to bring it up for discussion
and see what other people think.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: xf86-video-tegra or xf86-video-modesetting?

[Alex Deucher]

On Sat, Nov 24, 2012 at 4:09 PM, Thierry Reding
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> 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.
>
> 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.
>
> 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.

Just fork and fill in your own GPU specific bits.  Most accel stuff
ends up being very GPU specific.

Alex

Re: xf86-video-tegra or xf86-video-modesetting?

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2314 bytes --]

On Sun, Nov 25, 2012 at 09:51:46PM -0500, Alex Deucher wrote:
> On Sat, Nov 24, 2012 at 4:09 PM, Thierry Reding
> <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > 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.
> >
> > 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.
> >
> > 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.
> 
> Just fork and fill in your own GPU specific bits.  Most accel stuff
> ends up being very GPU specific.

That doesn't exclude the alternative that I described. Maybe I didn't
express what I had in mind very clearly. What I propose is to add some
code to the modesetting driver that would allow GPU-specific code to be
called if matching hardware is detected (perhaps as stupidly as looking
at the DRM driver name/version). Such code could perhaps be called from
the DDX' .ScreenInit and call the GPU-specific function to register an
EXA driver.

That would allow a large body of code (modesetting, VT switching, ...)
to be shared among a number of drivers instead of duplicating the code
for each one and having to keep merging updates from the modesetting
driver as it evolves. So the GPU-specific acceleration would just sit on
top of the existing code and only be activated on specific hardware.
What I'm *not* proposing is to create an abstraction layer for
acceleration.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: xf86-video-tegra or xf86-video-modesetting?

[Dave Airlie]

On Mon, Nov 26, 2012 at 5:32 PM, Thierry Reding
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> On Sun, Nov 25, 2012 at 09:51:46PM -0500, Alex Deucher wrote:
>> On Sat, Nov 24, 2012 at 4:09 PM, Thierry Reding
>> <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
>> > 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.
>> >
>> > 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.
>> >
>> > 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.
>>
>> Just fork and fill in your own GPU specific bits.  Most accel stuff
>> ends up being very GPU specific.
>
> That doesn't exclude the alternative that I described. Maybe I didn't
> express what I had in mind very clearly. What I propose is to add some
> code to the modesetting driver that would allow GPU-specific code to be
> called if matching hardware is detected (perhaps as stupidly as looking
> at the DRM driver name/version). Such code could perhaps be called from
> the DDX' .ScreenInit and call the GPU-specific function to register an
> EXA driver.
>
> That would allow a large body of code (modesetting, VT switching, ...)
> to be shared among a number of drivers instead of duplicating the code
> for each one and having to keep merging updates from the modesetting
> driver as it evolves. So the GPU-specific acceleration would just sit on
> top of the existing code and only be activated on specific hardware.
> What I'm *not* proposing is to create an abstraction layer for
> acceleration.
>

vmware kinda did something like that initially with modesetting, it
was a bit messier, it would be nice though to just plug in stuff like
glamor and things, but you still need to deal with pixmap allocation
on a per-gpu basis.

I'd rather make the modesetting code into a library, either separate
or in the X server, but i've also investigated that and found it was
too much effort for me at the time also.

Dave.

Re: xf86-video-tegra or xf86-video-modesetting?

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3634 bytes --]

On Mon, Nov 26, 2012 at 05:45:38PM +1000, Dave Airlie wrote:
> On Mon, Nov 26, 2012 at 5:32 PM, Thierry Reding
> <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > On Sun, Nov 25, 2012 at 09:51:46PM -0500, Alex Deucher wrote:
> >> On Sat, Nov 24, 2012 at 4:09 PM, Thierry Reding
> >> <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> >> > 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.
> >> >
> >> > 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.
> >> >
> >> > 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.
> >>
> >> Just fork and fill in your own GPU specific bits.  Most accel stuff
> >> ends up being very GPU specific.
> >
> > That doesn't exclude the alternative that I described. Maybe I didn't
> > express what I had in mind very clearly. What I propose is to add some
> > code to the modesetting driver that would allow GPU-specific code to be
> > called if matching hardware is detected (perhaps as stupidly as looking
> > at the DRM driver name/version). Such code could perhaps be called from
> > the DDX' .ScreenInit and call the GPU-specific function to register an
> > EXA driver.
> >
> > That would allow a large body of code (modesetting, VT switching, ...)
> > to be shared among a number of drivers instead of duplicating the code
> > for each one and having to keep merging updates from the modesetting
> > driver as it evolves. So the GPU-specific acceleration would just sit on
> > top of the existing code and only be activated on specific hardware.
> > What I'm *not* proposing is to create an abstraction layer for
> > acceleration.
> >
> 
> vmware kinda did something like that initially with modesetting, it
> was a bit messier, it would be nice though to just plug in stuff like
> glamor and things, but you still need to deal with pixmap allocation
> on a per-gpu basis.

I'm still very new to this game and I probably have a lot of catching up
to do. However I would expect it to be possible to override pixmap
allocation with GPU specific implementations. I've been looking at some
implementations of DDX drivers and I seem to remember that pixmap
management was done in the EXA driver, in which case it would be part of
the GPU specific code anyway.

> I'd rather make the modesetting code into a library, either separate
> or in the X server, but i've also investigated that and found it was
> too much effort for me at the time also.

That idea occurred to me as well. Given my lack of experience I'm not
sure I'd be very well suited for the job if you already judged it to be
too much effort...

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: xf86-video-tegra or xf86-video-modesetting?

[Mark Zhang]

In technical, it's true to focus xf86-video-modesetting on the hardware
independent stuffs/making frameworks and GPU vendors upstreams their
hardware dependent codes. But this needs a lot of cooperation and the
progress would be slow. This is not GPU vendors want so I assume they'll
not put lots of efforts into it.

So I think it's better to fork the xf86-video-modesetting right now
unless someday most of the GPU vendors are willing to work together and
do contributions to modesetting driver.

Mark
On 11/25/2012 05:09 AM, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> 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.
> 
> 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.
> 
> 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.
> 
> So what do other people think?
> 
> Thierry
> 
> * Unknown Key
> * 0x7F3EB3A1
> 

Re: xf86-video-tegra or xf86-video-modesetting?

[Aaron Plattner]

On 11/24/2012 01:09 PM, Thierry Reding wrote:
> 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.

 From a purely logistical standpoint, if you do choose to create a fork, calling 
it xf86-video-tegra might be a problem since there's already an existing 
tegra_drv.so.

You could probably graft tegradrm support onto xf86-video-nv pretty easily, if 
you want to reuse an existing driver package.

-- Aaron

Re: xf86-video-tegra or xf86-video-modesetting?

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

On Mon, Nov 26, 2012 at 09:45:50AM -0800, Aaron Plattner wrote:
> On 11/24/2012 01:09 PM, Thierry Reding wrote:
> >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.
> 
> From a purely logistical standpoint, if you do choose to create a
> fork, calling it xf86-video-tegra might be a problem since there's
> already an existing tegra_drv.so.

Right, you already use that name. Anyone have any great ideas for a new
name?

> You could probably graft tegradrm support onto xf86-video-nv pretty
> easily, if you want to reuse an existing driver package.

I think I'd rather go with a fork of the modesetting driver since it
already provides everything that we need and only the acceleration bits
need to be added on top.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]