public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Anholt <eta@lclark.edu>
To: Discuss issues related to the xorg tree  <xorg@lists.freedesktop.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Xserver development <xorg@freedesktop.org>
Subject: Re: State of Linux graphics
Date: Tue, 30 Aug 2005 23:15:20 -0700	[thread overview]
Message-ID: <1125468920.84445.21.camel@leguin> (raw)
In-Reply-To: <9e47339105083009037c24f6de@mail.gmail.com>

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

On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> I've written an article that surveys the current State of Linux
> graphics and proposes a possible path forward. This is a long article
> containing a lot of detailed technical information as a guide to
> future developers. Skip over the detailed parts if they aren't
> relevant to your area of work.
> 
> http://www.freedesktop.org/~jonsmirl/graphics.html
> 
> Topics include the current X server, framebuffer, Xgl, graphics
> drivers, multiuser support, using the GPU, and a new server design.
> Hopefully it will help you fill in the pieces and build an overall
> picture of the graphics landscape.
> 
> The article has been reviewed but if it still contains technical
> errors please let me know. Opinions on the content are also
> appreciated.

"EXA extends the XAA driver concept to use the 3D hardware to accelerate
the X Render extension."  No, EXA is a different acceleration
architecture making different basic design decisions related to memory
management and driver API.

"If the old hardware is missing the hardware needed to accelerate render
there is nothing EXA can do to help."  Better memory management allows
for better performance with composite due to improved placement of
pixmaps, which XAA doesn't do.  So EXA can help.

"So it ends up that the hardware EXA works on is the same hardware we
already had existing OpenGL drivers for."  No.  See, for example, the nv
or i128 driver ports, both completed in very short timeframes.

"The EXA driver programs the 3D hardware from the 2D XAA driver adding
yet another conflicting user to the long line of programs all trying to
use the video hardware at the same time."  No, EXA is not an addition to
XAA, it's a replacement.  It's not "yet another conflicting user" on
your machine (and I have yet to actually see this purported conflict in
my usage of either acceleration architecture).

"There is also a danger that EXA will keep expanding to expose more of
the chip’s 3D capabilities."  If people put effort into this because
they see value in it, without breaking other people's code, why is this
a "danger?"

-- 
Eric Anholt                                     eta@lclark.edu
http://people.freebsd.org/~anholt/              anholt@FreeBSD.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

  parent reply	other threads:[~2005-08-31  6:15 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-30 16:03 State of Linux graphics Jon Smirl
2005-08-30 17:26 ` David Reveman
2005-08-30 18:13   ` Jon Smirl
2005-08-30 22:38   ` Dave Airlie
2005-08-31  6:33   ` Allen Akin
2005-08-31  8:11     ` Anshuman Gholap
2005-08-31 17:20     ` David Reveman
2005-08-31 17:48     ` Jim Gettys
2005-08-31 18:23       ` Jon Smirl
2005-08-31 19:06       ` Allen Akin
2005-08-31 19:14         ` Jim Gettys
2005-08-31 18:29     ` Keith Packard
2005-08-31 20:06       ` Allen Akin
2005-08-31 20:20         ` Ian Romanick
2005-09-01  1:04           ` James Cloos
2005-08-31 21:06         ` Keith Packard
2005-09-01  1:58           ` Allen Akin
2005-09-01  3:11             ` Ian Romanick
2005-09-01  6:00               ` Antonio Vargas
2005-09-01 10:20                 ` Alan Cox
2005-09-01 13:57                   ` Antonio Vargas
2005-09-01  6:11               ` Allen Akin
2005-09-01  3:59             ` Keith Packard
2005-09-01 15:24               ` Brian Paul
2005-09-01 15:59                 ` Jim Gettys
2005-09-01 16:39                   ` Andreas Hauser
2005-09-01 20:18                     ` Jim Gettys
2005-09-01 20:38                       ` Jon Smirl
2005-09-01 21:29                         ` Sean
2005-09-01 16:09                 ` Alan Cox
2005-09-01 16:04                   ` Brian Paul
2005-09-01 17:21                     ` Ian Romanick
2005-09-01 17:26                       ` Keith Whitwell
2005-09-01 20:03               ` Allen Akin
2005-08-31  3:11 ` Daniel Stone
2005-08-31  4:29   ` Jon Smirl
2005-08-31  4:50   ` Jon Smirl
     [not found]     ` <1125464500.8730.68.camel@localhost.localdomain>
2005-08-31  5:17       ` Jon Smirl
2005-08-31  5:23       ` Jon Smirl
2005-08-31  5:40         ` Jon Smirl
2005-08-31  6:15 ` Eric Anholt [this message]
2005-08-31 13:38   ` Jon Smirl
  -- strict thread matches above, loose matches on Subject: below --
2005-09-02  2:44 rep stsb
2005-09-03  4:00 mcartoaje

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=1125468920.84445.21.camel@leguin \
    --to=eta@lclark.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xorg@freedesktop.org \
    --cc=xorg@lists.freedesktop.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