Unanswered topics | Active topics


Board index » »

All times are UTC-06:00



Post new topic  Reply to topic  Page 2 of 2
  [ 23 posts ] 
  Previous topic | Next topic 
Author Message
Neko
 Post subject:
PostPosted: Wed May 06, 2009 12:01 am 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1594
Location: Austin, TX
Quote:
Quote:
Does radeon-rewrite make it any better?
AFAICT fom the devs' plans, it should entirely fix it. and also introduce another much-needed buffer functionality too (i.e. FBOs). i'm yet to actually give it a try, though, as i need to make some preparations first. if everything goes to plan i should give it a run this weekend.
I would be very interested to know the result :D

_________________
Matt Sealey
Top
   
Reply with quote  
blu
 Post subject:
PostPosted: Sat May 09, 2009 6:03 pm 
Offline

Joined: Tue Mar 31, 2009 10:24 pm
Posts: 171
Quote:
I would be very interested to know the result :D
sorry, Matt, i got sidetracked from this task. i'll return to it soon, though, there's too much at stake here ; )

btw, here's an anecdotal, tangentially-related first hand story for you:

i tend to get rather frequent power outages at my place, approx one per month. must be something to do with the old power installation in my apartment building. i used to keep all my machines on ups, until the thing pissed me with its utterly annoying alarm sound during those midnight outages, and i tossed it out of the window (metaphorically). so, since then i've been ups-less, god bless journalling filesystems.

so, since i've been ups-less, i've had two occasions when machines actually survived an outage as if nothing happened. the first of them was a c2d mac mini which was in a suspended-to-ram sleep state at the moment - it lived out the whole ~1 min of outage apparently on power from the capacitors in the power brick - and woke up as if nothing had happened once the power got restored. i was impressed.

the second one happened today, and the lucky survivor was my (9250-equipped) efika, but here's the curious part - it was not suspended or hibernated - nope, it was running normally, just it's video-out was put to sleep, as i had ssd'd into it. otherwise the system was idling under X. the efika survived a few-second-long outage, when everything else in the apartment (including a g4 mac mini and a wii) went out. i was utterly impressed.
Top
   
Reply with quote  
blu
 Post subject:
PostPosted: Tue May 26, 2009 8:55 am 
Offline

Joined: Tue Mar 31, 2009 10:24 pm
Posts: 171
ok, KMS (kernel mode-setting) is a go on EFIKA + ATI9250.

more news at eleven.
Top
   
Reply with quote  
mattmatteh
 Post subject:
PostPosted: Tue May 26, 2009 10:23 am 
Offline

Joined: Sat Mar 15, 2008 4:57 pm
Posts: 84
Location: near chicago
I have not tried kernel mode setting before, i thought it was different from framebuffer? In that paste i see radeonfb, which i thought was an older framebuffer for older radeon cards that is not updated anymore. I am i mistaken ?

matt
Top
   
Reply with quote  
blu
 Post subject:
PostPosted: Tue May 26, 2009 10:57 am 
Offline

Joined: Tue Mar 31, 2009 10:24 pm
Posts: 171
Quote:
I have not tried kernel mode setting before, i thought it was different from framebuffer? In that paste i see radeonfb, which i thought was an older framebuffer for older radeon cards that is not updated anymore. Am i mistaken ?
it's still called radeonfb in radeon-rewrite.

re KMS - it basically allows the kernel to know (and handle) all there's to know about your display sub-system (fb related) - something that xorg has been privy to until now.

here's another KMS glimpse from the same setup:
Code:
$ lspci
00:18.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01)
00:18.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) (rev 01)
00:1c.0 Bridge: Motorola MPC5200B

$ cat /sys/devices/pci0000:00/0000:00:18.0/graphics/fb0/modes
S:1280x1024p-60
S:640x480p-85
S:800x600p-85
V:1152x864p-75
V:1024x768p-75
V:1024x768p-70
V:1024x768p-60
U:832x624p-75
V:800x600p-75
V:800x600p-72
V:800x600p-60
V:800x600p-56
V:640x480p-75
V:640x480p-72
U:640x480p-67
V:640x480p-60
U:720x400p-70
D:1024x768p-84
the reason for the low res modes listed is that i have a 17" crt attached to that radeon.
Top
   
Reply with quote  
blu
 Post subject:
PostPosted: Sun Mar 21, 2010 10:09 pm 
Offline

Joined: Tue Mar 31, 2009 10:24 pm
Posts: 171
Image

