David Reveman wrote:
On Thu, 2006-03-09 at 10:55 +0000, Keith Whitwell wrote:
David,
Beyond copypixels/partial swaps, do you have a feel for the remaining
driver requirements for Xgl in the intermediate term? I know in your
talks you were mentioning things like FBO's and of course GLX_EXT_tfp,
which the drivers don't currently support -- have these requirements
been lifted, or do you somehow work around them?
A GL compositing manager can always be accelerated on Xgl.
> FBOs are not
required but they're needed to accelerate drawing to redirected windows.
Most normal apps run fine without acceleration but XVideo and GLX apps
needs it for decent performance.
So without FBO's you basically do software 2d to a system memory buffer
and then use glTexSubImage to upload the dirty regions to a texture?
So, I guess you'd notice this with apps like firefox that scroll a large
pixmap? And the other cases where you still need hardware acceleration
for reasonable 2d performance... (And clearly XVideo).
Certainly texture upload performance is relevent, but it seems like
FBO's are a definite win - if you have hardware where you've bothered
writing a 2d driver in the first place, you'd need FBO's to match the 2d
performance of the old X.org driver, correct?
In the case where you have FBO's available, how are these used for 2d
accleration? Is it just bitblits (via copypixels, I guess), or do you
accelerate Render or Xlib drawing as well?
When you say GLX apps, you mean indirect GLX? What do you currently use
to render incoming GLX protocol? Does it get passed off to a software
rasterizer (sw mesa), or is it passed down to the underlying GL driver?
As I recall from XDC there wasn't a possiblity for direct-rendered GL
until a couple of things were fixed: 1) making DRI apps aware of
redirection, ie have them use a private frontbuffer and 2) have some
mechanism to tell the compositing manager that the frontbuffer has been
updated. Does that still sound correct?
For acclerating XVideo, are you using or have you investigated PBO's for
the image upload?
I guess I'm trying to figure out what paths are necessary in the driver
for using Xgl as a working, full-strength desktop environment with
performance and capabilities on par with what people are used to with
the traditional Xorg drivers.
It's certainly great that the i8xx driver can minimally support Xgl with
such a small tweak, but it seems like there's much more that could be
done and I'd like to get a handle on what's missing in the DRI drivers
to enable people to use Xgl as part of their primary desktop.
Xgl has no driver requirements for GLX_EXT_tfp. GLX_EXT_tfp is always
supported on Xgl. GL_ARB_texture_rectangle or
GL_ARB_texture_non_power_of_two should be supported to make it useful
for the compositing manager, though.
The GLX_EXT_tfp support is a function of the fact that you're already
using textures to hold pixmaps? And also that you don't support direct
rendering? I don't know if direct-rendered clients would ever
particularly need GLX_EXT_tfp though...
I think the texture rectangle extensions are pretty widely supported. I
take it you can work with either as necessary?
Keith
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
