Why run xserver on the OpenGL API?
Marcelo E. Magallon
mmagallo@debian.org
Sun, 4 Jan 2004 17:12:35 -0600
On Sat, Jan 03, 2004 at 11:55:26PM -0800, Allen Akin wrote:
> For some reason I didn't receive Keith's message, so pardon me if
> this has already been discussed.
you probably didn't, I was playing catch up with the last six weeks'
worth of email or so... the message I replied to was pretty old.
> All the hardware-design and standardization effort is going into the
> programmable pipeline, which is certainly capable of accelerating
> things like plane masks and per-component alpha. (Don't know about
> conjoint/disjoint compositing operators; haven't looked closely at
> the definition.)
I was trying to avoid the "but this can be done with a fragment
program" mantra :-)
Besides...
Logic operations (bitwise operations) are not supported by the current
ARB_fragment_program specification. I can't recall if the SLang spec
says something about it.
I've heard some concerns (from hardware vendors) regarding transistor
count/performance/need of a programmable blending unit. Last I heard
"it's not going to happen soon". As you might recall, the early SLang
specifications included the framebuffer as a _read-write_ variable, not
as a write-only variable even if it contained a huge "this is slow, ok?
If you use it, don't complain" warning all over it. This was kicked
out as a result of ARB meetings. ATI's/ARB's answer to the people with
this need (yes, we exist) is super buffers. As I understand it their
standpoint is "if you need something like this, multipass", IOW render
to a buffer and then bind that buffer to a texture, which you use for
further rendering to a different buffer. Actually, it'd be _really_
cool (and enough) if you could just output the factors for the blending
equation from a fragment program.
Per-component alpha... ouch... now that I read this again... you want
an 4-component blending factor which is not constant across a
primitive? Hmm... what for? (I'm not against it, just curious). With
blend_func_separate you have one factor for RGB and one function for
alpha, for both src and dst. The reason behind that, as I understand
it, is premultiplied-alpha without having to premultiply alpha. That's
what I use it for anyways...
Re: conjoint/disjoint operators? Keith, can you give a reference? I
stupidly assumed you were talking about something else, but know that I
have looked it up, I can't find it. And looking at the source code I
don't understand what's going on.
Marcelo