No announcement yet.

Future of ATI Linux drivers

  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by barbarbaron View Post
    2. OpenGL extensions supported by the latest intel drivers is much more than other opensource stacks:

    GL_ARB_copy_buffer, GL_ARB_depth_texture, GL_ARB_depth_clamp,
    GL_ARB_draw_buffers, GL_ARB_draw_elements_base_vertex,
    GL_ARB_fragment_coord_conventions, GL_ARB_fragment_program,
    GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader,
    GL_ARB_framebuffer_object, GL_ARB_half_float_pixel,
    GL_ARB_half_float_vertex, GL_ARB_map_buffer_range, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object,
    GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_provoking_vertex,
    GL_ARB_seamless_cube_map, GL_ARB_shader_objects,
    GL_ARB_shading_language_100, GL_ARB_shading_language_120, GL_ARB_shadow,
    GL_ARB_sync, GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
    GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar,
    GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
    GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle,
    GL_ARB_transpose_matrix, GL_ARB_vertex_array_bgra,
    GL_ARB_vertex_array_object, GL_ARB_vertex_buffer_object,
    GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos,
    GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
    GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,
    GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
    GL_EXT_cull_vertex, GL_EXT_compiled_vertex_array, GL_EXT_copy_texture,
    GL_EXT_draw_buffers2, GL_EXT_draw_range_elements, GL_EXT_framebuffer_blit,
    GL_EXT_framebuffer_object, GL_EXT_fog_coord,
    GL_EXT_gpu_program_parameters, GL_EXT_multi_draw_arrays,
    GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels,
    GL_EXT_pixel_buffer_object, GL_EXT_point_parameters,
    GL_EXT_polygon_offset, GL_EXT_provoking_vertex, GL_EXT_rescale_normal,
    GL_EXT_secondary_color, GL_EXT_separate_specular_color,
    GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap,
    GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D,
    GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map,
    GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
    GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB,
    GL_EXT_texture_swizzle, GL_EXT_vertex_array, GL_EXT_vertex_array_bgra,
    GL_3DFX_texture_compression_FXT1, GL_APPLE_client_storage,
    GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object,
    GL_APPLE_object_purgeable, GL_ATI_blend_equation_separate,
    GL_ATI_envmap_bumpmap, GL_ATI_texture_env_combine3,
    GL_ATI_separate_stencil, GL_IBM_multimode_draw_arrays,
    GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat,
    GL_INGR_blend_func_separate, GL_MESA_pack_invert,
    GL_MESA_texture_signed_rgba, GL_MESA_ycbcr_texture, GL_MESA_window_pos,
    GL_NV_blend_square, GL_NV_depth_clamp, GL_NV_light_max_exponent,
    GL_NV_packed_depth_stencil, GL_NV_texture_env_combine4,
    GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program,
    GL_NV_vertex_program1_1, GL_OES_read_format, GL_SGIS_generate_mipmap,
    GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp,
    GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays, GL_OES_EGL_image

    Just compare it...
    I wouldn't say much more, but if you wanna compare, let's compare.

    The extensions Intel has that we decided not to support in Gallium:
    * GL_EXT_cull_vertex
    * GL_3DFX_texture_compression_FXT1
    * GL_NV_vertex_program
    * GL_NV_vertex_program1_1

    The extensions Intel has that r300 hw doesn't and cannot support:
    * GL_ARB_depth_clamp
    * GL_ARB_seamless_cube_map
    * GL_EXT_draw_buffers2
    * GL_NV_depth_clamp

    The extensions Intel has that we are missing in r300g:
    * GL_ARB_draw_elements_base_vertex (I have patches)
    * GL_ARB_fragment_program_shadow (it's on my todo, should be easy)
    * GL_ARB_half_float_pixel (useless without float textures anyway)
    * GL_ARB_sync (needs some work in st/mesa)
    * GL_APPLE_client_storage (huh?)
    * GL_ATI_envmap_bumpmap (I'll see what I can do)
    * GL_MESA_texture_signed_rgba (useless, app devs use GL_EXT_texture_snorm instead, which is not in Mesa)

    The first 4 on the list above are the only ones I consider important.

    The extensions r300g has that Intel has not:
    * GL_EXT_framebuffer_multisample
    * GL_EXT_texture_mirror_clamp
    * GL_ATI_texture_mirror_once
    * GL_NV_conditional_render
    * GL_SGI_color_matrix
    * GL_S3_s3tc


    • Wierd... I have *never* seen that issue and I have video cards that I use personally ranging from a mach64 card, Nvidia geforce2 400 MX, and a radeon 4200... and I have uses quite a few cards in other PCs even a few framebuffers in sun hardware :-) ... and never seen it.

      Given that I have used open and closed drivers and practically every combination of window manager imaginable on my radeon and nvidia hardware .. I suspect that it is a hardware specific problem.

      I have seen lack cuased by faulty drivers or missing drivers that would cause lag and sluggishness but never tearing of that level.


      • Originally posted by cb88 View Post
        Wierd... I have *never* seen that issue and I have video cards that I use personally ranging from a mach64 card, Nvidia geforce2 400 MX, and a radeon 4200... and I have uses quite a few cards in other PCs even a few framebuffers in sun hardware :-) ... and never seen it.

        Given that I have used open and closed drivers and practically every combination of window manager imaginable on my radeon and nvidia hardware .. I suspect that it is a hardware specific problem.

        I have seen lack cuased by faulty drivers or missing drivers that would cause lag and sluggishness but never tearing of that level.
        Every single ati card I have ever used gets tearing in compiz using fglrx. It is impossible right now for vsync and to work with compiz with fglrx on ANY ati card. You must just not notice it.


        • All extensions that have become part of the official OpenGL specification are important, including some EXT, ATI, and NV extensions (e.g. GL_EXT_draw_buffers2 and GL_NV_conditional_render, which are incorporated in OpenGL 3.0).


          • Originally posted by marek View Post
            * GL_S3_s3tc
            Does getting this support require linking against the external st3c library?


            • Yes, it does.


              • It seems that to me that the obvious answer about how to get both AMD and NVIDIA to fully open-source their drivers is to increase Linux market share. From what I've seen, Linux and open source is making slow progress. The most recent victory was webm. The 3 main obstacles I've noticed are good drivers, making other software like games use OpenGL, and marketing. Previously, ease of installing software was an issue, but that has been improved a lot. I find it unfortunate that GNOME has become dominant. KDE, even with it's flaws has one huge advantage. With only a few minor tweaks and a few minutes of training you can make it so that even the computer illiterate can use it with ease. I've been able to convert a few computer illiterate people that way. Hopefully, GNOME 3.0 will put it on par with KDE with making it as easy for new users. On the OpenGL front, there is progress. Even while it's not doing well on Windows, it seems Mac is helping create a revival. Oddly enough, Mac's success might actually be helping Linux.


                • "National Interests" and Linux Distributions

                  Originally posted by Yfrwlf View Post
                  No, I don't have any "hard" statistics, not that these are very hard to begin with, but I was trying to make two points:

                  a) Stats here are very flawed, because the process they are using is flawed. You want proof, look at the huge difference in the numbers. Also, add this random statistic as well to the mix:

                  That article is noted in several different places other than that website. So, Microsoft themselves told their investors that. It all comes down to who you want to trust. Do you want to trust Microsoft and a bunch of U.S.-biased web hit counters?

                  b) As just noted, those are U.S. hit counters. If you've been paying attention to the news, and using your brain at the same time, other countries have higher percentages that use Linux. Why do I think that?

                  In developing countries, computer users are not subject to the "fear of change" effect stunting adoption, seeing as to how they're changing from not using computers to using them.

                  Other countries have had very large public Linux roll-outs, while here in the U.S. they are small where and when they are able to actually survive Microsoft's onslaught of lawyers and lobbyists.

                  Some other countries have much healthier Linux pre-installed sales on computers than the U.S. does.

                  Again, the U.S. is Microsoft's home turf, and anyone who listens to the news a lot and knows about all the things that Microsoft is involved in knows fully well their power and influence and how great it is. MSNBC, for starters...but the point is that sales in the U.S. is incredibly hard because of them and other factors, so you can't just trust U.S. web hit counters. Only now are things slowly starting to open up more in part thanks to consumer's acceptance of different and new operating systems on devices like phones/MIDs and soon hopefully netbooks.

                  If the U.S. government recognized that forcing the sale of Windows on computers by removing consumer's choice to not buy it to get it cheaper was anti-competitive which it of course is, sales would be very different. But alas, now I'm complaining, and that of course doesn't effect current Linux use, whatever that might be.

                  Yes; Microsoft is US-based. That alone is enough to get it sneered at (or actively set against) in some places (take a trip to DistroWatch sometime, and simply count the number of Linux distributions either partially or completely backed by a local/regional/national government that have seen new or recent development; to make it easier, I'll ask that you restrict the count to the past year *and* each distribution that fits the criteria counts once). Why do these local/regional/national governments do this? Because Microsoft is *not* based in their country; therefore, they see Microsoft as a threat to their national interests. (Even if Microsoft has many local offices, their headquarters is in the US.)

                  However, the heterogenous nature of overall FOSS development means that it's not just these governments that partially or entirely support development of Linux distributions that respresent FOSS advances; have we forgotten that SELinux (Security-Enhanced Linux, which has been, for the past two years, of Linux-distribution security framework going forward) was driven primarily *by* the United States government (specifically, the National Security Agency)? The very reality that, for any reason, that an arm of the United States would contribute to the development of a no-cost operating system that competes with a commercial operating-system originating *in the same country* indicates that the United States government does NOT see computer software in general (and PC operating systems in particular) as a linchpin of the country's interests. Who's right - the United States or, say, Argentina?

                  A "defined national interest" is often not logical, rational, or even remotely sensible; if they were, war would not happen and ambassadors would have very little work to do. Why would the reasons behind decisions on computer operating systems in general (and even Linux distributions in particular) be any different?