From: Mark Zhang <markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Thierry Reding
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
Cc: "xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org"
<xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org>,
Dave Airlie <airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: xf86-video-tegra or xf86-video-modesetting?
Date: Mon, 26 Nov 2012 13:56:25 +0800 [thread overview]
Message-ID: <50B30489.4030904@nvidia.com> (raw)
In-Reply-To: <20121124210916.GB27042-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
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
>
next prev parent reply other threads:[~2012-11-26 5:56 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
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 [this message]
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=50B30489.4030904@nvidia.com \
--to=markz-ddmlm1+adcrqt0dzr+alfa@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.