interpreting glxinfo's output

[KAMALNEET SINGH]

andrew rader wrote:
> On Wed, Mar 26, 2008 at 5:15 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
>> On Wed, Mar 26, 2008 at 5:13 PM, andrew rader <andrew.r.rader at gmail.com> wrote:
>>> thanks for the fast reply,
>>>
>>>  that does indeed answer my question, with one additional question. The
>>>  last post has the general extension list described:
>>>
>>>  "general: and that's the resulting supported GLX extensions, depending
>>>  what the server and client sides support."
>>>
>>>  would it be better to just say "general is a list of the extensions
>>>  that the driver supports"? since both the client and server (in my
>>>  case) support TFP, but "general" doesn't, is it the driver that is
>>>  missing this extension?
>> Actually, it's all three (this just came up the other day): client and
>> server both handle the protocol and the driver implements it.
>>
>> --
>> Dan
>>
> 
> ah ok, so in my case the server/client are both saying "we can support
> drivers that provide the TFP extension" but my driver doesn't support
> it, so I can't use it (unless I use indirect method mentioned
> already).
> 
> does LIBGL_ALWAYS_INDIRECT=1 cause a different driver to be used, one
> that does implement TFP?

It is the same driver that is used for both direct and indirect 
rendering. The issue may be that the pixmap is in server's memory, and 
accessing it from client via direct rendering requires a more 
complicated mechanism, which isn't there yet(at least in the released 
versions AFAIK).

The glxinfo output means that your client and server do support the 
extension with the active driver. But u need to go through the server 
for that! And that is indirect rendering. At least theoretically, with 
AIGLX or XGL, it shouldn't be much slower than direct. And for an 
application like compositing window manager, it should make a negligible
difference. xcompmgr also works in an ''indirect'' fashion, there is no 
way to do XRender ''directly'' :-)

~kammal