Radeonsi is awesome, beats Catalyst!

[Veto]

LLVM register allocation bug

Seriously, this bug is the last really important hindrance for ditching Catalyst and switching to RadeonSI for real

My kids were having trouble with constant lock-ups of the complete computer when playing under Ubuntu 14.04 with Catalyst - requiring a hard reset. Also I bought the fabulous Goat Simulator which has just been released on Steam, but that had ugly artefacts and blinking. Last night I tried updating to Catalyst 14.6 - but that didn't really solve any issues. (*Crap*)

Then I tried going back to the RadeonSI, but e.g. Kerbal Space Program was running like a slide show. After updating with Oibaf's PPA everything seems to be running really smooth now - except Goat Simulator, which barfs with the LLVM register allocation bug. Boot sequence and switching in/out of fullscreen games is much smoother now. No total system freezes yet.

Quick rundown of Ubuntu 14.04 with Oibafs PPA per 2014-06-28. (Intel i5-3570K with AMD HD7750)

• Kerbel Space Program Demo - Works fine!
• Portal 2 - Works fine!
• Goat Simulator - Crashes with the LLVM register allocation bug
• Trine 2 - Works fine!
• Antichamber - Works fine!
• Minecraft - Works fine!
• Warthunder (under Wine) - Works sort of OK (Similar to Catalyst)

I really, really hope they manage to wrap it up before Ubuntu 14.10

[Pontostroy]

[*]Goat Simulator - Crashes with the LLVM register allocation bug

With llvm from svn Goat Simulator works fine

[Veto]

With llvm from svn Goat Simulator works fine

Nice! May I ask how you installed the updated llvm? Was it manually compiled or did you install from a PPA? Does it require recompile of mesa also or are they independent?

[dungeon]

Nice! May I ask how you installed the updated llvm? Was it manually compiled or did you install from a PPA? Does it require recompile of mesa also or are they independent?

You can install latest llvm-svn deb packages via this repo on Debian or Ubuntu:

http://llvm.org/apt/

But mesa must be compiled against that llvm 3.5 version, because oibaf ppa mesa packages currently use 3.4 version.

[Pontostroy]

Nice! May I ask how you installed the updated llvm? Was it manually compiled or did you install from a PPA? Does it require recompile of mesa also or are they independent?

For openSUSE i build mesa,ddx,llvm,x-server ... from git in my repository http://download.opensuse.org/reposit...ntostroy:/X11/ and for kernel http://download.opensuse.org/reposit...roy:/drm-next/

[Dukenukemx]

Quick rundown of Ubuntu 14.04 with Oibafs PPA per 2014-06-28. (Intel i5-3570K with AMD HD7750)

• Portal 2 - Works fine!
• Minecraft - Works fine!

I really, really hope they manage to wrap it up before Ubuntu 14.10

These game I've already played thoroughly with my Laptop (Intel i3 380M with AMD HD6370) using Oibaf's PPA. Especially the Portal games, which works fine but requires a lot of tuning. Things like S3TC, disable vsync, and enabling HyperZ.

[jrch2k8]

No matter what I do (cpulimt/taskset) there doesn't seem to be any noticable difference. I guess it could be that Ivy Bridge graphics are just not powerful enough to see any change. Or it could just be that this cpu use doesn't really matter for OpenArena. Either way my latest patch reduce OpenAL's cpu use by 45% which should be a good thing regradless I guess.

don't take this religiously but i believe depending the GPU the CPU speed has little to do with performance at FPS beyond bandwidth

1.) because the command streaming process is serialised not parallel(may have changed not 100% sure)
2.) because this days the CPU mostly upload stuff to the GPU and then the GPU takes over except shader compilation and other minors details, so if the application doesn't constantly upload data specially shaders and textures (big engines do this a lot) the CPU hit over FPS should be minimal as long as the bandwidth is enough

so, if you wanna have noticeable changes in 3D apps, i believe the first place to look is the command stream dispatcher in the drivers, every optimisation there should improve FPS or load times at least.

another interesting places to look is on the allocation and BOs side in the driver's DRM, track software fallbacks inside mesa, compiler side optimisations(every unnecessary ASM instruction kill a lot of bandwidth and performance due the iterative nature of graphics)

nice for the OpenAL changes