GLX_EXT_texture_from_pixmap

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lukas Hejtmanek wrote:

> Thanks for the explanation. However, GLX extensions look like this:
> GLX extensions:
>     GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
>     GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
>     GLX_MESA_swap_control, GLX_MESA_swap_frame_usage,
>     GLX_OML_swap_method,
>     GLX_SGI_make_current_read, GLX_SGI_video_sync,
>     GLX_SGIS_multisample,
>     GLX_SGIX_fbconfig
> 
> And GLX_EXT_tfp is not listed here. Is it a bug or am I something missing? (this
> is X.org + AIGLX, not Xgl).

I think it may be a bug.  Right now GLX_EXT_tfp is listed as "{Y, N, N,
N}" in glxextensions.c.  This means that if direct rendering is
available, the client library, the server, and the direct rendering
driver all have to support the extension.  However, the code that
implements the functions for GLX_EXT_tfp all return errors when direct
rendering is actually enabled.

This leads me to believe the GLX_EXT_tfp doesn't depend on the direct
rendering driver at all.  I think the correct setting for it in
glxextensions.c is "{Y, Y, N, N}".  That will cause it to be enabled if
the client library and server support it, regardless of what the direct
rendering driver says.

James, David: Does that sound right to you?

> And what about OpenGL extensions? Are these extensions handled by Mesa library
> and some of them can be SW instead of HW accelerated?

It's the same sort of deal was with GLX extensions.  Mesa doesn't
necessarilly have anything to do with it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFEQ7/VX1gOwKyEAw8RAtRuAKCc3nqo/EQ/KfleFoO6FWF9JZgBugCfSk8/
Qkk1jZ/mggy0h2yROA8k8CQ=
=h6P0
-----END PGP SIGNATURE-----