Ian Romanick wrote:
> I'd like to propose a couple changes to our current GL and GLX extension
> policies.
>
> GL
> ==
>
> There are a few GL extensions that I believe should just be made
> mandatory. Doing so would allow us to remove a ton of extension tests
> sprinkled throughout the code. The proposed extensions all provide ways
> to expose the extension without requiring additional hardware
> functionality. Enabling the extension just makes the API available.
> Here is my proposed list:
>
> - GL_ARB_draw_buffers - We'd have to change the default MaxDrawBuffers
> to 1 in context.c. Currently only the i965 driver enables this
> extension. I believe that swrast should have this extension listed
> because it supports GL 2.0.
>
> - GL_ARB_multisample - If the driver doesn't support multisampling, it
> can just not expose any multisample visuals. Only swrast and unichrome
> do not export this extension. I believe that swrast should have this
> extension listed because it supports GL 2.0.
>
> - GL_ARB_vertex_buffer_object - The only driver that doesn't export this
> extension is swrast. I believe that swrast should have this extension
> listed because it supports GL 1.4.
>
> - GL_ARB_vertex_program - For hardware that uses software for TNL, Mesa
> does all the work. For hardware that has only fixed-function TNL,
> vertex programs act like a TNL software fallback. Only i810, mach64,
> r128, radeon, savage, and sis do not support this extension. I believe
> that GL_NV_vertex_program and GL_NV_vertex_program1_1 should also be
> enabled. The expose nearly the same feature set as the ARB extension.
>
> - GL_ARB_texture_compression - Currently only mach64, swrast, and
> unichrome do not export this extension. I believe that swrast should
> have this extension listed because it supports GL 1.3.
>
> - GL_EXT_gpu_program_parameters - This convenience extension is handled
> completely in Mesa when GL_ARB_{vertex,fragment}_program is supported.
> The only drivers that do export this extension are mga, r300, and
> swrast.
>
> - GL_{EXT,SUN}_multi_draw_arrays - This functionality is handled
> completely inside Mesa. Currently, i810, mach64, r128, radeon, savage,
> sis, swrast, and unichrome do not export this extension. I believe that
> swrast should have this extension listed because it supports GL 1.4.
>
> - GL_IBM_multimode_draw_arrays - Same logic as above. The only drivers
> that do export this extension are swrast and tdfx.
>
> GLX
> ===
>
> I believe that we should enable GLX_SGIX_pbuffer by default. Drivers
> that do not support pbuffer rendering can just not export any fbconfigs
> with GLX_PBUFFER_BIT set. We already do this for GLX_ARB_multisample
> and GLX_OML_swap_method. This will allow drivers that already support
> GLX_SGIS_make_current_read to expose GLX 1.4.
>
> I believe the we should also add the trivial support required for
> GLX_ARB_color_buffer_float (and the ATI & NV extensions). Again,
> drivers that don't support floating point rendering (or don't have an
> appropriate license, I guess...I'm not a lawyer, and I'm not giving
> legal advice) just won't export any fbconfigs with the
> GLX_RGBA_FLOAT_BIT set.
This all sounds pretty good to me, Ian. Though, I share Roland's
concern about vertex program. Perhaps we could make that change
temporarily and see what issues pop up.
BTW, I was thinking of yanking out some older extensions such as
SGIX_shadow, SGIX_shadow_ambient, SGIX_depth texture which are
superceded by ARB extensions. Sound good?
-Brian
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
