RadeonSI Gallium3D-Nine Can Beat AMD Catalyst With Some Wine Tests

[peppercats]

AFAIK yes, but you should try it yourself.

when/if I get around to it I will, but that's nice if so.
Did you do your benchmarks with hyperz on BTW?

[jrch2k8]

You forgot to explain to people:
1) D3Dstream will work good on a fast 4core-6instruction+ CPU and when you cut 10%_CPU_hz you may lost 20%_FPS. All the rest are doomed.
2) RadeonSI does only have 60% the speed of Catalyst. The real deference is on HD6870_Vliw5 with R600, that has 100% efficiency.
3) No one tested this on IntelHD with ILO_gl2.1, that has 60% efficiency.
4) You can use Gallium_Nine with closed divers with simple assembly translation, like Gallium_IR to AMD_IL, with almost native speed.

1) is very relative since nine avoid recompilation of hlsl shaders(is passthrough as far i understand), so the CPU will not have such a high impact in the performance since nine require a very thin layer unlike wine's big translation layer.
2) mmm 60% is a bit of an understatement except for certain chips like hawaii, kabini,kaveri but ok close enough
3) ILO would be nice to test it
4) is not technically true since nine is a state tracker and depend on gallium api + TGSI, Fglrx will require to support this parts of gallium and understand TGSI since both command submission stream work differently, both kernel models allocate vram entirely different, etc, etc. you cannot simply send a bunch of random converted streams like that and expect it to work and even if it was possible it will have a severe performance penalty

[darkbasic]

Did you do your benchmarks with hyperz on BTW?

Yes of course. Without hyperz I get 46.8fps in Tropics with nine (50.9fps with hyperz).

[jrch2k8]

d3dstream(modified for DX calls tho) + nine should be the bomb

[dungeon]

2) mmm 60% is a bit of an understatement except for certain chips like hawaii, kabini,kaveri but ok close enough

You can exclude Kabini/Kaveri those fly too i have 100% performance in Xonotic when compared with Windows Catalyst , 115% performance when compared with Catalyst for Linux .

60% is somehow good current default estemate, for someone who just disable vblank and do not turn on hyperz

Only for big chips like Cayman, Tahiti and Hawaii and maybe some harvested chips, together with RS ones might be some performance issues here and there

[dungeon]

Ah my Tahiti is tested there , @darkbasic how it goes on Windows? Lets say Window 7 but without aero, i know driver there does sometimes nasty things with aero turned on

[artivision]

1) is very relative since nine avoid recompilation of hlsl shaders(is passthrough as far i understand), so the CPU will not have such a high impact in the performance since nine require a very thin layer unlike wine's big translation layer.
2) mmm 60% is a bit of an understatement except for certain chips like hawaii, kabini,kaveri but ok close enough
3) ILO would be nice to test it
4) is not technically true since nine is a state tracker and depend on gallium api + TGSI, Fglrx will require to support this parts of gallium and understand TGSI since both command submission stream work differently, both kernel models allocate vram entirely different, etc, etc. you cannot simply send a bunch of random converted streams like that and expect it to work and even if it was possible it will have a severe performance penalty

State trackers are portable libraries by definition. They have nothing to do with the low level driver, or memory management. And thats why i said translator that will cover differences between state trackers.

[darkbasic]

Ah my Tahiti is tested there , @darkbasic how it goes on Windows? Lets say Window 7 but without aero, i know driver there does sometimes nasty things with aero turned on

I'm sorry but I don't use Windows

[jrch2k8]

State trackers are portable libraries by definition. They have nothing to do with the low level driver, or memory management. And thats why i said translator that will cover differences between state trackers.

state trackers are gallium extension specific libraries that contain gallium code functionality common to all gallium drivers and gallium drivers implement the specific TGSI->GPU ir flatten implementation if needed and pipe it.

so the way gallium works fglrx will need to understand gallium api at least because a "translator" will plummet performance simply because the internal gallium structures need to be translated to fglrx internal structures (which are different enough to make your live a burning hell) because the way the hardware works(is not a CPU) you cannot just intercept some ASM from the command stream of A driver and binary translate it(as a blob) to stuff it in the command stream of B driver.

FGLRX devs will never try this feast(no real dev will), they will just implement a library(or reuse) that export the same symbols to be a drop in replacement(like libgl and company since is the same problem btw) but done entirely for their internal structures unrelated to gallium or KMS and very likely nVidia will do the same

[geearf]

Thanks to this article I dried nine today and I was pleasantly surprised.
I am *trying* to play The Secret World, and it was way too slow with wine or wine-csmt, with nine it was playable (like in wine I was one area around 4 fps, and with 9 more around 30, but with drop to 12 sometimes...).

Unfortunately, there are some visual bugs solved with csmt but not with nine, so it'd be great to have a wine-csmt-9 version.