Re: [Dri-devel] driver feature table
New columns for gamma, ffb, mach64, virge, sis and trident. Great work! Looks really impressive (and makes me feel really proud that my chip is not the worst one:). A couple of easy questions: is it true that Mach64 feature list is final (sure I do not mean fallback). Also, 3 features are marked as SW - is it good to expose them? It's actually not my question (someone already asked here before). Probably we could make exposition of non-HW-supported features optional (through XF86Config param)? Really, why inform application about things which are going to be slow? Or SW implementation of ARB/EXT_texture_env_* is fast? Regards, Sergey --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
I think I can fill in a few blanks for mach64: Card names: 3D Rage Pro All-in-Wonder Pro Xpert 98/LCD/XL/@Play/@Work 3D Rage LT Pro 3D Rage XL 3D Rage Mobility - No hardware stencil - No mipmapping - BLEND texture env is a software fallback - texture environments which modulate alpha (AtAf) are fallbacks or non-compliant (e.g. RGBA textures with MODULATE environment are non-compliant) Correction: The ARB/EXT_texture_env_[add,dot3,combine] extensions actually are _not_ exported by default. Setting DRI_MACH64_OGL13=1 however will export these extensions and a few others to get glxinfo to report OpenGL 1.3, with the extensions being software fallbacks or no-ops. Extensions which might be doable in hardware, but not currently implemented: - EXT_paletted_texture - not sure about this, but the hardware seems to support a 2K texture palette in RGB 565. - ARB_texture_compression - would need an extension to implement 4:1 VQ texture compression supported by the hardware. On 11 Oct 2002, Sergey V. Udaltsov wrote: New columns for gamma, ffb, mach64, virge, sis and trident. Great work! Looks really impressive (and makes me feel really proud that my chip is not the worst one:). A couple of easy questions: is it true that Mach64 feature list is final (sure I do not mean fallback). Also, 3 features are marked as SW - is it good to expose them? It's actually not my question (someone already asked here before). Probably we could make exposition of non-HW-supported features optional (through XF86Config param)? Really, why inform application about things which are going to be slow? Or SW implementation of ARB/EXT_texture_env_* is fast? Regards, Sergey --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
A couple of additions I forgot: 2D XFree86 Driver: ati_drv.o + atimisc_drv.o - Fog is disabled if alpha blending is enabled. On Fri, 11 Oct 2002, Leif Delgass wrote: I think I can fill in a few blanks for mach64: Card names: 3D Rage Pro All-in-Wonder Pro Xpert 98/LCD/XL/@Play/@Work 3D Rage LT Pro 3D Rage XL 3D Rage Mobility - No hardware stencil - No mipmapping - BLEND texture env is a software fallback - texture environments which modulate alpha (AtAf) are fallbacks or non-compliant (e.g. RGBA textures with MODULATE environment are non-compliant) Correction: The ARB/EXT_texture_env_[add,dot3,combine] extensions actually are _not_ exported by default. Setting DRI_MACH64_OGL13=1 however will export these extensions and a few others to get glxinfo to report OpenGL 1.3, with the extensions being software fallbacks or no-ops. Extensions which might be doable in hardware, but not currently implemented: - EXT_paletted_texture - not sure about this, but the hardware seems to support a 2K texture palette in RGB 565. - ARB_texture_compression - would need an extension to implement 4:1 VQ texture compression supported by the hardware. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
Leif Delgass wrote: A couple of additions I forgot: 2D XFree86 Driver: ati_drv.o + atimisc_drv.o - Fog is disabled if alpha blending is enabled. On Fri, 11 Oct 2002, Leif Delgass wrote: I think I can fill in a few blanks for mach64: Card names: 3D Rage Pro All-in-Wonder Pro Xpert 98/LCD/XL/@Play/@Work 3D Rage LT Pro 3D Rage XL 3D Rage Mobility - No hardware stencil - No mipmapping - BLEND texture env is a software fallback - texture environments which modulate alpha (AtAf) are fallbacks or non-compliant (e.g. RGBA textures with MODULATE environment are non-compliant) Correction: The ARB/EXT_texture_env_[add,dot3,combine] extensions actually are _not_ exported by default. Setting DRI_MACH64_OGL13=1 however will export these extensions and a few others to get glxinfo to report OpenGL 1.3, with the extensions being software fallbacks or no-ops. Extensions which might be doable in hardware, but not currently implemented: - EXT_paletted_texture - not sure about this, but the hardware seems to support a 2K texture palette in RGB 565. - ARB_texture_compression - would need an extension to implement 4:1 VQ texture compression supported by the hardware. Thanks for the updates, Leif. I'll post an update later. I'm thinking that if we rolled the info from the DRI Users Guide into this document we could retire the former (since it's got the old VA copyright). -Brian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
Sergey V. Udaltsov wrote: New columns for gamma, ffb, mach64, virge, sis and trident. Great work! Looks really impressive (and makes me feel really proud that my chip is not the worst one:). A couple of easy questions: is it true that Mach64 feature list is final (sure I do not mean fallback). I basically just grep'd the sources for _mesa_enable_extension() calls to find the extensions. There could certainly be mistakes in the table. Also, 3 features are marked as SW - is it good to expose them? It's actually not my question (someone already asked here before). Probably we could make exposition of non-HW-supported features optional (through XF86Config param)? Really, why inform application about things which are going to be slow? Or SW implementation of ARB/EXT_texture_env_* is fast? I don't think that we can make a blanket statement to cover this. In some cases, exposing extensions, even if they're done in software, is OK. In other cases it's silly. For example, if the hardware lacks stencil, GL_EXT_stencil_wrap might as well be supported by the driver since it's always going to be a software path. On the other hand, there's not much point exposing GL_ARB_texture_cube_map if it's in software since most apps that need it would need it to be fast to be useful. On the other (third) hand, whether or not a feature is implemented in software is not the real issue. The real issue is speed. If an app needs a particular feature to perform at a minimum level it should measure the speed itself and decide if it's fast enough. It's usually the case that hardware features are fast enough, but not always. Finally, even if a driver implements many extensions in hardware, it's always possible that software fallbacks might be needed. For example, glEnable(GL_POLYGON_SMOOTH) or glDrawBuffer(GL_FRONT_AND_BACK) often require software fallbacks. -Brian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
Lots of updates: New columns for gamma, ffb, mach64, virge, sis and trident. New rows for Primary Authors and Operating Sytems. I put question marks where I wasn't sure of what to put. -Brian Summary of DRI driver features: ATI r200 ATI Radeon ATI r128 Intel i810/815 Intel i830/845 Matrox G200/400 3dfx Voodoo3 3dfx Voodoo5 3DLabs gamma Sun FFB ATI Mach64 S3 Virge SIS ? Trident Cards Radeon 8500, 8700 Radeon 7x00 Rage Fury/Pro/Magnum, XPERT 2000, XPERT 128, XPERT 99, All-in-Wonder 128 i810/815 chipsets i830/845 chipsets Millenium G200, G400, G450, Mystique G200 Voodoo3, Banshee, Velocity 100/200 Voodoo4 4500, Voodoo5 5500 Oxygen GMX 2000 Sun Creator, Creator3D card names? card names? card names? Trident CyberBladeXP Primary Authors Tungsten Graphics VA Linux, Tungsten Graphics Precision Insight, VA Linux Precision Insight, VA Linux 2D/3D, others Precision Insight, VA Linux Precision Insight, VA Linux Precision Insight, VA Linux Precision Insight Red Hat Leif Delgass, Jose Fonseca Max Lingua SIS Alan Hourihane Operating Systems Linux, FreeBSD Linux, FreeBSD Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Intel/AMD x86 YES (AGP only) YES (AGP only) YES YES YES YES YES YES YES YES YES YES YES YES DEC Alpha YES YES YES no no no YES YES no no no no no no PowerPC untested YES YES no no untested untested untested no no no no no no Driver Name r200_dri.so radeon_dri.so r128_dri.so i810_dri.so i830_dri.so mga_dri.so tdfx_dri.so tdfx_dri.so gamma_dri.so ffb_dri.so mach64_dri.so s3v_dri.so sis_dri.so trident_dri.so Kernel Module radeon.o radeon.o r128.o i810.o i830.o mga.o tdfx.o tdfx.o gamma.o ? mach64.o s3v.o ? sis.o ? trident.o ? 2D XFree86 Driver radeon_drv.o radeon_drv.o r128_drv.o i810_drv.o i810_drv.o mga_drv.o tdfx_drv.o tdfx_drv.o gamma_drv.o ? sunffb_drv.o ?? s3virge_drv.o ?? ?? Hardware Stencil YES (@32bpp) YES (@32bpp) YES (@32bpp) no YES (@32bpp) YES (@32bpp) no YES (@32bpp) no YES (bpp?) ? ? YES (bpp?) no Hardware Alpha Channel YES (@32bpp) YES (@32bpp) no no YES (@32bpp) YES (@32bpp) no YES (@32bpp) YES (@32bpp) YES (@32bpp) no ? YES (bpp?) no Hardware TCL YES YES no no no no no no YES no no no no no ARB_multitexture (units) YES (2?) YES (2?) YES (2) YES (2) YES (2) YES (G200:1, G400:2) YES (2) YES (2) no no YES (2) no no no ARB_texture_cube_map no no no no no no no no no no no no no no ARB/EXT_texture_env_add YES YES YES YES YES YES YES YES no no YES(sw) no no no ARB/EXT_texture_env_dot3 YES YES no no no no no no no no YES(sw) no no no ARB/EXT_texture_env_combine YES YES no no YES no no YES no no YES(sw) no no no EXT_blend_color no no no no YES no no no no no no no no no EXT_blend_function_separate no no no no YES no no no no no no no no no EXT_blend_logic_op YES YES no no no no no no no no no no no no EXT_blend_min_max YES no no no YES no no no no no no no no no EXT_blend_subtract YES YES no no YES no no no no no no no no no EXT_fog_coord YES YES no no YES no no no no no no no no no EXT_paletted_texture no no no no no no YES YES no no no no no no EXT_secondary_color YES YES no no YES no no no no no no no no no EXT_shared_texture_palette no no no no no no no no no no no no no no EXT_stencil_wrap YES no no YES YES no no YES no no no no no no EXT_texture_filter_anisotropic YES YES no no no no no no no no no no no no EXT_texture_lod_bias YES YES no YES YES no YES YES no no no no no no IBM_texture_mirrored_repeat no YES no no no no no no no no no no no no MESA_pack_invert YES no no no no no no no no no no no no no MESA_texture_ycbcr YES no no no no no no no no no no no no no NV_texture_rectangle YES no no no no no no no no no no no no no SGIS_generate_mipmap no YES no no no YES no no no no no no no no GLX_NV_vertex_array_range YES no no no no no no no no no no no no no OpenGL Extensions enabled in all DRI drivers: GL_ARB_transpose_matrix
Re: [Dri-devel] driver feature table
On Wed, Oct 09, 2002 at 07:57:18AM -0600, Brian Paul wrote:
I've whipped up an HTML table which summarizes the features of the DRI drivers.
Maybe one of the web masters can incorporate it into the website.
Couple quick corrections. I don't think R200 supports
{ARB,IBM}_texture_mirrored_repeat (but it could), but R100 does. Currently,
both the the paletted texture extensions are disabled in the MGA driver. We
should probably also add a note that only AGP Radeons (R100 R200) are
supported on x86. Somebody should probably also add a line for PowerPC.
With regards to SGIS_generate_mipmap, is there any reason we can't enable
that on all hardware? Even for the hardware where it is enabled, it uses
the sw fallback.
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
Ian Romanick wrote:
On Wed, Oct 09, 2002 at 07:57:18AM -0600, Brian Paul wrote:
I've whipped up an HTML table which summarizes the features of the DRI drivers.
Maybe one of the web masters can incorporate it into the website.
Couple quick corrections. I don't think R200 supports
{ARB,IBM}_texture_mirrored_repeat (but it could), but R100 does. Currently,
both the the paletted texture extensions are disabled in the MGA driver. We
should probably also add a note that only AGP Radeons (R100 R200) are
supported on x86. Somebody should probably also add a line for PowerPC.
With regards to SGIS_generate_mipmap, is there any reason we can't enable
that on all hardware? Even for the hardware where it is enabled, it uses
the sw fallback.
But why?
Apps might prefer to have no mipmaps than have them generated by (slow)
software. In this case, advertising the string is misleading.
Apps which want mipmaps regardless will *have* to have a fallback path
themselves, so apps that care will already know how to do this when the
extension isn't advertized.
Overall, this 'false advertising' doesn't aid one class of apps, and confuses
another...
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
Ian Romanick wrote:
On Wed, Oct 09, 2002 at 07:57:18AM -0600, Brian Paul wrote:
I've whipped up an HTML table which summarizes the features of the DRI drivers.
Maybe one of the web masters can incorporate it into the website.
Couple quick corrections. I don't think R200 supports
{ARB,IBM}_texture_mirrored_repeat (but it could), but R100 does. Currently,
both the the paletted texture extensions are disabled in the MGA driver. We
should probably also add a note that only AGP Radeons (R100 R200) are
supported on x86. Somebody should probably also add a line for PowerPC.
Attached is an updated table.
With regards to SGIS_generate_mipmap, is there any reason we can't enable
that on all hardware? Even for the hardware where it is enabled, it uses
the sw fallback.
It think it probably could be enabled in all drivers, but I'd have to check
to be 100% sure.
-Brian
Summary of DRI driver features:
ATI R200
ATI R100
ATI R128
Intel i810/815
Intel i830
Matrox G200/400
Voodoo3
Voodoo5
Cards
Radeon 8500, 8700
Radeon 7x00
Rage Fury/Pro/Magnum, XPERT 2000, XPERT 128, XPERT 99, All-in-Wonder 128
i810/815 chipsets
i830 chipsets
Millenium G200, G400, G450, Mystique G200
Voodoo3, Banshee, Velocity 100/200
Voodoo4 4500, Voodoo5 5500
Intel/AMD x86
YES (AGP only)
YES (AGP only)
YES
YES
YES
YES
YES
YES
DEC Alpha
YES
YES
YES
no
no
no
YES
YES
PowerPC
?
?
?
?
?
?
?
?
Driver Name
r200_dri.so
radeon_dri.so
r128_dri.so
i810_dri.so
i830_dri.so
mga_dri.so
tdfx_dri.so
tdfx_dri.so
Kernel Module
r200.o
radeon.o
r128.o
i810.o
i830.o
mga.o
tdfx.o
tdfx.o
Hardware Stencil
YES (@32bpp)
YES (@32bpp)
YES (@32bpp)
no
YES (@32bpp)
YES (@32bpp)
no
YES (@32bpp)
Hardware Alpha Channel
YES (@32bpp)
YES (@32bpp)
no
no
YES (@32bpp)
YES (@32bpp)
no
YES (@32bpp)
Hardware TCL
YES
YES
no
no
no
no
no
no
ARB_multitexture (units)
YES (2?)
YES (2?)
YES (2)
YES (2)
YES (2)
YES (G200:1, G400:2)
YES (2)
YES (2)
ARB_texture_cube_map
no
no
no
no
no
no
no
no
ARB/EXT_texture_env_add
YES
YES
YES
YES
YES
YES
YES
YES
ARB/EXT_texture_env_dot3
YES
YES
no
no
no
no
no
no
ARB/EXT_texture_env_combine
YES
YES
no
no
YES
no
no
YES
EXT_blend_color
no
no
no
no
YES
no
no
no
EXT_blend_function_separate
no
no
no
no
YES
no
no
no
EXT_blend_logic_op
YES
YES
no
no
no
no
no
no
EXT_blend_min_max
YES
no
no
no
YES
no
no
no
EXT_blend_subtract
YES
YES
no
no
YES
no
no
no
EXT_fog_coord
YES
YES
no
no
YES
no
no
no
EXT_paletted_texture
no
no
no
no
no
no
YES
YES
EXT_secondary_color
YES
YES
no
no
YES
no
no
no
EXT_shared_texture_palette
no
no
no
no
no
no
no
no
EXT_stencil_wrap
YES
no
no
YES
YES
no
no
YES
EXT_texture_filter_anisotropic
YES
YES
no
no
no
no
no
no
EXT_texture_lod_bias
YES
YES
no
YES
YES
no
YES
YES
IBM_texture_mirrored_repeat
no
YES
no
no
no
no
no
no
MESA_pack_invert
YES
no
no
no
no
no
no
no
MESA_texture_ycbcr
YES
no
no
no
no
no
no
no
NV_texture_rectangle
YES
no
no
no
no
no
no
no
SGIS_generate_mipmap
no
YES
no
no
no
YES
no
no
GLX_NV_vertex_array_range
YES
no
no
no
no
no
no
no
OpenGL Extensions enabled in all DRI drivers:
GL_ARB_transpose_matrix
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_clip_volume_hint
GL_EXT_compiled_vertex_array
GL_EXT_packed_pixels
GL_EXT_polygon_offset
GL_EXT_rescale_normal
GL_EXT_texture3D (in software)
GL_EXT_texture_object
GL_EXT_vertex_array
GL_IBM_rasterpos_clip
GL_MESA_window_pos
GL_NV_texgen_reflection
Re: [Dri-devel] driver feature table
Brian Paul wrote: I've whipped up an HTML table which summarizes the features of the DRI drivers. Thanks Brian. Here are some more corrections: 1) Driver headings on top row: It looks like the driver names were based on some common names we throw around when talking about these drivers. Unfortunately, these names can be very confusing as times, so I've tried to generate consistent names using the IHV's name followed by the directory name for the 3D driver. Here is what I got: ATI r200, ATI radeon, ATI r128, Intel i810, Intel i830, Matrox mga, 3Dfx Voodoo3, 3Dfx Voodoo5. Note, I didn't follow my convention for the 3Dfx drivers in that a single source directory generates two different drivers with very different features in your matrix. I think we'll find as time goes on that it's not unusual for a single driver to generate very different results in the matrix depending on the capabilities for the specific hardware. I know there are a few for the G200 vs G400 hardware for example. 2) Cards Row. This is the hardest row to keep up to date. ATI r200 Column: I realize the 8700 has the R200 chipset, but has anybody successfully testing the 8700 or 8900 with the R200 open source driver? ATI r128 Column: Was support for Pro cards ever completed? I know the initial driver did not have it. Intel I830 Column: i845 is also supported, this can be changed to i830/i845 chipsets. Matrox mga Column: Millenium and Mystique are not supported by this driver. G200 is listed twice. 3) Kernel Module Row, ATI R200 Column: There is no r200.o kernel module. This should be radeon.o 4) Added 2D Driver Module Row. Row inverted here for the sake of e-mail: DRI Driver 2D Driver Name ATI r200 radeon_drv.o ATI radeon radeon_drv.o ATI r128 r128_drv.o Intel i810 i810_drv.o Intel i830 i810_drv.o Matrox mga mga_drv.o 3Dfx Voodoo3 tdfx_drv.o 3Dfx Voodoo5 tdfx_drv.o -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
Jens Owen wrote: Brian Paul wrote: I've whipped up an HTML table which summarizes the features of the DRI drivers. Thanks Brian. Here are some more corrections: 1) Driver headings on top row: This was intended to be interpreted as chipsets, not drivers. By that reasoning, I should probably split G200 and G400, but they're pretty similar. It looks like the driver names were based on some common names we throw around when talking about these drivers. Unfortunately, these names can be very confusing as times, so I've tried to generate consistent names using the IHV's name followed by the directory name for the 3D driver. Here is what I got: ATI r200, ATI radeon, ATI r128, Intel i810, Intel i830, Matrox mga, 3Dfx Voodoo3, 3Dfx Voodoo5. Note, I didn't follow my convention for the 3Dfx drivers in that a single source directory generates two different drivers with very different features in your matrix. I think we'll find as time goes on that it's not unusual for a single driver to generate very different results in the matrix depending on the capabilities for the specific hardware. I know there are a few for the G200 vs G400 hardware for example. 2) Cards Row. This is the hardest row to keep up to date. ATI r200 Column: I realize the 8700 has the R200 chipset, but has anybody successfully testing the 8700 or 8900 with the R200 open source driver? ATI r128 Column: Was support for Pro cards ever completed? I know the initial driver did not have it. Pro is listed on DRI Status page: http://dri.sourceforge.net/dri_status.phtml Intel I830 Column: i845 is also supported, this can be changed to i830/i845 chipsets. Matrox mga Column: Millenium and Mystique are not supported by this driver. G200 is listed twice. The product names were Millenium G200, Millenium G400, Mystique 200 etc. Again, I got these from the existing DRI docs. The weird table word wrapping requires very careful reading. 3) Kernel Module Row, ATI R200 Column: There is no r200.o kernel module. This should be radeon.o Fixed. 4) Added 2D Driver Module Row. Row inverted here for the sake of e-mail: DRI Driver 2D Driver Name ATI r200 radeon_drv.o ATI radeon radeon_drv.o ATI r128 r128_drv.o Intel i810 i810_drv.o Intel i830 i810_drv.o Matrox mga mga_drv.o 3Dfx Voodoo3 tdfx_drv.o 3Dfx Voodoo5 tdfx_drv.o Done. Attached is an update. If anyone else wants to make changes, do so, and post a new table.html file. -Brian Summary of DRI driver features: ATI r200 ATI Radeon ATI r128 Intel i810/815 Intel i830/845 Matrox G200/400 3dfx Voodoo3 3dfx Voodoo5 Cards Radeon 8500, 8700 Radeon 7x00 Rage Fury/Pro/Magnum, XPERT 2000, XPERT 128, XPERT 99, All-in-Wonder 128 i810/815 chipsets i830/845 chipsets Millenium G200, G400, G450, Mystique G200 Voodoo3, Banshee, Velocity 100/200 Voodoo4 4500, Voodoo5 5500 Intel/AMD x86 YES (AGP only) YES (AGP only) YES YES YES YES YES YES DEC Alpha YES YES YES no no no YES YES PowerPC ? ? ? ? ? ? ? ? Driver Name r200_dri.so radeon_dri.so r128_dri.so i810_dri.so i830_dri.so mga_dri.so tdfx_dri.so tdfx_dri.so Kernel Module radeon.o radeon.o r128.o i810.o i810.o mga.o tdfx.o tdfx.o 2D XFree86 Driver radeon_drv.o radeon_drv.o r128_drv.o i810_drv.o i810_drv.o mga_drv.o tdfx_drv.o tdfx_drv.o Hardware Stencil YES (@32bpp) YES (@32bpp) YES (@32bpp) no YES (@32bpp) YES (@32bpp) no YES (@32bpp) Hardware Alpha Channel YES (@32bpp) YES (@32bpp) no no YES (@32bpp) YES (@32bpp) no YES (@32bpp) Hardware TCL YES YES no no no no no no ARB_multitexture (units) YES (2?) YES (2?) YES (2) YES (2) YES (2) YES (G200:1, G400:2) YES (2) YES (2) ARB_texture_cube_map no no no no no no no no ARB/EXT_texture_env_add YES YES YES YES YES YES YES YES ARB/EXT_texture_env_dot3 YES YES no no no no no no ARB/EXT_texture_env_combine YES YES no no YES no no YES EXT_blend_color no no no no YES no no no EXT_blend_function_separate no no no no YES no no no EXT_blend_logic_op YES YES no no no no no no EXT_blend_min_max YES no no no YES no no no EXT_blend_subtract YES YES no no YES no no no EXT_fog_coord YES YES no no YES no no no EXT_paletted_texture no no no no no no YES YES EXT_secondary_color YES YES no no YES no no no EXT_shared_texture_palette no no no no no no no no EXT_stencil_wrap YES no no YES YES no no YES EXT_texture_filter_anisotropic YES YES no no no no no
Re: [Dri-devel] driver feature table
On Mit, 2002-10-09 at 15:57, Brian Paul wrote: I've whipped up an HTML table which summarizes the features of the DRI drivers. Here's the data for PowerPC: r200: ? (should basically work, but probably some bugs left) r100: yes r128: yes i8xx: no mga ? (probably doesn't work, but shouldn't be hard to fix) tdfx: ? (probably doesn't work, but shouldn't be hard to fix) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
On Mit, 2002-10-09 at 17:49, Brian Paul wrote: Jens Owen wrote: Brian Paul wrote: ATI r128 Column: Was support for Pro cards ever completed? I know the initial driver did not have it. Pro is listed on DRI Status page: http://dri.sourceforge.net/dri_status.phtml It used to work fine on a Rage128 Pro card here. (It died and was replaced by a Radeon 7500 in the meantime :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
Keith Whitwell wrote:
Ian Romanick wrote:
On Wed, Oct 09, 2002 at 07:57:18AM -0600, Brian Paul wrote:
I've whipped up an HTML table which summarizes the features of the
DRI drivers.
Maybe one of the web masters can incorporate it into the website.
Couple quick corrections. I don't think R200 supports
{ARB,IBM}_texture_mirrored_repeat (but it could), but R100 does.
Currently,
both the the paletted texture extensions are disabled in the MGA
driver. We
should probably also add a note that only AGP Radeons (R100 R200) are
supported on x86. Somebody should probably also add a line for PowerPC.
With regards to SGIS_generate_mipmap, is there any reason we can't enable
that on all hardware? Even for the hardware where it is enabled, it uses
the sw fallback.
But why?
Apps might prefer to have no mipmaps than have them generated by (slow)
software. In this case, advertising the string is misleading.
Apps which want mipmaps regardless will *have* to have a fallback path
themselves, so apps that care will already know how to do this when the
extension isn't advertized.
Overall, this 'false advertising' doesn't aid one class of apps, and
confuses another...
I know you're not crazy about exposing extensions which aren't implemented
in hardware, but I think in this case it would be OK.
- It's an OpenGL 1.4 standard feature
- The s/w implementation is fairly speedy.
- It's an extension that's not used a whole lot
-Brian
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
Brian Paul wrote: If anyone else wants to make changes, do so, and post a new table.html file. Okay. Here's a new file. It contains the following fixes: 1) i830 chipset uses i830 kernel module. 2) Michael's PowerPC support row. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado Summary of DRI driver features: ATI r200 ATI Radeon ATI r128 Intel i810/815 Intel i830/845 Matrox G200/400 3dfx Voodoo3 3dfx Voodoo5 Cards Radeon 8500, 8700 Radeon 7x00 Rage Fury/Pro/Magnum, XPERT 2000, XPERT 128, XPERT 99, All-in-Wonder 128 i810/815 chipsets i830/845 chipsets Millenium G200, G400, G450, Mystique G200 Voodoo3, Banshee, Velocity 100/200 Voodoo4 4500, Voodoo5 5500 Intel/AMD x86 YES (AGP only) YES (AGP only) YES YES YES YES YES YES DEC Alpha YES YES YES no no no YES YES PowerPC no YES YES no no no no no Driver Name r200_dri.so radeon_dri.so r128_dri.so i810_dri.so i830_dri.so mga_dri.so tdfx_dri.so tdfx_dri.so Kernel Module radeon.o radeon.o r128.o i810.o i830.o mga.o tdfx.o tdfx.o 2D XFree86 Driver radeon_drv.o radeon_drv.o r128_drv.o i810_drv.o i810_drv.o mga_drv.o tdfx_drv.o tdfx_drv.o Hardware Stencil YES (@32bpp) YES (@32bpp) YES (@32bpp) no YES (@32bpp) YES (@32bpp) no YES (@32bpp) Hardware Alpha Channel YES (@32bpp) YES (@32bpp) no no YES (@32bpp) YES (@32bpp) no YES (@32bpp) Hardware TCL YES YES no no no no no no ARB_multitexture (units) YES (2?) YES (2?) YES (2) YES (2) YES (2) YES (G200:1, G400:2) YES (2) YES (2) ARB_texture_cube_map no no no no no no no no ARB/EXT_texture_env_add YES YES YES YES YES YES YES YES ARB/EXT_texture_env_dot3 YES YES no no no no no no ARB/EXT_texture_env_combine YES YES no no YES no no YES EXT_blend_color no no no no YES no no no EXT_blend_function_separate no no no no YES no no no EXT_blend_logic_op YES YES no no no no no no EXT_blend_min_max YES no no no YES no no no EXT_blend_subtract YES YES no no YES no no no EXT_fog_coord YES YES no no YES no no no EXT_paletted_texture no no no no no no YES YES EXT_secondary_color YES YES no no YES no no no EXT_shared_texture_palette no no no no no no no no EXT_stencil_wrap YES no no YES YES no no YES EXT_texture_filter_anisotropic YES YES no no no no no no EXT_texture_lod_bias YES YES no YES YES no YES YES IBM_texture_mirrored_repeat no YES no no no no no no MESA_pack_invert YES no no no no no no no MESA_texture_ycbcr YES no no no no no no no NV_texture_rectangle YES no no no no no no no SGIS_generate_mipmap no YES no no no YES no no GLX_NV_vertex_array_range YES no no no no no no no OpenGL Extensions enabled in all DRI drivers: GL_ARB_transpose_matrix GL_EXT_abgr GL_EXT_bgra GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_texture3D (in software) GL_EXT_texture_object GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_MESA_window_pos GL_NV_texgen_reflection
Re: [Dri-devel] driver feature table
On Mit, 2002-10-09 at 19:29, Jens Owen wrote: 2) Michael's PowerPC support row. I assume you're talking about me. ;) I think it's a bad idea to just say 'no' for drivers that aren't 100% known to work, because people will think 'doh, it doesn't work, no point in trying'. In particular, I'd be very surprised if the r200 driver didn't work at all on PPC. Putting in a no for mga and tdfx is fine with me until we get any feedback about them, if we can't afford more verbosity. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
On Wed, 9 Oct 2002, Jens Owen wrote: Brian Paul wrote: If anyone else wants to make changes, do so, and post a new table.html file. Okay. Here's a new file. It contains the following fixes: 1) i830 chipset uses i830 kernel module. 2) Michael's PowerPC support row. Is each card that's supported under Linux also supported under FreeBSD? If not, someone might want to create another row to indicate FreeBSD support. Adam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
