| Age | Commit message (Collapse) | Author |
|---|
|
eliminates various "3D driver claims to not support visual" messages in
16-bit color mode.
|
|
|
|
Main driver impacts:
- new code for creating the Mesa GLframebuffer
- new span/pixel read/write code
Some drivers not yet updated/tested.
|
|
* GL_ARB_texture_cube_map
* GL_EXT_blend_equation_separate
* GL_ATI_blend_equation_separate
* GL_ARB_point_parameters
* GL_NV_blend_square
* GL_EXT_cull_vertex
* GL_ARB_depth_texture
* GL_SGIX_depth_texture
* GL_ARB_shadow
* GL_EXT_shadow_funcs
* GL_3DFX_texture_compression_FXT1
(Keith Whitwell, Tungsten Graphics)
|
|
|
|
|
|
|
|
(patented) S3TC/DXTC algorithms, but adds an option to dlopen a library module
providing functions to do so. Because it uses dlopen, it is only enabled if
USE_EXTERNAL_DXTN_LIB=1 is defined (which is only in linux-dri config, so far).
It adds support for S3TC to several DRI drivers, and adds a DRI config option to
force enabling S3TC even if the software compression/decompression is
unavailable. This may allow people to use apps that require S3TC even though
they don't have a license to implement the patented material themselves, if
those apps use precompressed textures.
Ideally we would get permission from the current holder of the patents to
implement the algorithm in Mesa, at which point the dlopen mess could go away.
Until then, this allows some to run applications they couldn't otherwise, and
hopefully will provide us with more push to get the final step of getting that
permission done.
|
|
|
|
|
|
uses the NEW_INTERFACE now so _SOLO isn't necessary anymore.
Tested with the hardware that I own.
|
|
|
|
|
|
|
