Re: XRENDER extension docs?
On Wed, Feb 26, 2003 at 05:06:48PM -0800, Kendall Bennett wrote: Kurt Wall [EMAIL PROTECTED] wrote: Feigning erudition, Kendall Bennett wrote: % Hi Guys, % % Is thete any documentation on the XRENDER extension and more specifically % the Matrox implementation of it? Do any other drivers other than the % Matrox driver implement this extension? http://www.xfree86.org/~keithp/render/ $XFREE86ROOT/lib/X11/doc/render-protocol.txt Awesome, thanks! That gives a bit more information, but it doesn't really describe how the XAA drivers can accelerate the XRENDER extension. It Yes, it would indeed be great if the XAA.HOWTO would be expanded by a new paragraph speaking about the XRENDER acceleration hooks. There is already the xaa.h which gives some info, but a discution of the hooks would be welcome. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
Around 9 o'clock on Feb 27, Sven Luther wrote: Yes, it would indeed be great if the XAA.HOWTO would be expanded by a new paragraph speaking about the XRENDER acceleration hooks. There is already the xaa.h which gives some info, but a discution of the hooks would be welcome. The current Render acceleration hooks are pretty low level; we need to spend some time designing a more comprehensive interface. The trouble is that Render provides so little structure to build upon, unlike the core protocol. We can place additional structure inside the render code and XAA to break down the current interface into more reasonable functions. However, it's hard to get excited about building accelerated implementations without a comprehensive test suite and when the spec is still a bit in flux. I've been working on the test suite with some students, but there's a steep learning curve and so not much progress has been made yet. The spec is almost finished as well; I've got to go rewrite the trapezoid specification to match our current thinking and I'd like to add some image transport requests. The trapezoid part won't have much of an effect on the architecture of any acceleration internals, but image transport may need to be exposed all the way to the bottom of the system. -keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
Keith Packard [EMAIL PROTECTED] wrote: Yes, it would indeed be great if the XAA.HOWTO would be expanded by a new paragraph speaking about the XRENDER acceleration hooks. There is already the xaa.h which gives some info, but a discution of the hooks would be welcome. The current Render acceleration hooks are pretty low level; we need to spend some time designing a more comprehensive interface. The trouble is that Render provides so little structure to build upon, unlike the core protocol. Ok, so it is a little early yet to start implementing this in our drivers? Or should we just implement what the Matrox driver is doing and follow that model for now (ie: just alpha blits)? We can place additional structure inside the render code and XAA to break down the current interface into more reasonable functions. However, it's hard to get excited about building accelerated implementations without a comprehensive test suite and when the spec is still a bit in flux. I've been working on the test suite with some students, but there's a steep learning curve and so not much progress has been made yet. Ok. What stuff other than alpha blits (for fonts and menus) does XRENDER provide anyway? I am a little unclear on that right now. Also I have been wondering about the accelerated anti-aliased text. Is all anti-aliased text in XFree86 done via the XRENDER extension and alpha blits? It is possible to implement accelerated anti-aliased text using simple 4-8 levels of mono bitmap blits using FreeType (that is what we used for it in our MGL graphics library). It is slower than regular text (and probably slower than alpha blits in hardware), but way faster than doing alpha blits in software when there is a hardware mono blit function to use. Has anyone considered using that style of interface for anti- aliased text in XFree86? Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
Around 10 o'clock on Feb 27, Kendall Bennett wrote: Ok, so it is a little early yet to start implementing this in our drivers? Or should we just implement what the Matrox driver is doing and follow that model for now (ie: just alpha blits)? I think the interfaces currently provided by XAA will probably remain usable, so you might as well implement them. Ok. What stuff other than alpha blits (for fonts and menus) does XRENDER provide anyway? I am a little unclear on that right now. Render does three things: 1) Image compositing 2) Trapezoids (and triangles) 3) Glyphs However, the image compositing function has a lot of functionality buried inside, including projective image transformations, solid fills and tiling. Plus, trapezoids and glyphs are defined in terms of image compositing, so in the MI implementation, they are implemented on top of the basic Composite function. My thought is that we'll want to have the XAA 'Composite' function recognise some common operations (like solid fill and screen-screen blt and perhaps others) and call out to driver functions designed for that specific operation. Plus, we should have XAA expose special higher level functions for glyph rendering to the driver so that the graphics card can use the higher level data structures to speed this operation, rather than having the MI layer break the text operation into a (long) sequence of primitive Composite operations. Also I have been wondering about the accelerated anti-aliased text. Is all anti-aliased text in XFree86 done via the XRENDER extension and alpha blits? It is possible to implement accelerated anti-aliased text using simple 4-8 levels of mono bitmap blits using FreeType (that is what we used for it in our MGL graphics library). Yes, all AA text is done with the Render glyph operations which are defined in terms of the basic image composition primitive. Once you have hardware acceleration for image compositing, that's going to be a lot faster than any non-standard rendering path. -keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
Keith Packard [EMAIL PROTECTED] wrote: I think the interfaces currently provided by XAA will probably remain usable, so you might as well implement them. Ok. Plus, we should have XAA expose special higher level functions for glyph rendering to the driver so that the graphics card can use the higher level data structures to speed this operation, rather than having the MI layer break the text operation into a (long) sequence of primitive Composite operations. Yes, most definitely. The current mechanism is not exactly efficient, and in fact is the reason why I want to hook some functions at a higher level so we can make this faster. Also when it comes to rendering text, one of the fastest ways of doing this is the way that OS/2 does it. Instead of caching any glyphs in offscreen video memory (terribly wasteful of offscreen video memory and no faster than using system memory bitmaps), you maintain a single large bitmap that matches the physical resolution of the screen (ie: 1280x1024 mono bitmap). When you need to draw text, you render the text into the mono bitmap in software at the necessary place on the screen, and when that is done pass the entire bitmap to be drawn to the hardware with a clip rectangle that covers just the text you just rendered into the bitmap. The clipping is real easy to do in the software setup stages for text rendering, and then you can blit the entire string to the hardware in one shot. So fast, efficient text could be done in XFree86 if a single function was used to transfer an entire bitmap in the driver code (pre-clipping could easily be done before the driver code is called), and some high level code to maintain and render the glyphs into the pre-allocated large bitmap. Also I have been wondering about the accelerated anti-aliased text. Is all anti-aliased text in XFree86 done via the XRENDER extension and alpha blits? It is possible to implement accelerated anti-aliased text using simple 4-8 levels of mono bitmap blits using FreeType (that is what we used for it in our MGL graphics library). Yes, all AA text is done with the Render glyph operations which are defined in terms of the basic image composition primitive. Once you have hardware acceleration for image compositing, that's going to be a lot faster than any non-standard rendering path. Granted, if you have hardware alpha blits that will be the fastest way to do this. But if you don't have hardware alpha blits (and lots of cards supported by XFree86 do not), you can still speed up anti-aliased text quite a lot by using a 4 or 8 level scheme using multiple mono bitmaps. Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
Around 11 o'clock on Feb 27, Kendall Bennett wrote: So fast, efficient text could be done in XFree86 if a single function was used to transfer an entire bitmap in the driver code (pre-clipping could easily be done before the driver code is called), and some high level code to maintain and render the glyphs into the pre-allocated large bitmap. That's how Render does text today, except that it allocates the temporary bitmap on the fly (which isn't a big deal with modern malloc implementations). Monochrome bitmaps the size of the screen are one thing, but 32bpp bitmaps at screen size are a bit large to keep around for this purpose (yes, Render glyphs really are 32bpp on LCD screens). Granted, if you have hardware alpha blits that will be the fastest way to do this. But if you don't have hardware alpha blits (and lots of cards supported by XFree86 do not), you can still speed up anti-aliased text quite a lot by using a 4 or 8 level scheme using multiple mono bitmaps. I suppose, but it wouldn't be compatible with the Render semantics. If I'd heard users complaining about text performance, I'd be more interested. Plus, the number of users with cards that can't support image compositing is rapidly declining; essentially any card that has even the smallest amount of acceleration for 3D graphics can accelerate Render. -keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
On Thu, 27 Feb 2003, Kendall Bennett wrote: Keith Packard [EMAIL PROTECTED] wrote: I think the interfaces currently provided by XAA will probably remain usable, so you might as well implement them. Ok. Plus, we should have XAA expose special higher level functions for glyph rendering to the driver so that the graphics card can use the higher level data structures to speed this operation, rather than having the MI layer break the text operation into a (long) sequence of primitive Composite operations. What are you guys talking about? XAA already has hooks all over the place. Yes, most definitely. The current mechanism is not exactly efficient, and in fact is the reason why I want to hook some functions at a higher level so we can make this faster. Also when it comes to rendering text, one of the fastest ways of doing this is the way that OS/2 does it. Instead of caching any glyphs in offscreen video memory (terribly wasteful of offscreen video memory and no faster than using system memory bitmaps), you maintain a single large bitmap that matches the physical resolution of the screen (ie: 1280x1024 mono bitmap). When you need to draw text, you render the text into the mono bitmap in software at the necessary place on the screen, and when that is done pass the entire bitmap to be drawn to the hardware with a clip rectangle that covers just the text you just rendered into the bitmap. The clipping is real easy to do in the software setup stages for text rendering, and then you can blit the entire string to the hardware in one shot. XAA already does this!!! XAA has never cached glyphs in video ram. So fast, efficient text could be done in XFree86 if a single function was used to transfer an entire bitmap in the driver code (pre-clipping could easily be done before the driver code is called), and some high level code to maintain and render the glyphs into the pre-allocated large bitmap. Also I have been wondering about the accelerated anti-aliased text. Is all anti-aliased text in XFree86 done via the XRENDER extension and alpha blits? It is possible to implement accelerated anti-aliased text using simple 4-8 levels of mono bitmap blits using FreeType (that is what we used for it in our MGL graphics library). Yes, all AA text is done with the Render glyph operations which are defined in terms of the basic image composition primitive. Once you have hardware acceleration for image compositing, that's going to be a lot faster than any non-standard rendering path. That's why XAA hooks Glyphs and doesn't do it that way. XAA does not break glyph rendering into the Composite operator. Granted, if you have hardware alpha blits that will be the fastest way to do this. But if you don't have hardware alpha blits (and lots of cards supported by XFree86 do not), you can still speed up anti-aliased text quite a lot by using a 4 or 8 level scheme using multiple mono bitmaps. No you can't. This text is ALPHA BLENDED into whatever the background is. It is not text ImageText - ie. it is not an alpha blended string on top of a solid backing rectangle. Mark ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
Mark Vojkovich [EMAIL PROTECTED] wrote: What are you guys talking about? XAA already has hooks all over the place. Yes, it does! Now that I am learning more about this I am happy to see that someone saw fit to make it so XAA drivers can hook stuff at many levels. Very cool. It should be better documented though ;-) XAA already does this!!! XAA has never cached glyphs in video ram. Hmm, then how come in the XAA driver architecture there are methods to do mono blits from offscreen video memory? I just assumed that this meant the glyphs were being cached in offscreen video memory, but perhaps XAA is just using offscreen memory as a temporary 'ping ping' buffer in this case? Ie: for hardware that can't do system blits but can do blits from offscreen video memory? Granted, if you have hardware alpha blits that will be the fastest way to do this. But if you don't have hardware alpha blits (and lots of cards supported by XFree86 do not), you can still speed up anti-aliased text quite a lot by using a 4 or 8 level scheme using multiple mono bitmaps. No you can't. This text is ALPHA BLENDED into whatever the background is. It is not text ImageText - ie. it is not an alpha blended string on top of a solid backing rectangle. True. The way we implement in our library is that the core of the text glyphs (ie: the non-blended solid pixels) are drawn with a fast mono blit. Then we render the 4 levels of aliasing into the framebuffer with high speed software blending only for the pixels that need to be drawn (usually only 5% coverage for a typical sized glyph). Doing it that way is still *way* faster than drawing the entire glyph with software blending if you don't have hardware compositing. Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
Keith Packard [EMAIL PROTECTED] wrote: So fast, efficient text could be done in XFree86 if a single function was used to transfer an entire bitmap in the driver code (pre-clipping could easily be done before the driver code is called), and some high level code to maintain and render the glyphs into the pre-allocated large bitmap. That's how Render does text today, except that it allocates the temporary bitmap on the fly (which isn't a big deal with modern malloc implementations). Monochrome bitmaps the size of the screen are one thing, but 32bpp bitmaps at screen size are a bit large to keep around for this purpose (yes, Render glyphs really are 32bpp on LCD screens). Right, but I wasn't talking about RENDER in this case but the standard case of aliased text. Then again I imagine if there is a choice between aliased and anti-aliased text, no-one would want the aliased version anymore so performance is not important ;-) And yes, 32bpp bitmaps would be a little too large to keep around. Besides, the primary reason to keep large mono bitmaps around is because it makes it easier to render the text due to the packed bits in mono bitmaps. 32bpp is much easier to handle with bitmaps just the size of the text due to one pixel per DWORD ;-) Granted, if you have hardware alpha blits that will be the fastest way to do this. But if you don't have hardware alpha blits (and lots of cards supported by XFree86 do not), you can still speed up anti-aliased text quite a lot by using a 4 or 8 level scheme using multiple mono bitmaps. I suppose, but it wouldn't be compatible with the Render semantics. If I'd heard users complaining about text performance, I'd be more interested. Plus, the number of users with cards that can't support image compositing is rapidly declining; essentially any card that has even the smallest amount of acceleration for 3D graphics can accelerate Render. Very true, but if you consider the fact that right now there is only one graphics driver in XFree86 that actually has the composting functions enabled (excluding closed NVIDIA drivers), the multi-level scheme could accelerate anti-aliased text on a lot of hardware instantly. Then when people get the time, the composting functions could be implemented to make it better and faster where applicable. Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
On Thu, 27 Feb 2003, Kendall Bennett wrote: Mark Vojkovich [EMAIL PROTECTED] wrote: What are you guys talking about? XAA already has hooks all over the place. Yes, it does! Now that I am learning more about this I am happy to see that someone saw fit to make it so XAA drivers can hook stuff at many levels. Very cool. It should be better documented though ;-) I think there are very few reasons to hook stuff at higher levels. I don't believe you have a reason to do so. XAA already does this!!! XAA has never cached glyphs in video ram. Hmm, then how come in the XAA driver architecture there are methods to do mono blits from offscreen video memory? I just assumed that this meant the glyphs were being cached in offscreen video memory, but perhaps XAA is just using offscreen memory as a temporary 'ping ping' buffer in this case? Ie: for hardware that can't do system blits but can do blits from offscreen video memory? Mono blits from offscreen are only used for cached stipples. If the driver supports these it is the prefered method for stippling. Otherwise XAA will fall back to transparent blits from the pixmap cache or CPUToScreenColorExpansion. XAA's catch-all for non-AA text rendering renders each glyph with WriteBitmap. If the driver didn't provide WriteBitmap, XAA would provide one that used the driver's CPUToScreenColorExpansion routines. If the conditions were appropriate XAA would pre-composite the whole string and pass the result as a single bitmap. These conditions are that no glyph is more than 32 pixels wide (it's optimized to expect it to fit in one DWORD) and the rop is such that it doesn't matter if glyphs overlap (if the rop it XOR, for example, overlapping characters are supposed to XOR each other and a pre-composited string would be incorrect if it contained overlapping characters). The result is that essentially all rendering of proportional fonts goes through that path. Furthermore, for fixed fonts, XAA has scanline renderers that each glyph width up to 32 pixels. The benchmark cases are written in assembly. In this case it doesn't have to composite into a scratch buffer. I renders directly to the target surface. Note that with the Scanline CPUToScreenColorExpand routines, XAA can render directly into your graphics engine's DMA command buffer. I don't think you'll be able to write non-AA code that renders quicker than XAA, but you'll certainly risk rendering it incorrectly. For AA fonts you can hook the top level through XAAInfoRec.Glyphs. If you don't provide that level XAA will provide one for you which will optimize the 1 bit alpha glyphs, but will fall through to the mi routines for everything else. Mi will composite the glyphs into a single Picture and pass it through to the Composite operator and you'll have another chance to accelerate it at that time. XAA only provides two low-level Render-related primitives. The 8 bit Alpha texture + color and the Generic color texture composite functions. It's difficult to abstract things much beyond that since different graphics engines diverge quite a bit at this level. XAA 3 (XFree86 5's XAA) doesn't even try. It's only got the 8 bit alpha low-level primitive and everything else is higher level where the driver is expected to do alot more, though I suppose much of it could be offloaded to helper functions. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
On Thu, 2003-02-27 at 14:42, Keith Packard wrote: Granted, if you have hardware alpha blits that will be the fastest way to do this. But if you don't have hardware alpha blits (and lots of cards supported by XFree86 do not), you can still speed up anti-aliased text quite a lot by using a 4 or 8 level scheme using multiple mono bitmaps. I suppose, but it wouldn't be compatible with the Render semantics. If I'd heard users complaining about text performance, I'd be more interested. Plus, the number of users with cards that can't support image compositing is rapidly declining; essentially any card that has even the smallest amount of acceleration for 3D graphics can accelerate Render. Actually, we get a fair number of complaints about AA-gnome-terminal speed, though some of that is just bugs in gnome-terminal that have now been fixed. But the software side could be made many times faster; especially considering that gnome-terminal is almost always text-on-constant background. And text-on-constant background should possible to make as fast as PCI/AGP write bandwidth. (*) (A lot slower than hardware compositing, but not remotely slow.) Regards, Owen (*) There are two levels of server-side optimization you can do for text-on-constant-background. a) If you keep track of the fact that a Pixmap is constant color, you can migrate from video ram to system ram about 100x faster than actually copying the data. Compositing system-ram-to-system-ram is fast. b) If you keep track of the fact that a Pixmap is constant color, you could have special-cased compositing routines that avoid even having to read the destination image. But this involves yet more paths in the compositing code. (Yuck.) This one is also harder to properly handle for the multiple-write case. You'd probably have to keep track of a constant-color _region_. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
Mark Vojkovich [EMAIL PROTECTED] wrote: We do. We have our own device driver abstraction layer and using the low level XAA functions does not map at all well to our driver modle. Hence hooking at the next level up (MID) will allow us to avoid the overheads of translating between the low level XAA model and our driver model. I forgot that you had your own driver API that you were translating to. ;-) Hooking WriteBitmap is reasonable to handle the proportional fonts. For fixed fonts you can replace the TEGlyph renderer and have it use the existing glyph_scanline_func[width - 1] to render into a scratch bitmap. See the XAATEGlyphRenderer for an example. Awesome, I will take a look at that. Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
On Thu, Feb 27, 2003 at 05:01:19PM -0500, Owen Taylor wrote: (*) There are two levels of server-side optimization you can do for text-on-constant-background. Well, we can start with even more simple optimizations, like not doing the compositing when the clip region is empty. Currently if you unmap a vte window that is doing lots of Xtf antialiased text drawing, the X server is spending tons of time doing compositing that is just thrown away. http://fontconfig.org/cgi-bin/bugzilla/show_bug.cgi?id=29 Cheers, Matt [EMAIL PROTECTED] -- Matt Wilson Manager, Base Operating Systems Red Hat, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
Around 23 o'clock on Feb 27, Matt Wilson wrote: Well, we can start with even more simple optimizations, like not doing the compositing when the clip region is empty. Yeah, that would help in some cases. One does have to be careful to keep backing store working though. -keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
Kurt Wall [EMAIL PROTECTED] wrote: Feigning erudition, Kendall Bennett wrote: % Hi Guys, % % Is thete any documentation on the XRENDER extension and more specifically % the Matrox implementation of it? Do any other drivers other than the % Matrox driver implement this extension? http://www.xfree86.org/~keithp/render/ $XFREE86ROOT/lib/X11/doc/render-protocol.txt Awesome, thanks! That gives a bit more information, but it doesn't really describe how the XAA drivers can accelerate the XRENDER extension. It seems the Matrox driver is the only one that can do this so far, so I guess we will just look at the Matrox driver source code. Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
