Page 9 of 11 FirstFirst ... 7891011 LastLast
Results 81 to 90 of 102

Thread: S3TC => r600{c,g}

  1. #81
    Join Date
    Jul 2008
    Posts
    10

    Default

    Quote Originally Posted by taiu View Post
    For those interested in hacking http://cgit.freedesktop.org/~andrem/...g/?h=r600-dxtn has an experiment on r600c.
    It should do tex upload (compressed or not) but no subteximage or getteximage, enough to run ut though. An yes, you probably have to
    modify your kernel to allow these tex formats
    Great. I suspected it had something to do with tile_type/tile_mode. Will try to transcribe that into r600g this evening.

  2. #82
    Join Date
    Jan 2007
    Posts
    459

    Default

    http://www.phoronix.com/scan.php?pag...item&px=OTEwNg
    R600 Gallium3D Driver Now Supports S3TC Library

    Posted by Michael Larabel on February 15, 2011

  3. #83
    Join Date
    Jun 2010
    Posts
    84

    Default

    Yeah! I'm compiling everything by ssh.... To bad I need to wait after work to try...

  4. #84
    Join Date
    Feb 2011
    Location
    Bizkaia-spain
    Posts
    9

    Default

    For me don't work.
    I have 2.6.38rc4 + r600G (Gallium 0.4 on 7.11-devel) and have 3D aceleration, but recompiled the drivers + install + reboot does not change anything.
    Only increase 0.2fps the speed

  5. #85
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    957

    Default

    You need drm-radeon-testing kernel (hopefully 2.6.39 will be enough).

  6. #86
    Join Date
    Aug 2009
    Posts
    24

    Default

    Dave,

    Any chance this could be added to 2.6.38 or is this change too late/too intrusive?
    Since the new formats are only available via envvar, the risk is mitigated, no?

  7. #87
    Join Date
    Feb 2011
    Location
    Bizkaia-spain
    Posts
    9

    Default

    Quote Originally Posted by darkbasic View Post
    You need drm-radeon-testing kernel (hopefully 2.6.39 will be enough).

    2.6.39??? If 2.6.38 not yet released..... Only Rc's

    I'm tried the newest git code and run's quite fast but not yet s3tc and not DRI???????

    You can see this output :

    Code:
    morzillo@LinuxPowa:~$ glxinfo
    name of display: :0.0
    display: :0  screen: 0
    direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
    server glx vendor string: SGI
    server glx version string: 1.4
    server glx extensions:
        GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, 
        GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
        GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, 
        GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
        GLX_SGIX_visual_select_group, GLX_INTEL_swap_event
    client glx vendor string: Mesa Project and SGI
    client glx version string: 1.4
    client glx extensions:
        GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
        GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
        GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
        GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
        GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
        GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, 
        GLX_INTEL_swap_event
    GLX version: 1.4
    GLX extensions:
        GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
        GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
        GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, 
        GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
        GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, 
        GLX_INTEL_swap_event
    OpenGL vendor string: X.Org
    OpenGL renderer string: Gallium 0.4 on AMD RV770
    OpenGL version string: 1.4 (2.1 Mesa 7.11-devel)
    OpenGL extensions:
        GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, 
        GL_ARB_fragment_program_shadow, GL_ARB_multisample, GL_ARB_multitexture, 
        GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite, 
        GL_ARB_shadow, 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_program, 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_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, 
        GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, 
        GL_EXT_point_parameters, GL_EXT_polygon_offset, 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_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_mirror_clamp, GL_EXT_texture_object, 
        GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, 
        GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, 
        GL_ATI_texture_mirror_once, GL_ATIX_texture_env_combine3, 
        GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, 
        GL_MESA_pack_invert, GL_NV_blend_square, GL_NV_depth_clamp, 
        GL_NV_light_max_exponent, GL_NV_texgen_reflection, 
        GL_NV_texture_env_combine4, GL_NV_texture_rectangle, 
        GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, 
        GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays
    
    96 GLX Visuals
        visual  x   bf lv rg d st  colorbuffer  sr ax dp st accumbuffer  ms  cav
      id dep cl sp  sz l  ci b ro  r  g  b  a F gb bf th cl  r  g  b  a ns b eat
    ----------------------------------------------------------------------------
    0x021 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
    0x022 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
    0x0ef 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
    0x0f0 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0 16 16 16 16  0 0 Slow
    0x0f1 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
    Bla bla bla bla......
    It's interesting...I played at full speed nexuiz but havn't DRI activated.
    Tried Glxgears and got 50fps(the same as always with r600g) but it's too slow, the gears moving quite slowly.
    I don't know how it is posible but i revert to my old mesa-stage until the code has better stability.
    Thanks

  8. #88
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    957

    Default

    Quote Originally Posted by MoRZiLLo View Post
    2.6.39??? If 2.6.38 not yet released..... Only Rc's
    That's why I told you to use drm-radeon-testing in the meantime...

  9. #89
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by MoRZiLLo View Post
    2.6.39??? If 2.6.38 not yet released..... Only Rc's
    Yes, but the merge window (when new features are added) closed the week before the first release candidate (or was, I don't remember, the result is the same), so it is not in the 2.6.38 release. If it is about the time it will last, then it will be no more than 3 months to 2.6.39 stable, I think.

  10. #90
    Join Date
    Aug 2009
    Posts
    24

    Default

    Quote Originally Posted by mrugiero View Post
    when new features are added
    Sure, but if said new feature is hidden behind an envvar, then there's no risk to introduce regressions, right? We could consider this as "staging", and this would allow all the spring distro users to experiment without having to update their kernel (only xorg-edgers ppa or equivalent would be needed, great for the compilation-impaired like myself)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •