[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

Luzipher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #142 from Luzipher  ---
Closing this bug, as with todays commit to xf86-video-ati (
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=94202cbfbca05a503acdc1cca2f8409d141173af
) all the needed pieces are committed to the development repositories.

You need a development version of kernel 3.17 (currently agd5f's branch
drm-fixes-3.17-wip seems a good choice), current mesa from git, at least
libdrm-2.4.56, and xf86-video-ati from git, as well as the new microcode (the
link is somewhere in this bugreport).

Thanks again to everyone involved fixing up Hawaii support ! :-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #141 from Luzipher  ---
The two patches fixing Unigine Heaven and Valley you posted today on the
mailing list, Marek, also solve the gpu crashes I have with World of Warcraft,
described briefly above.

Patches are in this mailing list thread:
http://lists.freedesktop.org/archives/mesa-dev/2014-August/064919.html

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #140 from Marek Ol??k  ---
(In reply to comment #136)
> Alright, I have tested Uber Mode and it doesn't improve performance, at
> least not visibly. That's not the biggest problem. Uber Mode makes the card
> very unstable. I'm getting random geometry corruption and hangs with it. If
> I test a game, it usually doesn't survive 2 minutes of playing. The only
> other difference I see is that the maximum shader clock changed from 8
> to 85000 (KHz?). Anyway, the clocks seem too low. I think this card should
> be able to reach 1 GHz. It's also pretty cold - it only has 50 ?C.

I think I should correct some things I said above. (BTW if you don't know what
a Uber/Quiet mode is, there is a tiny on-board switch for switching between the
two: http://assets.hardwarezone.com/img/2013/11/R9_BIOS_Switch-600W.jpg)

The Quiet mode is pretty stable. Some apps might hang due to incorrect hardware
programming, but other than that, it's solid.

The Uber mode has some graphics corruption in some 3D apps. That might be the
reason why it hangs, but the hangs can be rare despite seeing a lot of
disappearing/flickering geometry.

I'm using Alex's drm-next-3.17-rebased-on-fixes. The other branch 3.17-wip
turned out be very unstable when I first fetched it, so you might want to avoid
it (not sure if the wip branch is working now).

I've figured out why Heaven and Valley hang. I have a workaround now and I'll
try to find the best way to fix it tomorrow.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #139 from Marek Ol??k  ---
(In reply to comment #137)
> You might try the patches I posted on bug 74250.

Sorry, they don't help.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #138 from Alex Deucher  ---
(In reply to comment #136)
> Alright, I have tested Uber Mode and it doesn't improve performance, at
> least not visibly. That's not the biggest problem. Uber Mode makes the card
> very unstable. I'm getting random geometry corruption and hangs with it. If
> I test a game, it usually doesn't survive 2 minutes of playing. The only
> other difference I see is that the maximum shader clock changed from 8
> to 85000 (KHz?). Anyway, the clocks seem too low. I think this card should
> be able to reach 1 GHz. It's also pretty cold - it only has 50 ?C.

8 is 800Mhz.  The driver stores clocks in 10khz units.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #137 from Alex Deucher  ---
You might try the patches I posted on bug 74250.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #136 from Marek Ol??k  ---
Alright, I have tested Uber Mode and it doesn't improve performance, at least
not visibly. That's not the biggest problem. Uber Mode makes the card very
unstable. I'm getting random geometry corruption and hangs with it. If I test a
game, it usually doesn't survive 2 minutes of playing. The only other
difference I see is that the maximum shader clock changed from 8 to 85000
(KHz?). Anyway, the clocks seem too low. I think this card should be able to
reach 1 GHz. It's also pretty cold - it only has 50 ?C.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #135 from Luzipher  ---
(In reply to comment #134)
> (In reply to comment #133)
> > (In reply to comment #131)
> > > DPM seems to be working here.
> > 
> > I guess you have a unmodified reference design card ?
> 
> I guess so. It doesn't look fancy like cards you can buy. It's just a big
> black brick with an ugly sticker on it saying "HAWAII XT". :)

Well, yes, mine looks quite fancy, with 3 fans and stuff. I bought it for the
better cooling solution (no idea why the reference design must be loud and not
very efficient).
Thing is, it also has a different BIOS, because it doesn't have "Uber"-Mode, as
that mode should be default on my card. AFAIK "Uber"-Mode on reference designs
squeezes out more performance but is way louder. It should be activatable by a
small switch on the card.
In contrast my "Sapphire Radeon R9 290X Tri-X OC" switches beteen normal BIOS
and UEFI mode with that switch (I'm using the normal one as my rig is from the
ancient times before UEFI).

Maybe it'd be interesting if you tried to switch to "Uber"-Mode and see if
anything chages (does dpm still work or does the "Uber"-Mode BIOS also use a
ASIC_ProfilingInfo v3.1 table ?).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #134 from Marek Ol??k  ---
(In reply to comment #133)
> (In reply to comment #131)
> > DPM seems to be working here.
> 
> I guess you have a unmodified reference design card ?

I guess so. It doesn't look fancy like cards you can buy. It's just a big black
brick with an ugly sticker on it saying "HAWAII XT". :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #133 from Luzipher  ---
(In reply to comment #132)
> 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?

No, I removed that argument a while ago. But I just rechecked, this is what
dmesg prints - so it's really not there anymore:
Command line: BOOT_IMAGE=/kernel-3.16.0-rc4-gd8dacc8 root=/dev/sda7 ro
init=/usr/lib/systemd/systemd

> 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.

No, probably not. I'll start a new bug if the issue is not related to bug
#74250.

(In reply to comment #131)
> DPM seems to be working here.

I guess you have a unmodified reference design card ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #132 from Kai  ---
(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 avgsclk: 3 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: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #131 from Marek Ol??k  ---
DPM seems to be working here. If I do "sudo cat
/sys/kernel/debug/dri/64/radeon_pm_info" with no 3D app running, I get:

power level avgsclk: 30047 mclk: 15000

If I do the same while glxgears is running, I get:

power level avgsclk: 8 mclk: 112500

That said, the performance seems to be lower than Bonaire. The open source game
Torcs has 27 FPS with Bonaire and 18 FPS with Hawaii. radeontop shows 100% GPU
usage with Hawaii while Torcs is running.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #130 from Luzipher  ---
(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 avgsclk: 3 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 ?


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).
Any requests on which issues should get their own bugs now ? Turning off HDMI-0
and Glyphs come to mind ?

Oh and I had a typo in my last comment - of course I updated bug #74250. Is
that maybe related to my never changing power states ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #129 from Kai  ---
(In reply to comment #128)
> (In reply to comment #127)
> > 
> > With the latest round of patches and builds, I'm falling back to llvmpipe
> > again. I gues I know the reason: I probably need a different patch for the
> > DDX than
> >  > conditionally.patch>, right? I asked multiple times (comment #117 and
> > comment #121) but nobody reacted to that and now I'm seeing no error
> > anywhere, but I do see
> > > [48.086] (--) RADEON(0): Chipset: "HAWAII" (ChipID = 0x67b1)
> > > [48.086] (II) RADEON(0): GPU accel disabled or not working, using 
> > > shadowfb for KMS
> > in Xorg.0.log again.
> > 
> > As soon as that is resolved, I'm happy to move this to follow-up bugs (like
> > speed in 3D applications).
> 
> The latest ddx patch is on the mailing list:
> http://lists.x.org/archives/xorg-driver-ati/2014-July/026517.html

Thank you very much! Now everything is back to working as before. ;-)

As far as I'm concerned this bug can be closed and I can open new ones for the
misrendered glyphs, the lacking 3D performance (e.g. 9 FPS in "XCOM: Enemy
Unknown", as reported by the Gallium HUD), etc.

Thanks to all, who helped getting Hawaii support in shape.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #128 from Alex Deucher  ---
(In reply to comment #127)
> 
> With the latest round of patches and builds, I'm falling back to llvmpipe
> again. I gues I know the reason: I probably need a different patch for the
> DDX than
>  conditionally.patch>, right? I asked multiple times (comment #117 and
> comment #121) but nobody reacted to that and now I'm seeing no error
> anywhere, but I do see
> > [48.086] (--) RADEON(0): Chipset: "HAWAII" (ChipID = 0x67b1)
> > [48.086] (II) RADEON(0): GPU accel disabled or not working, using 
> > shadowfb for KMS
> in Xorg.0.log again.
> 
> As soon as that is resolved, I'm happy to move this to follow-up bugs (like
> speed in 3D applications).

The latest ddx patch is on the mailing list:
http://lists.x.org/archives/xorg-driver-ati/2014-July/026517.html

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #127 from Kai  ---
(In reply to comment #125)
> I think it's time to resolve this report; any remaining issues should be
> tracked in separate reports.

NAK!

With the latest round of patches and builds, I'm falling back to llvmpipe
again. I gues I know the reason: I probably need a different patch for the DDX
than
,
right? I asked multiple times (comment #117 and comment #121) but nobody
reacted to that and now I'm seeing no error anywhere, but I do see
> [48.086] (--) RADEON(0): Chipset: "HAWAII" (ChipID = 0x67b1)
> [48.086] (II) RADEON(0): GPU accel disabled or not working, using 
> shadowfb for KMS
in Xorg.0.log again.

As soon as that is resolved, I'm happy to move this to follow-up bugs (like
speed in 3D applications).

My stack is:
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Linux: Git:~agdf5/linux:drm-next-3.17-rebased-on-fixes:6e07731f71 (calls itself
3.16-rc6)
libdrm: Git:master/libdrm-2.4.56
LLVM: 3.5 RC1
libclc: Git:master/0ec7437d9c
Mesa: Git:master/85109bc507
DDX: 1:7.4.0-2 + Patch from
http://people.freedesktop.org/~agd5f/0001-radeon-enable-hawaii-accel-conditionally.patch
X: 2:1.16.0-1 (1.16.0)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #126 from Alex Deucher  ---
(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 avgsclk: 3 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #125 from Michel D?nzer  ---
I think it's time to resolve this report; any remaining issues should be
tracked in separate reports.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #124 from Luzipher  ---
(In reply to comment #120)
> (In reply to comment #119)
> > (In reply to comment #88)
> > > Try re-grabbing my drm-next-3.17-wip tree.  I dropped the last commit.
> > 
> > Alex, are you going to reapply the dropped patch for the ASIC_ProfilingInfo
> > v3.1 table ? Or does it need to be handled differently ? Just so you don't
> > forget ;-)
> 
> Can someone test it to see if it fixes any issues other than the messages in
> the log?  I don't have a hawaii board with that table version.

Hm, I'll test if there is any change with your unmodified
drm-next-3.17-rebased-on-fixes branch (no v3.1 patch).


Other than that (all still with the v3.1 patch included):
I can reliably cause GPU resets with entering the world in World of Warcraft
(see previous comment #97 for a dmesg). I never gat a rendered image before the
game crashes.

I didn't yet notice more corrupted glyphs, but the single one I saw was a black
rectangle.

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 avgsclk: 3 mclk: 15000

I also updated bug #72450 regarding the ASIC_ProfilingInfo v3.1 table with some
new information.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #123 from Alex Deucher  ---
(In reply to comment #121)
> (In reply to comment #120)
> > (In reply to comment #119)
> > > (In reply to comment #88)
> > > > Try re-grabbing my drm-next-3.17-wip tree.  I dropped the last commit.
> > > 
> > > Alex, are you going to reapply the dropped patch for the 
> > > ASIC_ProfilingInfo
> > > v3.1 table ? Or does it need to be handled differently ? Just so you don't
> > > forget ;-)
> > 
> > Can someone test it to see if it fixes any issues other than the messages in
> > the log?  I don't have a hawaii board with that table version.
> 
> What kind of issues would I be looking for? (I think I see the relevant
> error message:
> > [drm:radeon_atom_get_leakage_vddc_based_on_leakage_params] *ERROR* Unknown 
> > table version 3, 1
> but I didn't see any issues besides what I've reported here (mainly missing
> speed))

That issue is tracked separately in bug 74250.  As for the performance, check
sudo cat /sys/kernel/debug/dri/64/radeon_pm_info and see if the values in there
look sane and if they scale up properly with 3D load.  Report any issues
related to that on bug 74250.

Here's the 3.17 rebased on fixes branch:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-rebased-on-fixes

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #122 from Kai  ---
(In reply to comment #106)
> (In reply to comment #105)
> > Kai: did changing "Composition type" also fix the corrupted glyphs or just
> > the title bars ? I've seen exactly one corrupted glyph in firefox so far
> > (several hours of use) on cinnamon (but I'm not sure what cinnamon uses as I
> > couldn't find any settings related to opengl).
> 
> Can't say for sure. With XRender I saw a corrupted glyph almost immediately
> on the first page I visited. Since switching to OpenGL as "compositing type"
> in KDE's settings, I haven't seen a corrupt glyph. But it could also be
> coincidence.

Just to get back to this: I'm still seeing misrendered glyphs from time to
time. The way they are misrendered is different each time. Sometimes I get just
a black block, sometimes what can be seen in the image I posted, etc. It's also
not just limited to the browser, even though I can observe it there most often.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #121 from Kai  ---
(In reply to comment #120)
> (In reply to comment #119)
> > (In reply to comment #88)
> > > Try re-grabbing my drm-next-3.17-wip tree.  I dropped the last commit.
> > 
> > Alex, are you going to reapply the dropped patch for the ASIC_ProfilingInfo
> > v3.1 table ? Or does it need to be handled differently ? Just so you don't
> > forget ;-)
> 
> Can someone test it to see if it fixes any issues other than the messages in
> the log?  I don't have a hawaii board with that table version.

What kind of issues would I be looking for? (I think I see the relevant error
message:
> [drm:radeon_atom_get_leakage_vddc_based_on_leakage_params] *ERROR* Unknown 
> table version 3, 1
but I didn't see any issues besides what I've reported here (mainly missing
speed))


And just to ensure this doesn't get overlooked: if we need a new version of the
DDX patch (since the kernel is now returning a "2" to signal acceleration),
please provide that as well. ;-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #120 from Alex Deucher  ---
(In reply to comment #119)
> (In reply to comment #88)
> > Try re-grabbing my drm-next-3.17-wip tree.  I dropped the last commit.
> 
> Alex, are you going to reapply the dropped patch for the ASIC_ProfilingInfo
> v3.1 table ? Or does it need to be handled differently ? Just so you don't
> forget ;-)

Can someone test it to see if it fixes any issues other than the messages in
the log?  I don't have a hawaii board with that table version.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #119 from Luzipher  ---
(In reply to comment #88)
> Try re-grabbing my drm-next-3.17-wip tree.  I dropped the last commit.

Alex, are you going to reapply the dropped patch for the ASIC_ProfilingInfo
v3.1 table ? Or does it need to be handled differently ? Just so you don't
forget ;-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #118 from Alex Deucher  ---
I'll post a link to a new git tree with the radeon 3.17 changes rebased on
drm-fixes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #117 from Kai  ---
(In reply to comment #116)
> (In reply to comment #115)
> > I found
> >  > 16=f53f81b2576a9bd3af947e2b1c3a46dfab51c5ef>. Is that the correct commit
> > for Hawaii?
> 
> Yes, but you probably want all page-flipping related fixes.

Ok. I tried to pick all those page-flipping patches from Mario Kleiner over,
but I could only get 60c90d98ba00f7f8e8ec55f6b24096372f57e9a4 and
5900fdc42ca3cbbc50bab7133750459a165a5cca to apply. The other two failed and the
code looked quite different, so I left them out. If I need either
826484977c29b42c8cb8c42bd41acaa6e152a4bb or
5f87e090a7368adc2290ae17ffd82a070caadd20), then any help in adapting them,
would be appreciated very much.

> > Doesn't look like the appropriate commit to me (so much "Evergreen"
> > everywhere),
> 
> The programming of that hardware block hasn't changed since Evergreen.

Ok, was just irritated by all the changes happening in evergreen.c and similar
"non-CIK" named files. But I didn't check the entire include chain. ;-) Thanks
for clearing this up.


With regard to
:
does that mean, that I would need a new version of
?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #116 from Michel D?nzer  ---
(In reply to comment #115)
> I found
>  16=f53f81b2576a9bd3af947e2b1c3a46dfab51c5ef>. Is that the correct commit
> for Hawaii?

Yes, but you probably want all page-flipping related fixes.

> Doesn't look like the appropriate commit to me (so much "Evergreen"
> everywhere),

The programming of that hardware block hasn't changed since Evergreen.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #115 from Kai  ---
(In reply to comment #106)
> Playing streams (live and recorded broadcasts) from Twitch with this setup
> is, however, neigh impossible. With the open driver and GLAMOR acceleration,
> X uses 80 % CPU time on one core and the video becomes a dia show. The Flash
> plugin is at 40 % CPU time (different core), but that's roughly the same as
> with fglrx. (For reference: my CPU is an Intel Core i7-3770K.)

After some further testing yesterday I could only reproduce the stalling of X
with "recorded brodcasts" on Twitch. It doesn't matter what stream quality you
pick (if you're patient enough to get that menu open). X starts hogging all
resources on one CPU core as soon as you load any recording (I tried four
different recordings). Live broadcasts/streams worked normally yesterday
afternoon/evening and today.


(In reply to comment #114)
> (In reply to comment #108)
> > Btw, watching a video on Twitch spams my Xorg.0.log with *tons* of:
> > > [ 21013.158] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> > > completion event has impossible msc 2822274 < target_msc 2822275
> 
> These are fixed in drm-fixes-3.16, but that hasn't been merged into
> drm-next-3.17-wip yet.

Ah, ok. I found
.
Is that the correct commit for Hawaii? Doesn't look like the appropriate commit
to me (so much "Evergreen" everywhere), but it was the only one a search for
radeon_dri2_flip_event_handler yielded.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #114 from Michel D?nzer  ---
(In reply to comment #108)
> Btw, watching a video on Twitch spams my Xorg.0.log with *tons* of:
> > [ 21013.158] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> > completion event has impossible msc 2822274 < target_msc 2822275

These are fixed in drm-fixes-3.16, but that hasn't been merged into
drm-next-3.17-wip yet.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #113 from Kai  ---
Oh, and I needed the three Mesa patches "radeonsi: fix CMASK and HTILE
calculations for Hawaii", "gallium/util: add a helper for calculating primitive
count from vertex count" and "radeonsi: fix a hang with instancing on Hawaii"
to get into my KDE desktop, maybe it's the same for X -retro. The other Mesa
patches can't hurt either (I have them applied now).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #112 from Kai  ---
(In reply to comment #111)
> Created attachment 103550 [details]
> xorg log with drm-next-3.17-wip with x -retro and starting xterm

Just FYI: all "working" reports came from people with a stable X.Org 1.16.0
AFAIK. Maybe you want to try that instead of your development version?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #111 from Serkan Hosca  ---
Created attachment 103550
  --> https://bugs.freedesktop.org/attachment.cgi?id=103550=edit
xorg log with drm-next-3.17-wip with x -retro and starting xterm

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #110 from Serkan Hosca  ---
Created attachment 103549
  --> https://bugs.freedesktop.org/attachment.cgi?id=103549=edit
dmesg with drm-next-3.17-wip with x -retro and starting xterm

(In reply to comment #109)
> (In reply to comment #105)
> > (In reply to comment #103)
> > > Not working for me. I've updated the firmware files and using agd5f's
> > > drm-next-3.17-wip branch. I can't switch to other vt's, it gets stuck with
> > > the boot messages on vt1. Haven't tried starting X yet.
> > 
> > Your dmesg shows that you have a ASIC_ProfilingInfo v3.1 table on your
> > board. You might want to try a patch from bug #73420: attachement #93015.
> > The issue itself is tracked in bug #74250.
> 
> Tried attachment #93015 [details] [review] from bug #73420 and i get a hard
> lock up, can't even ssh the machine

Scratch that, my mistake, the attachment worked, cleared up those messages. I
can start x -retro but when i try to launch xterm gpu crashes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #109 from Serkan Hosca  ---
(In reply to comment #105)
> (In reply to comment #103)
> > Not working for me. I've updated the firmware files and using agd5f's
> > drm-next-3.17-wip branch. I can't switch to other vt's, it gets stuck with
> > the boot messages on vt1. Haven't tried starting X yet.
> 
> Your dmesg shows that you have a ASIC_ProfilingInfo v3.1 table on your
> board. You might want to try a patch from bug #73420: attachement #93015.
> The issue itself is tracked in bug #74250.

Tried attachment #93015 from bug #73420 and i get a hard lock up, can't even
ssh the machine.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #108 from Kai  ---
Btw, watching a video on Twitch spams my Xorg.0.log with *tons* of:
> [ 21013.158] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2822274 < target_msc 2822275
> [ 21075.557] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2826015 < target_msc 2826016
> [ 21139.338] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2829840 < target_msc 2829841
> [ 21161.360] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2831160 < target_msc 2831161
> [ 21163.677] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2831298 < target_msc 2831299
> [ 21163.811] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2831306 < target_msc 2831307
> [ 21178.130] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2832164 < target_msc 2832165
> [ 21209.838] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2834066 < target_msc 2834067
> [ 21267.601] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2837529 < target_msc 2837530
> [ 21273.836] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2837902 < target_msc 2837903
> [ 21483.986] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2850507 < target_msc 2850508
> [ 21516.393] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2852450 < target_msc 2852451
> [ 21668.162] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2861549 < target_msc 2861550
> [ 21699.370] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2863419 < target_msc 2863420
> [ 21699.837] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2863446 < target_msc 2863447
> [ 21731.427] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2865340 < target_msc 2865341
> [ 21899.500] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2875419 < target_msc 2875420
> [ 21906.569] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2875843 < target_msc 2875844
> [ 21906.835] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> completion event has impossible msc 2875859 < target_msc 2875860

AFAICT this happens only in fullscreen mode.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #107 from Marek Ol??k  ---
Yeah, it looks like Hawaii is underclocked or something. It's a lot slower than
my Bonaire.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #106 from Kai  ---
(In reply to comment #105)
> Other than that I can report Civ5, Half Life 2 and even Metro Last Light
> working on Hawaii now (native via Steam) :-)

I can confirm Portal 2 (Source), Jagged Alliance: Flashback (Unity) and XCOM:
Enemy Unknown (Unreal Engine 3) as working, though the performance in XCOM is
abysmal (9 FPS) and after a while you get GPU stalls (system recovered after a
short block and I could continue, but it's of course not much fun).
The other games have room to improve as well. But that was to be expected at
this point. Still, having more performance with the free driver would be really
nice. ;-)

Playing streams (live and recorded broadcasts) from Twitch with this setup is,
however, neigh impossible. With the open driver and GLAMOR acceleration, X uses
80 % CPU time on one core and the video becomes a dia show. The Flash plugin is
at 40 % CPU time (different core), but that's roughly the same as with fglrx.
(For reference: my CPU is an Intel Core i7-3770K.)

> Kai: did changing "Composition type" also fix the corrupted glyphs or just
> the title bars ? I've seen exactly one corrupted glyph in firefox so far
> (several hours of use) on cinnamon (but I'm not sure what cinnamon uses as I
> couldn't find any settings related to opengl).

Can't say for sure. With XRender I saw a corrupted glyph almost immediately on
the first page I visited. Since switching to OpenGL as "compositing type" in
KDE's settings, I haven't seen a corrupt glyph. But it could also be
coincidence.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #105 from Luzipher  ---
(In reply to comment #103)
> Not working for me. I've updated the firmware files and using agd5f's
> drm-next-3.17-wip branch. I can't switch to other vt's, it gets stuck with
> the boot messages on vt1. Haven't tried starting X yet.

Your dmesg shows that you have a ASIC_ProfilingInfo v3.1 table on your board.
You might want to try a patch from bug #73420: attachement #93015.
The issue itself is tracked in bug #74250.

Other than that I can report Civ5, Half Life 2 and even Metro Last Light
working on Hawaii now (native via Steam) :-)

Kai: did changing "Composition type" also fix the corrupted glyphs or just the
title bars ? I've seen exactly one corrupted glyph in firefox so far (several
hours of use) on cinnamon (but I'm not sure what cinnamon uses as I couldn't
find any settings related to opengl).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #104 from Kai  ---
(In reply to comment #98)
> After some playing around, I do see some (minor) visual issues. See
> https://imgur.com/a/uswfc for some screenshots and descriptions.

Ignore this, this was most likely a layer 8 problem. I just noticed, that the
"Compositing type" for KDE's desktop effects has been XRender instead of
"OpenGL 3.1" (not sure how that changed back; maybe I had to do it for fglrx
and don't remember). Now that I've changed that, all title bars are rendered
correctly. XRender never worked with GLAMOR since I've started using GLAMOR
(IIRC it was something close to 0.3).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #103 from Serkan Hosca  ---
Created attachment 103527
  --> https://bugs.freedesktop.org/attachment.cgi?id=103527=edit
dmesg with drm-next-3.17-wip

Not working for me. I've updated the firmware files and using agd5f's
drm-next-3.17-wip branch. I can't switch to other vt's, it gets stuck with the
boot messages on vt1. Haven't tried starting X yet.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #102 from Kai  ---
(In reply to comment #101)
> You can either disable MSAA in your apps (graphics settings in games, etc.)
> or you can apply this libdrm patch ;)
> http://lists.freedesktop.org/archives/dri-devel/2014-July/064743.html

Ah, ok. I thought there was some DRI option I was unaware of. I build libdrm
with the patch, seems the better solution to me. Thanks again!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #101 from Marek Ol??k  ---
You can either disable MSAA in your apps (graphics settings in games, etc.) or
you can apply this libdrm patch ;)
http://lists.freedesktop.org/archives/dri-devel/2014-July/064743.html

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #100 from Kai  ---
(In reply to comment #99)
> BTW, MSAA may be broken and I recommend turning it off for now.

Ok, how do I do that? I'm only aware of the debug flag "msaa". My radeon(4) man
page didn't yield anything for MSAA either and a quick grep over the Mesa code
pointed only to code actually handling MSAA (or dealing with the debug flag).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #99 from Marek Ol??k  ---
BTW, MSAA may be broken and I recommend turning it off for now.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #98 from Kai  ---
After some playing around, I do see some (minor) visual issues. See
https://imgur.com/a/uswfc for some screenshots and descriptions.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #97 from Luzipher  ---
Created attachment 103500
  --> https://bugs.freedesktop.org/attachment.cgi?id=103500=edit
dmesg with working acceleration (Marek's patches): WoW GPU reset

Yay, with your seven patches, Marek, it works with the built-in glamor-1.0.0 !
Thanks a lot !

The following patches were applied:

[Mesa-dev] [PATCH 1/2] r600g, radeonsi: add debug flags which disable tiling
http://lists.freedesktop.org/archives/mesa-dev/2014-July/064127.html

[Mesa-dev] [PATCH 2/2] radeonsi: fix CMASK and HTILE calculations for Hawaii
http://lists.freedesktop.org/archives/mesa-dev/2014-July/064128.html

[Mesa-dev] [PATCH 1/3] gallium/util: add a helper for calculating primitive
count from vertex count
http://lists.freedesktop.org/archives/mesa-dev/2014-July/064129.html

[Mesa-dev] [PATCH 2/3] radeonsi: fix a hang with instancing on Hawaii
http://lists.freedesktop.org/archives/mesa-dev/2014-July/064130.html

[Mesa-dev] [PATCH 3/3] radeonsi: fix a hang with streamout on Hawaii
http://lists.freedesktop.org/archives/mesa-dev/2014-July/064131.html

[Mesa-dev] [PATCH] winsys/radeon: fix vram_size overflow with Hawaii
http://lists.freedesktop.org/archives/mesa-dev/2014-July/064137.html

[Mesa-dev] [PATCH] radeonsi: fix occlusion queries on Hawaii
http://lists.freedesktop.org/archives/mesa-dev/2014-July/064138.html


With those the transparency and flickery effects I described in comment #91 are
gone !

World of Warcraft still crashes when entering the world, but not fatally
anymore (there is a GPU reset and black screens for a while, but it recovers
and only the game crashes). I attached the dmesg of the crash, Xorg.0.log
doesn't show anything. I'm not sure if the GPU faults / VM faults visible in
the log are related to the game, but they probably occured while I logged in
and selected a character.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #96 from Kai  ---
(In reply to comment #94)
> (In reply to comment #86)
> > Created attachment 103474 [details] [review] [review]
> > Hack to temporarily fix accel
> > 
> > If you want working desktop you can use this patch to disable the packet
> > that is the issue. With that mesa patch i have stable acceleration and
> > desktop.
> 
> I don't recommend this patch. It disables updates to resource descriptors in
> some cases, which means you'll get resource bindings from old draw packets
> or even old IBs, which will cause VM faults or even hangs. I think it also
> breaks MSAA and might cause hangs there too (CMASK must be cleared).
> 
> Hawaii works without the patch very well here. I'm only using Alex's stuff
> from comment 81 and my Mesa fixes. Nothing else.

IT WORKS! Thanks to Alex, Marek, J?r?me and all the others involved!
The stack I used was (base is Debian Testing):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Linux: ~agdf5/linux:drm-next-3.17-wip (calls itself 3.16-rc4?)
libdrm: 2.4.54-1
LLVM: 3.5 RC1
libclc: Git:master/0ec7437d9c
Mesa: Git:master/74e100affc + the three patches Marek named ("radeonsi: fix
CMASK and HTILE calculations for Hawaii"; "gallium/util: add a helper for
calculating primitive count from vertex count"; "radeonsi: fix a hang with
instancing on Hawaii") and can be found on mesa-dev.
DDX: 1:7.4.0-2 + Patch from
http://people.freedesktop.org/~agd5f/0001-radeon-enable-hawaii-accel-conditionally.patch
X: 2:1.16.0-1 (1.16.0)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #95 from Luzipher  ---
Thank again, Kai, indeed my xorg-server used glamor 0.6.0.

Ok, so it's not really trivial to get xorg-server-1.16 working right with the
built-in glamor 1.0.0 on gentoo. The ebuilds for xorg-server-1.16,
xorg-drivers-1.16 and xf86-video-ati are borked. I'll file a bugreport on their
bugtracker later. If anyone here is interested, I could attach the ebuilds I
altered here.

But back on topic, I finally got it all working with the built in glamor - and
with that I'm seeing exactly what Kai described in comment #82.

(In reply to comment #94)
> Hawaii works without the patch very well here. I'm only using Alex's stuff
> from comment 81 and my Mesa fixes. Nothing else.

Next I'll try your patches, Marek - I guess you mean the ones on the mailing
list ? Is there a git-repo where you have them ? I checked your stuff for mesa
on freedesktop, but couldn't see anything there.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #94 from Marek Ol??k  ---
(In reply to comment #86)
> Created attachment 103474 [details] [review]
> Hack to temporarily fix accel
> 
> If you want working desktop you can use this patch to disable the packet
> that is the issue. With that mesa patch i have stable acceleration and
> desktop.

I don't recommend this patch. It disables updates to resource descriptors in
some cases, which means you'll get resource bindings from old draw packets or
even old IBs, which will cause VM faults or even hangs. I think it also breaks
MSAA and might cause hangs there too (CMASK must be cleared).

Hawaii works without the patch very well here. I'm only using Alex's stuff from
comment 81 and my Mesa fixes. Nothing else.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #93 from Luzipher  ---
Created attachment 103497
  --> https://bugs.freedesktop.org/attachment.cgi?id=103497=edit
dmesg with working acceleration: GPU faults

I just looked at my dmesg (with the same running system as described in comment
#91) and noticed quite a few "GPU faults" logged there (see attachement).

My Xorg.0.log looks clean though (only the EDID information of one of my
monitors was printed out waaay after I started X, at timestamps 1705 and 3420.
But I believe that was when powersaving switched off the screens).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #92 from Kai  ---
(In reply to comment #91)
> Thanks Kai, for your answers. I got it working now as well - in fact I'm
> typing from an accelerated xorg that's running for over an hour now.

yw; happy I could help.

> - glamor 0.6.0 (is that still necessary with xorg 1.16 ?)

No (as I've indicated in comment #85); my understanding is, that only the
integrated version is maintained at this point. You might even have overwritten
the integrated libglamoregl.so with the externel version? You can check which
one you loaded by looking in your Xorg.0.log for the following lines:
> (II) Loading sub module "glamoregl"
> (II) LoadModule: "glamoregl"
> (II) Loading /usr/lib/xorg/modules/libglamoregl.so
> (II) Module glamoregl: vendor="X.Org Foundation"
>   compiled for 1.16.0, module version = 1.0.0
>   ABI class: X.Org ANSI C Emulation, version 0.4
and check what version you see. The integrated version is 1.0.0 and as you can
see from attachment 103450, my X started correctly with that. I just get a GPU
stall when the desktop should be drawn/shown the frist time. The last image I
see is the KDE loading screen with all icons.

> - kernel command line parameters: radeon.dpm=0 drm.rnodes=1

Oh, I didn't try those so far. I'll look into that and see if I can KDE loading
with those.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #91 from Luzipher  ---
Thanks Kai, for your answers. I got it working now as well - in fact I'm typing
from an accelerated xorg that's running for over an hour now.

I used:
- agd5f's kernel (drm-next-3.17-wip), including the "handle ASIC_ProfilingInfo
v3.1" patch
- ucode from comment #81 copied to "/lib/firmware/updates/$(uname -r)/radeon"
- xf86-video-ati with agd5f's patch from comment #81
- mesa git with glisse's patch from comment #86
- llvm git
- xorg-server 1.16
- glamor 0.6.0 (is that still necessary with xorg 1.16 ?)
- kernel command line parameters: radeon.dpm=0 drm.rnodes=1

I do not use any kind of login manager (gdm, kdm) for login, but plain old
text-mode, then typing startx.

Both xfce4 and cinnamon start up and work, but at least in cinnamon I get
massive flickering on mouse-overs or animated cursors (terminology). For
example the background image occupies the whole text-area where I type this
comment, whenever I move the mouse in or out (firefox). The same happens when I
type, but obly for 2-3 lines of the surrounding text.using the mouse-wheel to
scroll helps and corrects the display.

I am able to run glxgears. And I even tried World of Warcraft via wine, where I
could get to the character selection screen (3D character is displayed), but
upon entering the world, the machine crashed and I got the screen full of noise
as output (similar to what happened before the fix on crashes).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #90 from Kai  ---
(In reply to comment #88)
> Try re-grabbing my drm-next-3.17-wip tree.  I dropped the last commit.

I did; no change, still get that GPU stall.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #89 from Kai  ---
Created attachment 103477
  --> https://bugs.freedesktop.org/attachment.cgi?id=103477=edit
dmesg output after restarting X after lockup from comment #87

Oh, forgot to add: if I restart X after that, I get the attached additional
lines in dmesg.

After that I rebooted, logged into KDE (acceleration disabled), killed Konsole,
so it wouldn't automatically get startet and tried a login with acceleration
again. But still no luck: I'm still stuck on the last icon of the KDE loading
screen just before the desktop get's drawn the first time. After killing X I'm
seeing the GPU stall (see comment #83) again, just without the segfault in
Konsole.

Maybe it has something to do with the composition type and Qt graphic system
I've chosen in KDE for desktop effects? The composition type is set to "OpenGL
3.1" and the Qt graphic system is set to "Native".

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #88 from Alex Deucher  ---
Try re-grabbing my drm-next-3.17-wip tree.  I dropped the last commit.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #87 from Kai  ---
(In reply to comment #86) 
> If you want working desktop you can use this patch to disable the packet
> that is the issue. With that mesa patch i have stable acceleration and
> desktop.

Thanks J?r?me! The "EQ overflowing" is gone (same stack as detailed in comment
#82, except for Mesa, which is now at Git master/5eb11eb192 + the patch from
attachment 103474), but I'm still stuck on the KDE loading screen, just before
the desktop is drawn. After I kill X I see the three lines, I pasted in comment
#83, appearing again at the end of dmesg's output. So, no luck for me yet.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #86 from Jerome Glisse  ---
Created attachment 103474
  --> https://bugs.freedesktop.org/attachment.cgi?id=103474=edit
Hack to temporarily fix accel

If you want working desktop you can use this patch to disable the packet that
is the issue. With that mesa patch i have stable acceleration and desktop.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #85 from Kai  ---
I think I can answer your questions, since I got acceleration working up to the
point where it crashed (see comment #82).

(In reply to comment #84)
> I did as instructed, but couldn't yet get accel to work (llvmpipe is used).
> A few questions:
> 1. Do I need to rename the firmware files to uppercase ? (HAWAII_ce.bin
> instead of hawaii_ce.bin) ?

No. I didn't rename the files and they were correctly loaded.

> 2. Does the current radeon stuff already work with the glamor that got
> merged into xorg-server 1.16 or do I need the external glamor ? (does that
> work with 1.16 ?)

Yes. My 7.4.0 came up with the integrated GLAMOR. And just yesterday I helped a
friend with an OLAND to get it set up with the free drivers. His setup uses
also a 1.16.0 server and the DDX uses the integrated GLAMOR.

> 3. As far as I know, the "NoAccel" xorg.conf option was renamed to "Accel".
> Is that still necessary with your xf86-video-ati patch ?

My xorg.conf had only a 'Driver "radeon"' line (since I don't have the -ati
loader shim around). No "Accel" or other option was set (and yes, it's Accel
with 7.4.0).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #84 from Luzipher  ---
First: Thanks Alex for looking into this and making progress !

I did as instructed, but couldn't yet get accel to work (llvmpipe is used). A
few questions:
1. Do I need to rename the firmware files to uppercase ? (HAWAII_ce.bin instead
of hawaii_ce.bin) ?
2. Does the current radeon stuff already work with the glamor that got merged
into xorg-server 1.16 or do I need the external glamor ? (does that work with
1.16 ?)
3. As far as I know, the "NoAccel" xorg.conf option was renamed to "Accel". Is
that still necessary with your xf86-video-ati patch ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #83 from Kai  ---
After I killed X the following three lines appeared in dmesg's output:
> [ 1421.048407] konsole[1509]: segfault at e0 ip 7fa9e928a1dd sp 
> 7fff046f5160 error 4 in libkdeui.so.5.13.3[7fa9e8f1e000+445000]
> [ 1431.576124] radeon :01:00.0: ring 0 stalled for more than 1msec
> [ 1431.576130] radeon :01:00.0: GPU lockup (waiting for 
> 0x01eb last fence id 0x01de on ring 0)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #82 from Kai  ---
Created attachment 103450
  --> https://bugs.freedesktop.org/attachment.cgi?id=103450=edit
Xorg.0.log showing "EQ overflowing"

(In reply to comment #81)
> it's now working more or less.  grab the latest ucode here
> http://people.freedesktop.org/~agd5f/radeon_ucode/ucode.tar.gz and use my
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-wip kernel
> tree, plus this patch for ddx:
> http://people.freedesktop.org/~agd5f/0001-radeon-enable-hawaii-accel-
> conditionally.patch

I followed these instructions and everything seems to work, until KDM wants to
draw the desktop for the first time, then I see the following:
> (EE) [mi] EQ overflowing.  Additional events will be discarded until existing 
> events are processed.
> (EE) 
>(EE) Backtrace:
> [...]
> (EE) 
> (EE) [mi] These backtraces from mieqEnqueue may point to a culprit higher up 
> the stack.
> (EE) [mi] mieq is *NOT* the cause.  It is a victim.
> (EE) [mi] EQ overflow continuing.  100 events have been dropped.

The backtrace and "EQ overflow continuing" part repeats two times more. See the
attached Xorg.0.log for the backtraces.

The stack I used was (base is Debian Testing):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Linux: ~agdf5/linux:drm-next-3.17-wip (calls itself 3.16-rc4?)
libdrm: 2.4.54-1
LLVM: 3.5 RC1
libclc: Git:master/0ec7437d9c
Mesa: Git:master/bf1247936a
DDX: 1:7.4.0-2 + Patch
X: 2:1.16.0-1 (1.16.0)

Firmeware was put into /lib/firmware/updates/$(uname -r)/radeon (which
translates to /lib/firmware/updates/3.16.0-rc4-citadel/radeon).

Do I need to do something else? Disable tiling? DPM? Is this a remaining issue?
Or did I misunderstand, something and it is expected not to get KDE up and
running?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #81 from Alex Deucher  ---
it's now working more or less.  grab the latest ucode here
http://people.freedesktop.org/~agd5f/radeon_ucode/ucode.tar.gz and use my
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-wip kernel tree,
plus this patch for ddx:
http://people.freedesktop.org/~agd5f/0001-radeon-enable-hawaii-accel-conditionally.patch

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #80 from Alex Deucher  ---
(In reply to comment #79)
> Ok, this is weird: just out of curiosity I tried to launch Xorg with
> "-retro", then I do see errors logged (see attached excerpt from dmesg). If
> I run Xorg without parameters, I just end up with a black screen, no logged
> errors and Xorg.0.log looks like everything is fine (except for that
> "config_odev_get_int_attribute" error):

> Shouldn't I be seeing the same errors as with "-retro" as well?

-retro invokes acceleration while the non-retro case does not.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #79 from Kai  ---
Created attachment 102983
  --> https://bugs.freedesktop.org/attachment.cgi?id=102983=edit
dmesg: lock-up with Xorg -retro

Ok, this is weird: just out of curiosity I tried to launch Xorg with "-retro",
then I do see errors logged (see attached excerpt from dmesg). If I run Xorg
without parameters, I just end up with a black screen, no logged errors and
Xorg.0.log looks like everything is fine (except for that
"config_odev_get_int_attribute" error):
> [  1724.926] (--) RADEON(0): Chipset: "HAWAII" (ChipID = 0x67b1)
> [  1724.926] (EE) Error config_odev_get_int_attribute called for non integer 
> attrib 4
> [  1724.926] (II) Loading sub module "dri2"
> [  1724.926] (II) LoadModule: "dri2"
> [  1724.926] (II) Module "dri2" already built-in
> [  1724.926] (II) Loading sub module "glamoregl"
> [  1724.926] (II) LoadModule: "glamoregl"
> [  1724.926] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
> [  1724.931] (II) Module glamoregl: vendor="X.Org Foundation"
> [  1724.931]  compiled for 1.15.99.904, module version = 1.0.0
> [  1724.931]  ABI class: X.Org ANSI C Emulation, version 0.4
> [  1724.931] (II) glamor: OpenGL accelerated X.org driver based.
> [  1724.958] (II) glamor: EGL version 1.4 (DRI2):
> [  1724.975] (II) RADEON(0): glamor detected, initialising EGL layer.
> [  1724.975] (II) RADEON(0): KMS Color Tiling: disabled
> [  1724.975] (II) RADEON(0): KMS Color Tiling 2D: disabled
> [  1724.975] (II) RADEON(0): KMS Pageflipping: enabled
> [  1724.975] (II) RADEON(0): SwapBuffers wait for vsync: enabled
> [...]

Shouldn't I be seeing the same errors as with "-retro" as well?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #78 from Kai  ---
Ahrg, comment #77 was only half of what I wanted to add... (screwed the C up)

In Xorg.0.log I'm seeing
> (EE) Error config_odev_get_int_attribute called for non integer attrib 4
no matter whether I force acceleration on or not. Not sure, this is relevant
though.


In case I force HAWAII acceleration (same settings as Luzipher in comment #9)
on I end up with a black screen and the system is inaccessible directly. Over
SSH I found, that no error is logged to either Xorg.0.log or dmesg (I checked
journalctl as well, just to be sure, but nothing there as well). Issuing a
reboot command over SSH didn't work either. Would I need to set some kernel
variable to get info about a locked-up GPU?


The stack I used was (base is Debian Testing):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Linux: 3.15.5
libdrm: 2.4.54-1
LLVM: SVN:trunk/r213236
libclc: Git:master/0ec7437d9c
Mesa: Git:master/48deb4dbf2
DDX: 1:7.4.0-2
X: 2:1.15.99.904-1 (1.16.0 RC 4)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

Kai  changed:

   What|Removed |Added

 CC||kai at dev.carbon-project.org

--- Comment #77 from Kai  ---
Just an additional note: with 3.15.5 I'm seeing eight (one for each ring?)
instances of:
> [drm:radeon_atom_get_leakage_vddc_based_on_leakage_params] *ERROR* Unknown 
> table version 3, 1

Probably not important to the larger issue (no acceleration; fallback to
llvmpipe) here though.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #76 from Luzipher  ---
(In reply to comment #75)
> > LLVM triggered Diagnostic Handler: unsupported call to function
> > llvm.AMDGPU.rsq. in main
> 
> You need to update your LLVM SVN/Git snapshot.

Just a quick update if someone else runs into this problem: llvm doesn't build
with gcc 4.7 or 4.9, but it works with gcc 4.8.3.

Other than that I didn't get different results from the newest git code (mesa,
xf86-video-ati) on a patched kernel 3.16-rc2 - egltri_screen works once,
eglgears_screen produces garbage. But it seems somewhat more stable (no
unrecoverable crashes as far as I can remember). Xorg on the other hand seems
worse (no output anymore), but that might be the new in-server glamor stuff, I
guess.

I won't be able to continue investigations for a few days - the printks are
still on my todo list (or maybe gdb ...).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #75 from Michel D?nzer  ---
(In reply to comment #74)
> Ok, but how do I make sure that si_get_backend_mask() gets information from
> the kernel ?

By tracing its execution flow, either in gdb or by adding debugging printfs.


> > Also, might be worth testing with R600_DEBUG=nodma for now, to prevent the
> > userspace code from using the asynchronous DMA engine.
> Will do that.

Actually, that was a red herring, sorry; there's no asynchronous DMA support
yet for CIK.


> LLVM triggered Diagnostic Handler: unsupported call to function
> llvm.AMDGPU.rsq. in main

You need to update your LLVM SVN/Git snapshot.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #74 from Konstantin  ---
First, sorry for being away so long.

(In reply to comment #69)
> First of all, let me remind both of you to make sure si_get_backend_mask()
> gets the information from the kernel, and to use my patch which disables
> tiling as much as possible for now.
Ok, but how do I make sure that si_get_backend_mask() gets information from the
kernel ?

(In reply to comment #69)
> Also, might be worth testing with R600_DEBUG=nodma for now, to prevent the
> userspace code from using the asynchronous DMA engine.
Will do that.

(In reply to comment #69)
> That's all it's supposed to do, FWIW. :)
I guessed as much :-) I actually was quite excited that it worked.

(In reply to comment #69)
> Does it work if you add EGL_DRIVER=egl_dri2 ?
Unfortunately that didn't work. As output I get (note best driver is DRI2
instead of gallium):
# EGL_LOG_LEVEL=debug EGL_PLATFORM=drm EGL_DRIVER=egl_dri2 ./egltri_screen
libEGL debug: Native platform type: drm (environment overwrite)
libEGL debug: EGL search path is /usr/lib64/egl
libEGL debug: added egl_dri2 to module array
libEGL debug: the best driver is DRI2
EGL_VERSION = 1.4 (DRI2)
libEGL debug: attribute 0x3033 has an invalid value 0x8
libEGL debug: EGL user error 0x3004 (EGL_BAD_ATTRIBUTE) in eglChooseConfig
EGLUT: failed to choose a config

But on recent mesa it works again without EGL_DRIVER.

(In reply to comment #69)
> I'm afraid it's still too early to test in X. Even without -retro, the GPU
> is probably used for some operations via glamor, e.g. for the cursor image.
Well, I just tested again on yesterdays mesa (2014-06-22) and vanilla kernel
3.16-rc2 (no patches, cause I had problems on rc1). egltri_screen still works
once, then I get garbage, that now looks different (lots of small dots).

I also tried eglgears_screen, but that segfaults. I guess it's a problem in
llvm - and unfortunately llvm refuses to build for about 2 weeks now.
Output is:

LLVM triggered Diagnostic Handler: unsupported call to function
llvm.AMDGPU.rsq. in main
[  621.798733] traps: eglgears_screen[431] general protection ip:7f0cb3ae51d8
sp:7fffe17cfa10 error:0 in libLLVM-3.5svn.so[7f0cb2b35000+1af1000]
Segmentation fault

Next I'll try to get the kernel patches for disabling tiling running again and
use R600_DEBUG=nodma. Do I have to do anything about si_get_backend_mask() ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #73 from Michel D?nzer  ---
(In reply to comment #72)
> P.S. Both of these boxes have worked "well" to "excellent" in and have
> recently been going weird.

Your issues are not related to this bug report, though you might find some
advice for trouble shooting in here. Please file your own reports for your
issues.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #72 from Robert White  ---
P.S. Both of these boxes have worked "well" to "excellent" in and have recently
been going weird. Games that played recently (q.v. warzone2100) have stopped
working on both systems and, as said, the i965 is really suffering some display
rot.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #71 from Robert White  ---
I don't know if this will help at all, but I am getting similar errors on a
radeon laptop _and_ an i965 laptop. Im using the latest git as fetched by
gentoo layman overlay tools and linux 3.15.0 (and previously 3.14.{0,1,5,6}).

I'm missing some icons under xfce4 and kde is a right mess on the i965.

EGL_LOG_LEVEL=debug  eglgears_x11
libEGL debug: Native platform type: x11 (autodetected)
libEGL debug: EGL search path is /usr/lib64/egl
libEGL debug: added /usr/lib64/egl/egl_gallium.so to module array
libEGL debug: added egl_dri2 to module array
libEGL debug: dlopen(/usr/lib64/egl/egl_gallium.so)
libEGL info: use X11 for display 0x1fef010
libEGL info: created a pipe screen for r600
libEGL debug: the best driver is Gallium
EGL_VERSION = 1.4 (Gallium)
libEGL debug: the value (0x0) of attribute 0x3040 did not meet the criteria
(0x8)
libEGL debug: the value (0x0) of attribute 0x3040 did not meet the criteria
(0x8)
libEGL debug: the value (0x0) of attribute 0x3040 did not meet the criteria
(0x8)
libEGL debug: the value (0x0) of attribute 0x3040 did not meet the criteria
(0x8)
libEGL debug: the value (0x0) of attribute 0x3040 did not meet the criteria
(0x8)
libEGL debug: the value (0x0) of attribute 0x3040 did not meet the criteria
(0x8)
libEGL debug: the value (0x0) of attribute 0x3040 did not meet the criteria
(0x8)
... many duplicates sikpped ...
libEGL debug: the value (0x0) of attribute 0x3040 did not meet the criteria
(0x8)
EGLUT: failed to choose a config

vs

EGL_LOG_LEVEL=debug eglgears_screen 
libEGL debug: Native platform type: x11 (build-time configuration)
libEGL debug: EGL search path is /usr/lib64/egl
libEGL debug: added egl_dri2 to module array
libEGL debug: DRI2: dlopen(/usr/lib64/dri/i965_dri.so)
libEGL debug: DRI2: found extension `DRI_Core'
libEGL info: DRI2: found extension DRI_Core version 1
libEGL debug: DRI2: found extension `DRI_IMAGE_DRIVER'
libEGL debug: DRI2: found extension `DRI_DRI2'
libEGL info: DRI2: found extension DRI_DRI2 version 4
libEGL debug: DRI2: found extension `DRI_DriverVtable'
libEGL debug: DRI2: found extension `DRI_ConfigOptions'
libEGL debug: DRI2: found extension `DRI_TexBuffer'
libEGL info: DRI2: found extension DRI_TexBuffer version 3
libEGL debug: DRI2: found extension `DRI2_Flush'
libEGL info: DRI2: found extension DRI2_Flush version 4
libEGL debug: DRI2: found extension `DRI_IMAGE'
libEGL info: DRI2: found extension DRI_IMAGE version 8
libEGL debug: DRI2: found extension `DRI_RENDERER_QUERY'
libEGL debug: DRI2: found extension `DRI_CONFIG_QUERY'
libEGL debug: DRI2: found extension `DRI_Robustness'
libEGL debug: the value (0x4) of attribute 0x302f did not meet the criteria
(0x5)
... duplicates, though not as many, removed ...
libEGL debug: the value (0x4) of attribute 0x302f did not meet the criteria
(0x5)
libEGL debug: the best driver is DRI2
EGL_VERSION = 1.4 (DRI2)
libEGL debug: attribute 0x3033 has an invalid value 0x8
libEGL debug: EGL user error 0x3004 (EGL_BAD_ATTRIBUTE) in eglChooseConfig

EGLUT: failed to choose a config

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #70 from vincent  ---
Created attachment 99958
  --> https://bugs.freedesktop.org/attachment.cgi?id=99958=edit
dmesg with nodma + notiling

Oops sorry I forgot about the tiling patch. Unfortunatly it doesn't help,
with it I can see egltri_screen triangle but the monitor reset, and
eglgears_screen still display garbage.
Attached is the dmesg with the 2 apps tested.

By the way does clover use dma ? Clover runs fine, at least in simple case, but
with inputs and output verification, and back to the commit that introduced
hawaii support.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #69 from Michel D?nzer  ---
First of all, let me remind both of you to make sure si_get_backend_mask() gets
the information from the kernel, and to use my patch which disables tiling as
much as possible for now.

Also, might be worth testing with R600_DEBUG=nodma for now, to prevent the
userspace code from using the asynchronous DMA engine.


(In reply to comment #64)
> * egltri_screen from mesa-demos works, outputs a coloured triangle on grey
> background for 5s (with 3 monitors attached)

That's all it's supposed to do, FWIW. :)


(In reply to comment #65)
> Sometimes it even works again after a few invocations with garbage, but the
> triangle is not centered then, but offset to the left or right. The garbage
> also looks deterministic (always identical for the third and fourth
> invocation after a restart).

Still, I'd assume in those cases it doesn't actually render anything but just
displays leftovers from previous runs.

To differentiate that, I built a second copy of egltri_screen with all
rendering commands except for glClear() disabled (and a glClearColor() call
added for a distinctive clear colour). By running both copies alternatively, I
could be pretty sure whether what I'm seeing was rendered by the current run or
just a leftover.


(In reply to comment #68)
> I can't get EGL to work with newest mesa, with the following messages when 
> trying
> to run egltri_screen:
> # EGL_LOG_LEVEL="debug" EGL_PLATFORM="drm" ./egltri_screen

Does it work if you add EGL_DRIVER=egl_dri2 ?


> I attached a dmesg with patch 99839 from Christian K?nig but NOT patch 99594
> from Alex Deucher, with newest mesa, where I did a "Xorg -retro" start and
> then glxinfo (which garbles the screen).

I'm afraid it's still too early to test in X. Even without -retro, the GPU is
probably used for some operations via glamor, e.g. for the cursor image.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #68 from Luzipher  ---
Created attachment 99906
  --> https://bugs.freedesktop.org/attachment.cgi?id=99906=edit
xorg and then glxinfo with kernel patch from attachment 99839

Sorry, I have to make another correction to my last post - mesa wasn't from git
but from commit 58c659703bed86ea004a2e64ee231e3ba99b3d45. I can't get EGL to
work with newest mesa, with the following messages when trying to run
egltri_screen:
# EGL_LOG_LEVEL="debug" EGL_PLATFORM="drm" ./egltri_screen

libEGL debug: Native platform type: drm (environment overwrite)
libEGL debug: EGL search path is /usr/lib64/egl
libEGL debug: added /usr/lib64/egl/egl_gallium.so to module array
libEGL debug: added egl_dri2 to module array
libEGL debug: dlopen(/usr/lib64/egl/egl_gallium.so)
libEGL info: use DRM for display (nil)
libEGL debug: the best driver is Gallium
EGL_VERSION = 1.4 (Gallium)
libEGL debug: the value (0x0) of attribute 0x3040 did not meet the criteria
(0x8)
libEGL debug: the value (0x0) of attribute 0x3040 did not meet the criteria
(0x8)
libEGL debug: the value (0x0) of attribute 0x3040 did not meet the criteria
(0x8)
EGLUT: failed to choose a config


I attached a dmesg with patch 99839 from Christian K?nig but NOT patch 99594
from Alex Deucher, with newest mesa, where I did a "Xorg -retro" start and then
glxinfo (which garbles the screen). I think there might be some new messages
like:
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing C466 (len 254,
WS 0, PS 4) @ 0xC490
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing B9EC (len 145,
WS 0, PS 8) @ 0xBA77

And:
radeon :02:00.0: still active bo inside vm

Also glxgears still crashes and causes garbage, but it seems ore recoverable
(Ctrl-C makes the gpu reset cycle quit sometimes) and it seems to believe to
render more frames (messages like "3 frames in XXX sec" instead of "1 frame").


With older mesa egltri_screen still causes gpu resets and garbage.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #67 from vincent  ---
Created attachment 99886
  --> https://bugs.freedesktop.org/attachment.cgi?id=99886=edit
dmesg kernel 3.15+-disable-fence-wait-patch

egltri_screen doesnt work and only display garbage, and I have a message about
vm protection fault.
THere is also a couple of "radeon :01:00.0: failed to sync rings (-35)"
message

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #66 from Christian K?nig  ---
Created attachment 99839
  --> https://bugs.freedesktop.org/attachment.cgi?id=99839=edit
Possible fix

> Sorry I forget test=2 case, dmesg attached, radeon_fence_info is :

That looks like at least semaphores are not working as they should.

Please try the egl* tests with this workaround applied.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #65 from Luzipher  ---
Sorry, I have to correct myself somewhat: I can run egltri_screen exactly
*twice* with correct output. And I guess the second time only looks right,
because it displays what the first run left in memory. Even if I restart the
machine after elgtri_screen and the run eglgears_screen (!), I get the
triangle, not gears.
So I guess its only the first invocation that works. But it doesn't stall the
gpu, even if it outputs garbage (and nothing is printed in dmesg).

Sometimes it even works again after a few invocations with garbage, but the
triangle is not centered then, but offset to the left or right. The garbage
also looks deterministic (always identical for the third and fourth invocation
after a restart).

After some playing around I also got this from egltri_screen:
Will use screen size: 1920 x 1080
radeon: Failed to allocate virtual address for buffer:
radeon:size  : 4147200 bytes
radeon:alignment : 256 bytes
radeon:domains   : 4
radeon:va: 0x0182
radeon: Failed to allocate virtual address for buffer:
radeon:size  : 4147200 bytes
radeon:alignment : 256 bytes
radeon:domains   : 4
radeon:va: 0x0182
Segmentation fault
And the screen where the output would have shown went black (no signal), while
the other two stayed "alive".

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #64 from Luzipher  ---
Created attachment 99813
  --> https://bugs.freedesktop.org/attachment.cgi?id=99813=edit
dmesg of eglgears_screen with drm-fixes 3.15-rc6 and agd5f's use-old-hdp-flush
patch

(In reply to comment #58)
> Created attachment 99594 [details] [review]
> use old hdp flush
> 
> Does this kernel patch help?

I don't know if this info helps, but anyway:

With current stuff (llvm, glamor, mesa from git) and airlied's current
drm-fixes (commit 77c01bef72a5ce5cb24adae6066ed81a52004d30) with your
old-hdp-flush patch and the patch from bug 74250, I get:
* eglinfo works multiple times in a row
* egltri_screen from mesa-demos works, outputs a coloured triangle on grey
background for 5s (with 3 monitors attached)
* eglgears_screen garbles the screen, but it only stalls the gpu once or twice
(dmesg attached) and then returns to console
* and I can repeatedly run egltri_screen even after eglgears_screen ran

So for me it seems like quite an improvement.

I'd like to help further if possible, but I don't have any experience with gdb
unfortunately. If I can do anything else or if there are some detailed
instructions on what to do, just tell me and I'll try to find some time.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #63 from Alex Deucher  ---
(In reply to comment #62)
> What are rings 1 and rings 2 ? I suspect one of the ring is the constant
> engine but I'm not sure if it's currently supported or not.
> 

1 and 2 are compute rings.  The constant engine is part of the gfx ring.

> I've read that hawaii has something a gfx/compute command queue and 7
> compute only command queue, does they use the same ring ?

The gfx ring can execute gfx or compute work.  There are many compute rings on
CI hardware, but we currently only expose two.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #62 from vincent  ---
What are rings 1 and rings 2 ? I suspect one of the ring is the constant engine
but I'm not sure if it's currently supported or not.

I've read that hawaii has something a gfx/compute command queue and 7 compute
only command queue, does they use the same ring ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #61 from vincent  ---
Created attachment 99652
  --> https://bugs.freedesktop.org/attachment.cgi?id=99652=edit
dmesg kernel 3.12+ test=2

Sorry I forget test=2 case, dmesg attached, radeon_fence_info is :

--- ring 0 ---
Last signaled fence 0x0001
Last emitted0x0003
Last sync to ring 1 0x
Last sync to ring 2 0x
Last sync to ring 3 0x
Last sync to ring 4 0x
Last sync to ring 5 0x
--- ring 1 ---
Last signaled fence 0x0003
Last emitted0x0003
Last sync to ring 0 0x
Last sync to ring 2 0x
Last sync to ring 3 0x
Last sync to ring 4 0x
Last sync to ring 5 0x
--- ring 2 ---
Last signaled fence 0x0001
Last emitted0x0001
Last sync to ring 0 0x
Last sync to ring 1 0x
Last sync to ring 3 0x
Last sync to ring 4 0x
Last sync to ring 5 0x
--- ring 3 ---
Last signaled fence 0x0001
Last emitted0x0001
Last sync to ring 0 0x
Last sync to ring 1 0x
Last sync to ring 2 0x
Last sync to ring 4 0x
Last sync to ring 5 0x
--- ring 4 ---
Last signaled fence 0x0001
Last emitted0x0001
Last sync to ring 0 0x
Last sync to ring 1 0x
Last sync to ring 2 0x
Last sync to ring 3 0x
Last sync to ring 5 0x
--- ring 5 ---
Last signaled fence 0x0002
Last emitted0x0002
Last sync to ring 0 0x
Last sync to ring 1 0x
Last sync to ring 2 0x
Last sync to ring 3 0x
Last sync to ring 4 0x

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #60 from vincent  ---
I checked that eglinfo already worked with kernel 3.14.3 so the situation
didn't improve with the patch on kernel 3.15.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #59 from vincent  ---
Created attachment 99597
  --> https://bugs.freedesktop.org/attachment.cgi?id=99597=edit
dmesg with old-hdp patch (kernel 3.15+)

On top of kernel 3.15, unfortunatly not, eglinfo works well but egltri_screen
and eglgears_screen still render garbage (but they dont stall the gpu).

I'd like to apply it on 3.12+, commit 32f79a8a because that's where I made my
ring test but the patches doesnt apply cleanly, and the code seems to have
changed quite a lot in cik.c.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #58 from Alex Deucher  ---
Created attachment 99594
  --> https://bugs.freedesktop.org/attachment.cgi?id=99594=edit
use old hdp flush

Does this kernel patch help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #57 from vincent  ---
Created attachment 99592
  --> https://bugs.freedesktop.org/attachment.cgi?id=99592=edit
dmesg-test-1

radeon_fence_info with test 1

--- ring 0 ---
Last signaled fence 0x0001
Last emitted0x0001
Last sync to ring 1 0x
Last sync to ring 2 0x
Last sync to ring 3 0x
Last sync to ring 4 0x
Last sync to ring 5 0x
--- ring 1 ---
Last signaled fence 0x0001
Last emitted0x0001
Last sync to ring 0 0x
Last sync to ring 2 0x
Last sync to ring 3 0x
Last sync to ring 4 0x
Last sync to ring 5 0x
--- ring 2 ---
Last signaled fence 0x0001
Last emitted0x0001
Last sync to ring 0 0x
Last sync to ring 1 0x
Last sync to ring 3 0x
Last sync to ring 4 0x
Last sync to ring 5 0x
--- ring 3 ---
Last signaled fence 0x07f7
Last emitted0x07f7
Last sync to ring 0 0x
Last sync to ring 1 0x
Last sync to ring 2 0x
Last sync to ring 4 0x
Last sync to ring 5 0x
--- ring 4 ---
Last signaled fence 0x0001
Last emitted0x0001
Last sync to ring 0 0x
Last sync to ring 1 0x
Last sync to ring 2 0x
Last sync to ring 3 0x
Last sync to ring 5 0x
--- ring 5 ---
Last signaled fence 0x0002
Last emitted0x0002
Last sync to ring 0 0x
Last sync to ring 1 0x
Last sync to ring 2 0x
Last sync to ring 3 0x
Last sync to ring 4 0x

I didnt have any other message when loading the module.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #56 from Christian K?nig  ---
(In reply to comment #55)
> Do the messages like "[  124.822006] [drm] Tested GTT->VRAM and VRAM->GTT
> copy for GTT offset 0x3fe98000" and "[  124.822010] [drm] Testing syncing
> between rings 1 and 0..." mean that the test are actually passed ?

Yes the DMA actually seems to work when used for buffer moves.

The second message is from the second test which tries semaphore sync between
the different engines.

What the last message logged when you try to load the module?

Also please try radeon.test=1 and radeon.test=2 separately.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #55 from vincent  ---
Do the messages like "[  124.822006] [drm] Tested GTT->VRAM and VRAM->GTT copy
for GTT offset 0x3fe98000" and "[  124.822010] [drm] Testing syncing between
rings 1 and 0..." mean that the test are actually passed ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #54 from vincent  ---
Content of radeon_fence_info in this case is :

--- ring 0 ---
Last signaled fence 0x0002
Last emitted0x0003
Last sync to ring 1 0x
Last sync to ring 2 0x
Last sync to ring 3 0x
Last sync to ring 4 0x
Last sync to ring 5 0x
--- ring 1 ---
Last signaled fence 0x0003
Last emitted0x0003
Last sync to ring 0 0x
Last sync to ring 2 0x
Last sync to ring 3 0x
Last sync to ring 4 0x
Last sync to ring 5 0x
--- ring 2 ---
Last signaled fence 0x0001
Last emitted0x0001
Last sync to ring 0 0x
Last sync to ring 1 0x
Last sync to ring 3 0x
Last sync to ring 4 0x
Last sync to ring 5 0x
--- ring 3 ---
Last signaled fence 0x07f7
Last emitted0x07f7
Last sync to ring 0 0x
Last sync to ring 1 0x
Last sync to ring 2 0x
Last sync to ring 4 0x
Last sync to ring 5 0x
--- ring 4 ---
Last signaled fence 0x0001
Last emitted0x0001
Last sync to ring 0 0x
Last sync to ring 1 0x
Last sync to ring 2 0x
Last sync to ring 3 0x
Last sync to ring 5 0x
--- ring 5 ---
Last signaled fence 0x0002
Last emitted0x0002
Last sync to ring 0 0x
Last sync to ring 1 0x
Last sync to ring 2 0x
Last sync to ring 3 0x
Last sync to ring 4 0x


I can't run eglinfo in this case so I think it's expected that ring 0 does not
attempt to sync with ring 3.
I don't know if dmesg attached in #53 is enough to determine why the dma engine
is stalling.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #53 from vincent  ---
Created attachment 99591
  --> https://bugs.freedesktop.org/attachment.cgi?id=99591=edit
dmesg-using-test3

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #52 from Alex Deucher  ---
(In reply to comment #51)
> Unfortunatly with "radeon.test=3" the tty doesnt even appear, and it looks
> like sshd server is never run, I cant access anything :/

Try booting into a non-X runlevel and then manually loading radeon from the
command line.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #51 from vincent  ---
Unfortunatly with "radeon.test=3" the tty doesnt even appear, and it looks like
sshd server is never run, I cant access anything :/

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #50 from Christian K?nig  ---
(In reply to comment #47)
> When using the radeon.lockup_timeout=0 eglinfo (and every other egl apps)
> never finishes, probably waiting for a fence, but I still can switch tty.

That was expected, it probably just waits forever for some results.

> That's with kernel 3.12+ (otoh with 3.14.3 if I try to run a egl app, I have
> garbage on display and my monitor shutdown, and is never brought up, there
> is probably others issues introduced after hawaii commit as suggested)

That's why I suggested to work over the network, trying to debug gfx hardware
while the hardware is in use (e.g. it's your output device for debug messages)
is usually pointless.

> The radeon_fence_info are the same between several run.

Yeah, and the values are pretty interesting:

--- ring 0 ---
Last signaled fence 0x0001
Last emitted0x0002
...
Last sync to ring 3 0x0009

--- ring 3 ---
Last signaled fence 0x0001
Last emitted0x0009

Ring 0 is the 3D engine, ring 3 is the DMA engine. What we see here is that we
submitted some commands to the DMA engine which then got stuck.

The 3D engine is just waiting for the DMA to continue as well.

Try to load the radeon module with radeon.test=3 on the kernel command line
(keep in mind that this can take a while and will probably crash as well).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #49 from vincent  ---
Do you know which commits I should cherry-pick ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #48 from Michel D?nzer  ---
(In reply to comment #42)
> There is only one buffer_map(READ), in si_get_backend_mask, right after the
> buffer_map(WRITE) from si_get_backend_mask.

Please make sure the kernel has the commit(s) necessary to provide the backend
mask to userspace, so si_get_backend_mask() doesn't need to fall back to this
method.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #47 from vincent  ---
When using the radeon.lockup_timeout=0 eglinfo (and every other egl apps) never
finishes, probably waiting for a fence, but I still can switch tty. That's with
kernel 3.12+ (otoh with 3.14.3 if I try to run a egl app, I have garbage on
display and my monitor shutdown, and is never brought up, there is probably
others issues introduced after hawaii commit as suggested)

The radeon_fence_info are the same between several run.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #46 from vincent  ---
Created attachment 99513
  --> https://bugs.freedesktop.org/attachment.cgi?id=99513=edit
radeon_fence_info with egl second run

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #45 from vincent  ---
Created attachment 99512
  --> https://bugs.freedesktop.org/attachment.cgi?id=99512=edit
radeon_fence_info with egl first run

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #44 from vincent  ---
Created attachment 99511
  --> https://bugs.freedesktop.org/attachment.cgi?id=99511=edit
radeon_fence_info before running eglinfo

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #43 from Christian K?nig  ---
The hang caused by eglinfo is probably just because we try to clear a buffer on
init using hw accel or something like this.

Here are a couple of tips how to further narrow it down:

1. Don't work on the system you are trying to debug. Use another system and
access the box with the hardware over the network or even better with a serial
cable.

2. Add radeon.lockup_timeout=0 to the kernel commandline. This will disable
recovery after the first lockup. It doesn't make sense to try to debug all
lockups at the same time, we probably got more than one problem to solve.

3. After the system crashed take a look at the debugfs files under
/sys/kernel/debug/dri/0/, especially radeon_fence_info. If you lockup the GPU
does this always happen at the same command submitted? E.g. if you try twice do
you always get the same fence value? Or is this random?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: