Printable View
Apparently, there is very advanced code going through technical review over at AMD. Nobody knows how long that could take.Quote:
Originally Posted by ua=42
In the meantime, you should use profiles, which work perfectly with FLOSS drivers. Force low power state on boot, and switch manually to high power state before gaming or anything intensive.
Check here for instructions: http://www.x.org/wiki/RadeonFeature
Better version from the Arch wiki: https://wiki.archlinux.org/index.php...th_KMS_enabledQuote:
Originally Posted by pingufunkybeat
Quote:
With root access, you have two choices:
1. Dynamic frequency switching (depending on GPU load)
# echo dynpm > /sys/class/drm/card0/device/power_method
The "dynpm" method dynamically changes the clocks based on the number of pending fences, so performance is ramped up when running GPU intensive apps, and ramped down when the GPU is idle. The re-clocking is attempted during vertical blanking periods, but due to the timing of the re-clocking functions, does not always complete in the blanking period, which can lead to flicker in the display. Due to this, dynpm only works when a single head is active.
Note: The "profile" method mentioned below is not as aggressive as "dynpm," but is currently much more stable and flicker free and works with multiple heads active.
2. Profile-based frequency switching
# echo profile > /sys/class/drm/card0/device/power_method
The "profile" mode will allow you to select one of the five profiles below. Different profiles, for the most part, end up changing the frequency/voltage of the card.
"default" uses the default clocks and does not change the power state. This is the default behavior.
"auto" selects between "mid" and "high" power states based on the whether the system is on battery power or not. The "low" power state are selected when the monitors are in the dpms off state.
"low" forces the gpu to be in the low power state all the time. Note that "low" can cause display problems on some laptops; this is why auto only uses "low" when displays are off.
"mid" forces the gpu to be in the "mid" power state all the time. The "low" power state is selected when the monitors are in the dpms off state.
"high" forces the gpu to be in the "high" power state all the time. The "low" power state is selected when the monitors are in the dpms off state.
So lets say we want the "low" option...for this, run the following command:
# echo low > /sys/class/drm/card0/device/power_profile
Replace "low" with any of the aforementioned profiles as necessary.
Note: Echoing a profile value to this file is not permanent, so when you find something that fits your needs, you will need to add it to /etc/rc.local, so it is executed at system startup, in case you are using initscripts. In case of using systemd there will be no /etc/rc.local file, you can use following udev rule:
dynpm-method example:
$ cat /etc/udev/rules.d/30-local.rules
KERNEL=="card0", SUBSYSTEM=="drm", DRIVERS=="radeon", ATTR{device/power_method}="dynpm"
auto-profile example:
$ cat /etc/udev/rules.d/30-local.rules
KERNEL=="card0", SUBSYSTEM=="drm", DRIVERS=="radeon", ATTR{device/power_method}="profile", ATTR{device/power_profile}="auto"
Note: Gnome-shell users may be interested in the following extension: Radeon Power Profile Manager for manually controlling the GPU profiles.
Unfrotunatelly FOSS driver pm capabilies are light-years behind catalyst. If powertop numbers from 2 mobile chipsets (radeon 4330 and 5650) are in any way meaningfull, going from high to low profile on idle/low load saves about 2watts, going from radeon low profile to catalysts gives another 5W. Also the problem is not just battery life, heat is even ore important. Fryning +1000$ laptop is way uncool. (pun kinda intended).
To add, KDE users might wanna try RadeonPM plasmoid. It shows cards hw info (GPU/merm frequency, voltage and temp if sensors are provided) and allows switching profiles, pm methods.
Compiled the latest code and still there's no OpenGL 3.1. Looking at GL3.txt at docs I see that for r600 GL_ARB_draw_instanced isn't yet done. :(
glxinfo won't report core profiles yet, nothing to do with draw instanced.Quote:
Originally Posted by pejakm
So until we fix glxinfo it'll only show 3.0.
Dave.
Ah, that clarifies it. Thanks.Quote:
Originally Posted by airlied
Also, I see now draw instanced in fact is merged, but it appears GL3.txt isn't updated accordingly.
Edit: airlied, still glxinfo doesn't report GL_ARB_texture_buffer_object extension, and it reports "shading language version string: 1.30".
I think TBOs are only enabled if GLSL 1.4 is, and i think that's only enabled if you are in a core context rather than the compatibility one glxinfo uses.Quote:
Originally Posted by pejakm
With a patched glxinfo (patch from Dave Airlied) http://lists.freedesktop.org/archive...ry/032655.htmlQuote:
Originally Posted by smitty3268
Quote:
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.1-devel
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)
OpenGL core profile extensions:
GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend,
GL_AMD_seamless_cubemap_per_texture, GL_AMD_shader_stencil_export,
GL_ARB_ES2_compatibility, GL_ARB_base_instance,
GL_ARB_blend_func_extended, GL_ARB_color_buffer_float,
GL_ARB_conservative_depth, GL_ARB_copy_buffer, GL_ARB_debug_output,
GL_ARB_depth_buffer_float, GL_ARB_depth_clamp, GL_ARB_draw_buffers,
GL_ARB_draw_buffers_blend, GL_ARB_draw_elements_base_vertex,
GL_ARB_draw_instanced, GL_ARB_explicit_attrib_location,
GL_ARB_fragment_coord_conventions, GL_ARB_fragment_shader,
GL_ARB_framebuffer_object, GL_ARB_framebuffer_sRGB,
GL_ARB_half_float_pixel, GL_ARB_half_float_vertex,
GL_ARB_instanced_arrays, GL_ARB_invalidate_subdata,
GL_ARB_map_buffer_alignment, GL_ARB_map_buffer_range,
GL_ARB_occlusion_query2, GL_ARB_pixel_buffer_object, GL_ARB_point_sprite,
GL_ARB_provoking_vertex, GL_ARB_robustness, GL_ARB_sampler_objects,
GL_ARB_seamless_cube_map, GL_ARB_shader_bit_encoding,
GL_ARB_shader_objects, GL_ARB_shader_stencil_export,
GL_ARB_shader_texture_lod, GL_ARB_sync, GL_ARB_texture_buffer_object,
GL_ARB_texture_compression_rgtc, GL_ARB_texture_cube_map_array,
GL_ARB_texture_float, GL_ARB_texture_non_power_of_two,
GL_ARB_texture_rectangle, GL_ARB_texture_rg, GL_ARB_texture_rgb10_a2ui,
GL_ARB_texture_storage, GL_ARB_texture_swizzle, GL_ARB_timer_query,
GL_ARB_transform_feedback2, GL_ARB_transform_feedback3,
GL_ARB_transform_feedback_instanced, GL_ARB_uniform_buffer_object,
GL_ARB_vertex_array_bgra, GL_ARB_vertex_array_object,
GL_ARB_vertex_shader, GL_ARB_vertex_type_2_10_10_10_rev,
GL_ATI_blend_equation_separate, GL_ATI_texture_compression_3dc,
GL_ATI_texture_float, GL_ATI_texture_mirror_once, GL_EXT_abgr,
GL_EXT_blend_equation_separate, GL_EXT_draw_buffers2,
GL_EXT_draw_instanced, GL_EXT_framebuffer_blit,
GL_EXT_framebuffer_multisample, GL_EXT_framebuffer_object,
GL_EXT_framebuffer_sRGB, GL_EXT_packed_depth_stencil, GL_EXT_packed_float,
GL_EXT_pixel_buffer_object, GL_EXT_provoking_vertex, GL_EXT_texture_array,
GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_latc,
GL_EXT_texture_compression_rgtc, GL_EXT_texture_compression_s3tc,
GL_EXT_texture_filter_anisotropic, GL_EXT_texture_integer,
GL_EXT_texture_mirror_clamp, GL_EXT_texture_sRGB,
GL_EXT_texture_sRGB_decode, GL_EXT_texture_shared_exponent,
GL_EXT_texture_snorm, GL_EXT_texture_swizzle, GL_EXT_timer_query,
GL_EXT_transform_feedback, GL_EXT_vertex_array_bgra,
GL_IBM_multimode_draw_arrays, GL_IBM_rasterpos_clip, GL_MESA_pack_invert,
GL_MESA_texture_signed_rgba, GL_NV_conditional_render, GL_NV_depth_clamp,
GL_NV_packed_depth_stencil, GL_NV_texture_barrier, GL_OES_EGL_image,
GL_OES_read_format, GL_S3_s3tc,
I have a question that not really fits with this thread.
It's about MSAA for R600g. Why games like Xonotic, sauerbraten don't recognize AA support? Even though AA works with set GALLIUM_MSAA variable, games don't seem to 'see' this newly added feature.
Aaaah. *fans self gently resting in my throne on this Sunday morning*
I could read this kind of news all day long. ;)
Well it seems the free driver stack is getting more and more into shape. And hopefully some code can be shared between generations and maybe some even for GPUs from other vendors.