Re: Why run xserver on the OpenGL API?

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