Latest Saucy builds for Ubuntu (drm-next) indeed seems to fix UVD on the Sony Vaio (RV710 ATI), though the screen flickering is still there. Unfortunately I can't find anything untoward in the usual logs or dmesg.
I pushed some updated patches to my drm-next-3.11 branch that should fix the outstanding issue with NI asics and also adds a debugfs interface for tracking the current power state.
well my 7770 certainly improved and i think i found the issue of the black screen, it does work when i disconnect my HDMI tv connection and leave only my DVI monitor but with both KMS have a nasty hang at start.
another issue is if i start with the drm-next-3.11 kernel radeonsi doesnt seem to work correctly[it spawn 1 ksoftirq per core and give hell to the CPU], i assume llvm need update, so ill compile today revision[i have 30 jun] with libdrm today git and see if persist. drm-next-wip-5 works fine tho
My HD 6870 doesn't work with the latest patches. Once KMS is enabled during boot, the screen is covered in an abundant amount of artifacts that spell doom. It works with the previous patch set (drm-next-3.11-wip-5).
I'm using Arch with the latest mesa/ati related packages found here.
I noticed that HomeSp's 6870 is working fine with the latest patches, so oddly enough I'm hoping that this is a true regression and not PEBKAC, as I'd not like to waste anyone's time. Is there any information that I can give that might help resolve this?
So when dpm is enabled performance is definitly worse.
@agd5f: Do you know what to do? How to increase performance with enabled dpm? I'd like to see same performace with dpm as "default" profile has.
If you need additional info or tests, let me know what is needed.
Glxgears is a light 3D benchmark. So light, many claim it only measures CPU overhead of the driver, so the values are not directly comparable. But increase in glxgears frames on same machine is a good thing.
You may be hitting ondemand powerstate bug, thread is found in this section of forum, but only if you use non-Intel CPU. Intel CPUs use pstate driver, so its completely different and more efficient.
To overcome this, you can play with:
echo 150 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
which will increase CPU polling time, if frequency went up. Default is 1.
the cpu will stay longer in performance state and less frequent polls in power state rob less of CPU raw performance.
but on mobile platform it could be advantageous to keep the value lower or even default, as it will result in faster downclock time and less battery usage. However, if your mobile platform is loaded, more frequent polls will rob its performance and will rob more battery. Think of it as a warden, that can mess too much in manufacturing process, robbing its efficiency; but if there is nothing to do, more frequent checks will result in faster downclock.
echo 35 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
which will make CPU enter full clocking, if the load of more that 35% is detected. Default is 95%, which guarantees sluggish desktop. Personally recommended values 25-40%.
You can then set these variables in /etc/sysfs.conf (create it, if absent), the following way:
devices/system/cpu/cpu0/cpufreq/scaling_governor = ondemand
devices/system/cpu/cpu1/cpufreq/scaling_governor = ondemand
devices/system/cpu/cpufreq/ondemand/sampling_down_factor = 150
devices/system/cpu/cpufreq/ondemand/up_threshold = 35
or load your settings in any autostart script.
If you have mobile platform, governor "conservative" may be more advantageous, as it increases clocks step-wise; "ondemand" will fire top clock when reaching barrier, instead.