One year later..

What started as radeon-rewrite has borne fruit - this Efika5K2 here has seen its first _proper_ GL. And this user has lived to see the day. Tons of thanks and kudos to David Airlie and the whole gang who made this possible.

Quick glimpse:
Code:
$ DISPLAY=0:0 glxinfo
name of display: 0:0.0
display: 0:0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
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
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_allocate_memory,
GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, 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 version: 1.2
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_copy_sub_buffer, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
GLX_SGI_make_current_read, GLX_SGI_video_sync, GLX_SGIS_multisample,
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group,
GLX_EXT_texture_from_pixmap
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R200 (RV280 5960) 20090101 PowerPC TCL DRI2
OpenGL version string: 1.3 Mesa 7.7
OpenGL extensions:
GL_ARB_draw_buffers, GL_ARB_imaging, GL_ARB_multisample,
GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_point_parameters,
GL_ARB_point_sprite, 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_rectangle,
GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object,
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_compiled_vertex_array, GL_EXT_convolution,
GL_EXT_copy_texture, GL_EXT_draw_range_elements,
GL_EXT_framebuffer_object, GL_EXT_fog_coord, GL_EXT_histogram,
GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil,
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_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_blend_equation_separate,
GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once,
GL_ATI_fragment_shader, 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_ycbcr_texture,
GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent,
GL_NV_packed_depth_stencil, GL_NV_texture_rectangle,
GL_NV_texgen_reflection, GL_OES_read_format, GL_SGI_color_matrix,
GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp,
GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays
Notice the FBO extension. At long last! Also what is not immediately seen above is the proper kernel-side BO manager - TTM (working VBOs ahoy!).

One small step for Mesa/DRI, one giant step for GL development in the free world (i.e. non-intel-bound, non-proprietary ATI GL drivers). Three cheers.

ps: first run under crux 2.5 with kernel upgraded to 2.6.32.3.
Top
   
Reply with quote  
Neko
 Post subject:
PostPosted: Mon Mar 22, 2010 4:47 pm 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1594
Location: Austin, TX
Quote:
Notice the FBO extension. At long last! Also what is not immediately seen above is the proper kernel-side BO manager - TTM (working VBOs ahoy!).

One small step for Mesa/DRI, one giant step for GL development in the free world (i.e. non-intel-bound, non-proprietary ATI GL drivers). Three cheers.

ps: first run under crux 2.5 with kernel upgraded to 2.6.32.3.
So the question is, what does this mean for Efika PPC users? Does Compiz etc. work out of the box? Performance improvements worth nothing?

_________________
Matt Sealey
Top
   
Reply with quote  
blu
 Post subject:
PostPosted: Mon Mar 22, 2010 11:27 pm 
Offline

Joined: Tue Mar 31, 2009 10:24 pm
Posts: 171
Quote:
So the question is, what does this mean for Efika PPC users? Does Compiz etc. work out of the box? Performance improvements worth nothing?
I'm not a compiz user so I cannot comment on it, at least not yet. Re performance - it is a bit early to draw any definitive conclusions as the codebase is clearly young and some things are in a proto state (I managed to step in half a dozen of traps already), BUT one thing I noticed is that R200 behaves sanely now WRT fillrate under texturing - before the pipeline would halve its fillrate the moment a single texture was introduced; now fillrate decreases gradually with the texture resolution, as it should. I guess that could be good news for compiz. OTOH, my fillrate test here flat out fails at any 1024+ texture res cases, so new drivers giveth, new drivers taketh ; )

Apropos, turns out VBOs are still in the old 'unconditionally setup a new DMA region each time the same static VBO is used' mode, but that's supposedly because that VBO management logic is still on the old brainwave - the new BO manager should be well capable of doing it properly. Actually, attending to this issue is on my 'todo' list, as I consider it of high priority. Time to spam the mesa-dev list ; )
Top
   
Reply with quote  
Display posts from previous:  Sort by  
Post new topic  Reply to topic  Page 2 of 2
  [ 23 posts ] 

Board index » »

All times are UTC-06:00

Who is online

Users browsing this forum: No registered users and 0 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
PowerDeveloper.org: Copyright © 2004-2012, Genesi USA, Inc. The Power Architecture and Power.org wordmarks and the Power and Power.org logos and related marks are trademarks and service marks licensed by Power.org.
All other names and trademarks used are property of their respective owners. Privacy Policy
Powered by phpBB® Forum Software © phpBB Group