D
D
D
er at gmail.com>
To: Jon Smirl <jonsmirl at gmail.com>
In-Reply-To: <9e4733910507280701420f61e4 at mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <21d7e9970507271600118d0400 at mail.gmail.com>
<a728f9f905072806262cc2ef67 at mail.gmail.com>
<9e4733910507280701420f61e4 at mail.gmail.com>
Cc: XOrg Devel List <xorg at freedesktop.org>
Subject: Re: slides from my talk at DDC
X-BeenThere: xorg at lists.freedesktop.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Alex Deucher <alexdeucher at gmail.com>
List-Id: Discuss issues related to the xorg tree <xorg.lists.freedesktop.org>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/listinfo/xorg>,
<mailto:xorg-request at lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/xorg>
List-Post: <mailto:xorg at lists.freedesktop.org>
List-Help: <mailto:xorg-request at lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/xorg>,
<mailto:xorg-request at lists.freedesktop.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2005 14:16:52 -0000
On 7/28/05, Jon Smirl <jonsmirl at gmail.com> wrote:
> On 7/28/05, Alex Deucher <alexdeucher at gmail.com> wrote:
> > On 7/27/05, Dave Airlie <airlied at gmail.com> wrote:
> > > I've put the slides from my talk at DDC up
> > >
> > > http://www.skynet.ie/~airlied/talks/ddc05/ddc_pres.sxi
> > >
> > > On top of those slides, really after talking at OLS I'm convinced we
> > > need a modeset library in userspace not in the kernel, we can then
> > > backend that modesetting lib onto the kernel fbdev or a userspace
> > > split up X..
> > >
> > > Some issues I don't mention that need thinking about are going to be
> > > how mode setting interacts with virtual screens, and
> > > merged-framebuffer type things... (i.e. you want to set two different
> > > modes on the CRTCs but only have a single framebuffer, the mode
> > > setting APIs I've looked at don't seem to cover this too well... but
> > > maybe they don't need to.
> >
> > If possible, I'd like to see mergedfb go away in favor of "real"
> > multi-head support. It'd be nice if a single instance of the driver
> > could handle both heads and manage all of the offscreen memory, but
> > allocate each head it's own chunk of frame buffer. then have the
> > single driver instance update the drawing and 3d engine offsets as
> > appropriate, or not depending on the engine. if one driver handled
> > both heads copies between framebuffers and other operations could be
> > sped up a lot. mergedfb is nice but has too many limitations that
> > wouldn't be there with a better approach (things like drawing engine
> > coordinates, non-rectanglar desktops, etc.).
>=20
> The coordinate limits are fixed in the R300+. If you have two
> identical displays it is cool to use mergedfb with OpenGL drawing.
>=20
yes, but they are not "fixed" on savage, r128, and radeon/r200 and on
r300+ you still have limits, it's just 3968 rather than 2048. We'll
hit those limits soon enough with new larger displays.
Alex
> >
> > Alex
> >
> > >
> > > Dave.
> --
> Jon Smirl
> jonsmirl at gmail.com
>