RE: Another Render question
On Tue, 27 Jan 2004, Sottek, Matthew J wrote: > > I didn't remove anything. There was never any support for > >componentAlpha. I just made XAA aware that it didn't support > >it. > > You removed the ability for a driver to support accelerated component > alpha on a XFree 4.4.0 binary. If this is now the most common case > then why wouldn't a driver want the opportunity to support that? Seems > like the driver should be required to punt that rather than Xaa punting > for them. There was never a way for the driver to know that componentAlpha was used. I removed the ambiguity. Now, if you get masks that have RGB components, the RGB components are to be ignored. It could have been defined either way: componentAlpha or non-componentAlpha. I don't know if componentAlpha is the more common case, but I think that drivers are less likely to be able to accelerate it than they are non-componentAlpha, so being able to support componentAlpha seems better suited to the exception rather than the rule. We can always add to the flags as Thomas and I discussed. Not sure that we want to squeeze that into 4.4 though. Mark. > > Looking at the XAADoComposite function, it isn't very large so a > driver could just hook at that level and pull a copy of that function > into the driver minus the component alpha check and be able to support > accelerated component alpha. There also seems to be a check that > punts anything with a transform which also eliminates a large number > of useful RENDER cases. (Do all stretches have a transform?) > Seems like a driver that wanted to support RENDER well would have > to hook at the Composite level currently so it isn't really a big > deal that component alpha doesn't get passed through to the driver. > > There still remains the issue of why would the newer font libs > use component alpha when that removes all opportunity for > acceleration. Is there a way for the libs to determine that > component alpha is an unaccelerated path? > > -Matt > > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Another Render question
> I didn't remove anything. There was never any support for >componentAlpha. I just made XAA aware that it didn't support >it. You removed the ability for a driver to support accelerated component alpha on a XFree 4.4.0 binary. If this is now the most common case then why wouldn't a driver want the opportunity to support that? Seems like the driver should be required to punt that rather than Xaa punting for them. Looking at the XAADoComposite function, it isn't very large so a driver could just hook at that level and pull a copy of that function into the driver minus the component alpha check and be able to support accelerated component alpha. There also seems to be a check that punts anything with a transform which also eliminates a large number of useful RENDER cases. (Do all stretches have a transform?) Seems like a driver that wanted to support RENDER well would have to hook at the Composite level currently so it isn't really a big deal that component alpha doesn't get passed through to the driver. There still remains the issue of why would the newer font libs use component alpha when that removes all opportunity for acceleration. Is there a way for the libs to determine that component alpha is an unaccelerated path? -Matt ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another Render question
Mark Vojkovich wrote: On Mon, 26 Jan 2004, Thomas Winischhofer wrote: Sottek, Matthew J wrote: a) is used for aa text; however, sometimes (haven't yet found out why) the alphaType argument to this is not PICT_a8 as one would expect, but PICT_a8r8g8b8. I don't quite get the logic behind this. What's the CPUToScreenTexture hook for if CPUToScreenAlphaTexture should be able to deal with ARGB textures? And how should the "red", "green" and "blue" arguments correlate with the RGB contents of this odd texture? a) Is used whenever you want to combine a per-pixel alpha with a diffuse color. Text, as you said is the common case but I think there were other intentions... I've seen some screenshots on Keith's site that show using a window's own alpha channel as a drop shadow. In order for that to work you would need to get an argb input (the offscreen copy of the full window contents) but only use the "a" and use the diffuse rgb as provided. Maybe that is the intended use? Hm. I _think_ we're talking about the same thing. However, my (second) question was more meant in the line of the following: I am given a constant r, g and b as each a separate parameter, and an You are also given "a". a8r8g8b8 texture which by Mark's explanation is for providing an alpha value for each of the r, g, b components. But the format is _a8_r8g8b8; No, it modulates r, g, b, and a. if the components' alphas are in the r8g8b8 part, what's to happen with the a8 part of that texture? You are given constant a, r, g, b. An a8 texture modulates all of them: ... unless XAA_RENDER_NO_SRC_ALPHA is set...? a *= a8 ... in which case the above does not apply...? r *= a8 g *= a8 b *= a8 Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Another Render question
On Mon, 26 Jan 2004, Sottek, Matthew J wrote: > >I am given a constant r, g and b as each a separate parameter, and an > >a8r8g8b8 texture which by Mark's explanation is for providing an alpha > >value for each of the r, g, b components. But the format is _a8_r8g8b8; > >if the components' alphas are in the r8g8b8 part, what's to happen with > > >the a8 part of that texture? > > I did some reading and Mark's explanation seems correct when > componentAlpha is set the constant r, g, b, and a should be modulated > by the per-pixel r, g, b, and a. > > When componentAlpha is not set then you would be expected, I think, > to just extract the Alpha. That would be consistent with the drop > shadow idea. > > Are you indicating that newer libxrender and libxft will use the > component alpha method? Fedora and RH9 seem to use the PICT_a8 > method. Are the libs moving toward PICT_a8 or toward PICT_a8r8g8b8 > (which one is newer?) > > If the a8r8g8b8 is newer and Mark just removed it, then no drivers > will be able to accelerate the common path until XFree 4.4. Wouldn't > it be better to just let the 2 or 3 drivers that have RENDER > acceleration punt and thereby allow drivers to pick up support > for it before 4.4. I didn't remove anything. There was never any support for componentAlpha. I just made XAA aware that it didn't support it. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Another Render question
>I am given a constant r, g and b as each a separate parameter, and an >a8r8g8b8 texture which by Mark's explanation is for providing an alpha >value for each of the r, g, b components. But the format is _a8_r8g8b8; >if the components' alphas are in the r8g8b8 part, what's to happen with >the a8 part of that texture? I did some reading and Mark's explanation seems correct when componentAlpha is set the constant r, g, b, and a should be modulated by the per-pixel r, g, b, and a. When componentAlpha is not set then you would be expected, I think, to just extract the Alpha. That would be consistent with the drop shadow idea. Are you indicating that newer libxrender and libxft will use the component alpha method? Fedora and RH9 seem to use the PICT_a8 method. Are the libs moving toward PICT_a8 or toward PICT_a8r8g8b8 (which one is newer?) If the a8r8g8b8 is newer and Mark just removed it, then no drivers will be able to accelerate the common path until XFree 4.4. Wouldn't it be better to just let the 2 or 3 drivers that have RENDER acceleration punt and thereby allow drivers to pick up support for it before 4.4. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another Render question
On Mon, 26 Jan 2004, Thomas Winischhofer wrote: > Sottek, Matthew J wrote: > >>a) is used for aa text; however, sometimes (haven't yet found out why) > >>the alphaType argument to this is not PICT_a8 as one would expect, but > >>PICT_a8r8g8b8. > >> > >>I don't quite get the logic behind this. What's the CPUToScreenTexture > >>hook for if CPUToScreenAlphaTexture should be able to deal with ARGB > >>textures? And how should the "red", "green" and "blue" arguments > >>correlate with the RGB contents of this odd texture? > > > > > > a) Is used whenever you want to combine a per-pixel alpha with a > > diffuse color. Text, as you said is the common case but I think there > > were other intentions... > > > > I've seen some screenshots on Keith's site that show using a window's > > own alpha channel as a drop shadow. In order for that to work you > > would need to get an argb input (the offscreen copy of the full > > window contents) but only use the "a" and use the diffuse rgb as > > provided. Maybe that is the intended use? > > Hm. I _think_ we're talking about the same thing. However, my (second) > question was more meant in the line of the following: > > I am given a constant r, g and b as each a separate parameter, and an You are also given "a". > a8r8g8b8 texture which by Mark's explanation is for providing an alpha > value for each of the r, g, b components. But the format is _a8_r8g8b8; No, it modulates r, g, b, and a. > if the components' alphas are in the r8g8b8 part, what's to happen with > the a8 part of that texture? > You are given constant a, r, g, b. An a8 texture modulates all of them: a *= a8 r *= a8 g *= a8 b *= a8 An a8r8g8b8 texture without componentAlpha is the same: a *= mask.a r *= mask.a g *= mask.a b *= mask.a With componentAlpha: a *= mask.a r *= mask.r g *= mask.g b *= mask.b Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another Render question
> On Mon, 26 Jan 2004, Thomas Winischhofer wrote: > > > I do now understand that r, g, b can contain separate alpha values for > > each component (which I easily could support in my driver since I first > > need to build an accelerator-suitable texture anyway). What is supposed > > to happen with the 4th, the a component? Normally you multiply all source components (a,r,g,b) by Mask.a in order to get a new source. With component alpha, you multiply the source components by their corresponding mask components. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another Render question
Sottek, Matthew J wrote: a) is used for aa text; however, sometimes (haven't yet found out why) the alphaType argument to this is not PICT_a8 as one would expect, but PICT_a8r8g8b8. I don't quite get the logic behind this. What's the CPUToScreenTexture hook for if CPUToScreenAlphaTexture should be able to deal with ARGB textures? And how should the "red", "green" and "blue" arguments correlate with the RGB contents of this odd texture? a) Is used whenever you want to combine a per-pixel alpha with a diffuse color. Text, as you said is the common case but I think there were other intentions... I've seen some screenshots on Keith's site that show using a window's own alpha channel as a drop shadow. In order for that to work you would need to get an argb input (the offscreen copy of the full window contents) but only use the "a" and use the diffuse rgb as provided. Maybe that is the intended use? Hm. I _think_ we're talking about the same thing. However, my (second) question was more meant in the line of the following: I am given a constant r, g and b as each a separate parameter, and an a8r8g8b8 texture which by Mark's explanation is for providing an alpha value for each of the r, g, b components. But the format is _a8_r8g8b8; if the components' alphas are in the r8g8b8 part, what's to happen with the a8 part of that texture? Formula, anyone? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another Render question
Mark Vojkovich wrote: What if some hardware supported this? Wouldn't it be better to set a flag in the Flags field submitted to the driver's SetUpCPU...() function? Or/and perhaps let the driver specify a flag in the CPUToScreenAlphaTextureFlags, like XAA_RENDER_COMPONENT? If you want to test that, you can add it, though I'd recommend waiting until after 4.4. I've already checked in code that has XAA bail out when it sees componentAlpha. In order to avoid breaking binary compatibility, you'd need to add a flag to the CPUToScreenAlphaTextureFlags that allows the driver to say that it supports per-component alpha. Otherwise all the current drivers would need to be rewritten to recognize the new flag. That's basically what I meant. I will commit my changes to the sis driver anyway (just adding support for nonComponent a8r8g8b8), but wait with the rest. Thanks. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Another Render question
>a) is used for aa text; however, sometimes (haven't yet found out why) >the alphaType argument to this is not PICT_a8 as one would expect, but >PICT_a8r8g8b8. > >I don't quite get the logic behind this. What's the CPUToScreenTexture >hook for if CPUToScreenAlphaTexture should be able to deal with ARGB >textures? And how should the "red", "green" and "blue" arguments >correlate with the RGB contents of this odd texture? a) Is used whenever you want to combine a per-pixel alpha with a diffuse color. Text, as you said is the common case but I think there were other intentions... I've seen some screenshots on Keith's site that show using a window's own alpha channel as a drop shadow. In order for that to work you would need to get an argb input (the offscreen copy of the full window contents) but only use the "a" and use the diffuse rgb as provided. Maybe that is the intended use? -Matt ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another Render question
On Mon, 26 Jan 2004, Thomas Winischhofer wrote: > Mark Vojkovich wrote: > > On Mon, 26 Jan 2004, Thomas Winischhofer wrote: > > > > > >>Can anyone explain the meaning of a8r8g8b8 "pure" alpha textures? > > > > > >It's probably a bug that XAA is letting those through. > > a8r8g8b8 alpha masks mean one of two things: > > > > 1) If componentAlpha is set, it's 4 alpha masks which act separately > >on the different components of the source. > > > > 2) If componentAlpha is not set, you're supposed to just use the > >alpha portion. > > OK, I see. I didn't analyze the code deeply enough. In my tests, the RGB > portion of the a8r8g8b8 formatted alpha texture was always zero. (Qt in > some way [indirectly] uses this to draw aa text, as does x11perf > -aaXXtest; stangely, I had this accelerated a while back WITHOUT > allowing a8r8g8b8 but ever since I installed Debian's experimental > packages with external libxrender and libxft the accelerated path wasn't > used. Despite that I recompiled these external libs against 4.3 headers.) > > I do now understand that r, g, b can contain separate alpha values for > each component (which I easily could support in my driver since I first > need to build an accelerator-suitable texture anyway). What is supposed > to happen with the 4th, the a component? > > > XAA's render support was written in the early days of render, > > back when render didn't support as much stuff as it does now. > > It probably makes sense for XAA to only pass them through when > > componentAlpha is not set, then it would be up to the driver > > to decide whether or not it can just extract the alpha portion, > > and punt if it doesn't. > > > > We should probably be adding > > > > if(pMask->componentAlpha) > > return FALSE; > > > > right after the if(pMask) test to reject the 4-component alpha > > condition. > > What if some hardware supported this? Wouldn't it be better to set a > flag in the Flags field submitted to the driver's SetUpCPU...() > function? Or/and perhaps let the driver specify a flag in the > CPUToScreenAlphaTextureFlags, like XAA_RENDER_COMPONENT? If you want to test that, you can add it, though I'd recommend waiting until after 4.4. I've already checked in code that has XAA bail out when it sees componentAlpha. In order to avoid breaking binary compatibility, you'd need to add a flag to the CPUToScreenAlphaTextureFlags that allows the driver to say that it supports per-component alpha. Otherwise all the current drivers would need to be rewritten to recognize the new flag. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another Render question
Mark Vojkovich wrote: On Mon, 26 Jan 2004, Thomas Winischhofer wrote: Can anyone explain the meaning of a8r8g8b8 "pure" alpha textures? It's probably a bug that XAA is letting those through. a8r8g8b8 alpha masks mean one of two things: 1) If componentAlpha is set, it's 4 alpha masks which act separately on the different components of the source. 2) If componentAlpha is not set, you're supposed to just use the alpha portion. OK, I see. I didn't analyze the code deeply enough. In my tests, the RGB portion of the a8r8g8b8 formatted alpha texture was always zero. (Qt in some way [indirectly] uses this to draw aa text, as does x11perf -aaXXtest; stangely, I had this accelerated a while back WITHOUT allowing a8r8g8b8 but ever since I installed Debian's experimental packages with external libxrender and libxft the accelerated path wasn't used. Despite that I recompiled these external libs against 4.3 headers.) I do now understand that r, g, b can contain separate alpha values for each component (which I easily could support in my driver since I first need to build an accelerator-suitable texture anyway). What is supposed to happen with the 4th, the a component? XAA's render support was written in the early days of render, back when render didn't support as much stuff as it does now. It probably makes sense for XAA to only pass them through when componentAlpha is not set, then it would be up to the driver to decide whether or not it can just extract the alpha portion, and punt if it doesn't. We should probably be adding if(pMask->componentAlpha) return FALSE; right after the if(pMask) test to reject the 4-component alpha condition. What if some hardware supported this? Wouldn't it be better to set a flag in the Flags field submitted to the driver's SetUpCPU...() function? Or/and perhaps let the driver specify a flag in the CPUToScreenAlphaTextureFlags, like XAA_RENDER_COMPONENT? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another Render question
On Mon, 26 Jan 2004, Thomas Winischhofer wrote: > Can anyone explain the meaning of a8r8g8b8 "pure" alpha textures? It's probably a bug that XAA is letting those through. a8r8g8b8 alpha masks mean one of two things: 1) If componentAlpha is set, it's 4 alpha masks which act separately on the different components of the source. 2) If componentAlpha is not set, you're supposed to just use the alpha portion. XAA's render support was written in the early days of render, back when render didn't support as much stuff as it does now. It probably makes sense for XAA to only pass them through when componentAlpha is not set, then it would be up to the driver to decide whether or not it can just extract the alpha portion, and punt if it doesn't. We should probably be adding if(pMask->componentAlpha) return FALSE; right after the if(pMask) test to reject the 4-component alpha condition. Mark. > > The two hooks for render acceleration are > > a) CPUToScreenAlphaTexture (should be PICT_a8) > b) CPUToScreenTexture (like eg PICT_a8r8g8b8) > > a) is used for aa text; however, sometimes (haven't yet found out why) > the alphaType argument to this is not PICT_a8 as one would expect, but > PICT_a8r8g8b8. > > I don't quite get the logic behind this. What's the CPUToScreenTexture > hook for if CPUToScreenAlphaTexture should be able to deal with ARGB > textures? And how should the "red", "green" and "blue" arguments > correlate with the RGB contents of this odd texture? > > I extended RENDER acceleration in the SiS driver now to seemingly > correctly handle such "ARGB alpha textures" textures as well; I simply > ignore the RGB part of an ARGB alpha texture fed to > CPUToScreenAlphaTexture; but my curiousity WRT if this is the idea > behind it remains. > > Thomas > > -- > Thomas Winischhofer > Vienna/Austria > thomas AT winischhofer DOT net *** http://www.winischhofer.net/ > twini AT xfree86 DOT org > > > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another RENDER question
Keith Packard wrote: Around 0 o'clock on Feb 28, Thomas Winischhofer wrote: The hardware I am dealing with does not support ARGB textures (at least not in 2D level, and I don't want to mess with DRI), but "alpha blended bit blits". Using the '3D' hardware needn't entail dealing with DRI. The MGA driver does precisely that for Render acceleration. Alright. That should be possible. Can anyone explain to me what exactly (in the words of common 3D language) the mga driver does? The register setup is totally uncommented in the driver code. I went through my docs for the 3D registers for the hardware I am dealing with (SiS 300 series) and I saw no sort of "command" for just applying a texture mapping or anything similar. I can only define vertices for drawing primitives like triangle, line and point - which is rather complicated, partly because all coordinates are in floating point format. Furtherly, I can define textures (and Z buffers and alpha settings and a lot of other stuff). But it seems the texture mapping is done based on the results of the setup engine (which does the drawing primitives) in the transformation phase. I saw no command for doing a simple transformation without firing the setup engine (ie issueing a drawing primitive) before. Sorry if that sounds rookie-like - fact is I am a rookie on the area of 3D programming. Is there any 3D expert around who could give me a hint? Docs can be provided on request. The difference being: While ARGB textures contain an alpha value for each pixel, the "alpha blended bit blits" render with a static alpha value for all of the bitmap data. It might be of some use; applications can specify this operation through Render with a single-pixel tiled 'mask' operand to composite, but it won't speed up text or geometric operations at all. As Mark pointed out I will save the code I already wrote for features like translucent windows. Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED] *** http://www.winischhofer.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another RENDER question
Around 0 o'clock on Feb 28, Thomas Winischhofer wrote: > The hardware I am dealing with does not support ARGB textures (at least > not in 2D level, and I don't want to mess with DRI), but "alpha blended > bit blits". Using the '3D' hardware needn't entail dealing with DRI. The MGA driver does precisely that for Render acceleration. > The difference being: While ARGB textures contain an alpha value for > each pixel, the "alpha blended bit blits" render with a static alpha > value for all of the bitmap data. It might be of some use; applications can specify this operation through Render with a single-pixel tiled 'mask' operand to composite, but it won't speed up text or geometric operations at all. -keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another RENDER question
On Fri, 28 Feb 2003, Thomas Winischhofer wrote: > The hardware I am dealing with does not support ARGB textures (at least > not in 2D level, and I don't want to mess with DRI), but "alpha blended > bit blits". > > The difference being: While ARGB textures contain an alpha value for > each pixel, the "alpha blended bit blits" render with a static alpha > value for all of the bitmap data. > > Is this hardware capability of any use, be it RENDER or any other XAA > function? Not much in my option. The interesting area is alpha masks. While there are cases in render that you'll be able to accelerate, the semantics of the API are more generic where constant alpha is merely a special case of an alpha mask. Perhaps when we get the translucent window support (XFree86 5 timeframe, I believe) this hardware feature will be easier to expose. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
