On Thu, 2006-03-09 at 12:11 +0000, Keith Whitwell wrote: > 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?
Yes. > > 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). True, but with the texture upload performance in the proprietary drivers scrolling in firefox is just fine. However, when using FBOs I can feel that it's faster. > > 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? Yes, or well, if it's Render extension performance I'm trying to match, then doing things in software is faster than a lot of the Xorg drivers. > > 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? Render is fully accelerated and important parts of the core protocol is also accelerated. > > 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? GLX apps == indirect GLX, Yes. Both sw mesa and native GL driver can be used. Xgl will use native GL driver if possible. > > 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? Yes. > > For acclerating XVideo, are you using or have you investigated PBO's for > the image upload? Yes. Xgl can already use PBOs for all image uploads, including YUV images. It gives significantly better performance when used but there's currently no driver that accelerate image uploads from PBOs for anything but 32bpp and YV12 images that Xgl support and most media players use must currently be uploaded as 8bpp. > > > 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? Yes. > > 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... Eventually, we probably want the compositing manager to be a direct rendering client. > > I think the texture rectangle extensions are pretty widely supported. I > take it you can work with either as necessary? Yes, but I have compositing manager features that use mipmapping when possible and that only works with 2D texture targets so I definitely prefer ARB_tnpot. -David ------------------------------------------------------- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
