[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=78453

--- Comment #132 from Kai <kai at dev.carbon-project.org> ---
(In reply to comment #130)
> (In reply to comment #126)
> > (In reply to comment #124)
> > > 
> > > And for the DPM stuff: dpm doesn't seem to work, the numbers never changed
> > > (tested on console without X and Metro Last Light; I dropped my previous
> > > "radeon.dpm=0" from the kernel parameters):
> > > # cat /sys/kernel/debug/dri/64/radeon_pm_info
> > > power level avg    sclk: 30000 mclk: 15000
> > 
> > You need to print that out while you have a 3D app running.  Those numbers
> > are real-time.  E.g., in the console, there is no 3D acceleration happening
> > so they stay at their low levels.
> 
> I did just that :-) Sorry if I wasn't clear enough on this. Actually what I
> did was starting Metro Last Light and catting over ssh multiple times from
> my laptop (Metro doesn't allow alt-tab). The values never changed at all.
> 
> I chose Metro, because it's the most graphically challenging piece of
> software I have - and should therefore certainly cause a change of values.
> glxgears didn't cause a change as well, but I thought that might be because
> it's too simple.
> 
> Today, to verify, I also tried it with Half Life 2. Same result. (But MSAA
> works now with the libdrm patch, thanks Marek !)
> 
> All of the above still with the "ASIC_ProfilingInfo v3.1" as I got a NULL
> pointer dereference with yesterday's drm-next-3.17-rebased-on-fixes kernel.
> 
> I guess the new kernel to use is "standard" 3.17-wip, as it now contains all
> the Hawaii stuff ?

Just a thought: you had radeon.dpm=0 set for a long time according to some of
your posts. Are you sure you've removed that from your Kernel command line?

I can't tell if the reclocking is working as Marek reported in comment #131
yet. I might have time fireing a game up during the weekend. But should that be
a problem I can just open a new bug. I don't think this possible reclocking
issue should keep this bug open.

> I'm also ok with tracking the remaining issues in separate bugs - do I need
> to close this bug ? (I'd wait till the xf86-video-ati patch is applied).

Yes, that sounds reasonable: the person who commits the DDX patch can close
this bug, because then all pieces should be at least in Git.

> Any requests on which issues should get their own bugs now ? Turning off
> HDMI-0 and Glyphs come to mind ?


The glyph stuff is already tracked in bug 81930. We still need bugs for the
poor performance and crashing the GPU by running Unigine Heaven (you have to
actually reboot, otherwise the screen won't come up again, in fact the screen
is not just black, it loses its signal). And possible other issues I'm not
seeing myself or just have not noticed yet.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/665f3d9c/attachment.html>