From: "Terje Bergström" <tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Cc: Thierry Reding
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>,
"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: Sun, 25 Nov 2012 17:47:32 +0200 [thread overview]
Message-ID: <50B23D94.8070604@nvidia.com> (raw)
In-Reply-To: <1353797672.1479.17.camel@tellur>
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
next prev parent reply other threads:[~2012-11-25 15:47 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 [this message]
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=50B23D94.8070604@nvidia.com \
--to=tbergstrom-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
--cc=airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=dev-8ppwABl0HbeELgA04lAiVw@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