Starcraft 2 In Wine & Select Games Could See Nice Performance Win With RadeonSI Patches

[brent]

Traditionally GPUs used a 256 MB window of VRAM mapped into address space. It made sense to keep it small on 32 bit due to lack of address space. But on 64 bit, there is more than enough address space.

I know there were some plans to map all of the VRAM on 64 bit. Is this still unimplemented?

[M@GOid]

Maybe this can be a huge gain on APUs. It would be nice to test it on Intel and AMD.

[Enverex]

They're RadeonSI Patches rather than general Mesa patches so I can't see how it would affect Intel iGPU performance.

[LeJimster]

I had been following the original bug report from the gallium-nine bug tracker the last few days. Whats interesting is the original report seems to suggest with the patches it's even faster now with nine than on native windows..

From my experience SC2 performance nose-dives when there is a lot of units on screen even on nine. I'm hoping this patch will bring the performance up above 60fps constantly.

[tuxd3v]

Maybe this can be a huge gain on APUs. It would be nice to test it on Intel and AMD.

AMD apus was what I thought too,

One thing that I noticed is that on Nvidia cards, even when you put the card on a pcie2.1, it looses performance, but the effect is not so pronounced..
Which leads me to thinking that it could be there some sort of compression or Nvidia cheats in Graphics quality..

I don know if that technique is applied on AMD, but it could help on bandwith( a zram like scheme, with low compression rate )
The downside the CPU will be more active, but , could be a solution, and in the Graphics card could be there a algorithm to compress/uncompress data, using OpenCl.

But maybe this will increase latency..

[dungeon]

One could always play with PIPE_USAGE_XYZ to get better perf, here and breaks it there while also introducing some stutter somewhere too if he don't care...

What is good managment there for cards is not necessarily also good for APUs, let alone Thunderbolt and don't forget PXes Thank God we don't serve CrossFire and else PRO solutions like SSG

Without single developer having 5 heads it is hard to find optimal solution there

[schmidtbag]

WHAT?! Are we seriously expected to accept a performance loss in glxgears!? Totally unacceptable. I'm moving to Nvidia now.
/s

On a serious note though, even though this performance improvement is just over Thunderbolt, that's still some really impressive results. I doubt it'll make that big of a difference for desktop GPUs with x16 lanes, but for everything else, I'm sure this will have a noticeable effect.
I'm really curious to see what the impact of this would be on APUs. They're starving for memory bandwidth, so I'd think those could have equally impressive results.

Also, would something like this work with OpenCL?

[Michael_S]

I'm really curious to see what this improvement is. I actually found that Github issue earlier this week and tried to build and install Marek Olšák's mesa build to try it out myself, but I borked my system and had to spend an hour fixing it. (Note to self: in the future change Grub settings so you can easily get to recovery mode before trying to upgrade system libraries. I had set my grub to no timeout and automatically boot first kernel, which isn't so smart when that boot leaves you with a blank display and not even a tty.)

I could be reading the GALLIUM_HUD outputs wrong, but when I play SC2 there does seem to be some kind of bottleneck even without Thunderbolt and an external GPU. The HUD states my CPU usage is rarely past 50% and GPU usage is at 80%. I'm using the wine_d3d9 and the Ubuntu PPA for mesa.

[geearf]

I had set my grub to no timeout and automatically boot first kernel, which isn't so smart when that boot leaves you with a blank display and not even a tty

SSH should be your friend.

[Michael_S]

SSH should be your friend.

It should be, but I must have really messed things up because the entire boot process froze. I didn't just lose my GUI, it wouldn't respond to ping or SSH either. I had to blindly restart and mash the down arrow key half a dozen times before I got to the grub menu and could boot into recovery. Then find and delete every single file installed across / by my build of mesa, apt install --reinstall all of the regular mesa libraries, and restart and all was fine.