Radeon RADV Driver Merge Request Opened To Use ACO By Default

[pal666]

Source?

phoronix

[qarium]

it's unclear why death of llvm deserves celebration. did llvm bite you in childhood?

the point is: we only celebrate if ACO is faster and better in the end.

so you see to celebrate the death of the worst to get a better solution has nothing to do with hate for LLVM...

[smitty3268]

phoronix

Not seeing it.

[grigi]

Basically, LLVM has quickly gone from the posterchild of innovation to the posterchild of commercial toxicity.
Valve documented their attempts to get things fixed, to just get them stuck in limbo forever due to conflict in what the purpose of it is.

[nuetzel]

I think we should start with radeonsi 'sisched' regression fighting.
After 'remove AMD_DEBUG=sisched option' in March we lost

6,7 - 8,7 % of fps (@ least on Polaris 20) with UH and UV.

I've put together a handmade 'radeonsi: Revert remove AMD_DEBUG=sisched option' patch
and regain the lost fps.

setenv AMD_DEBUG sisched

Heaven

84,6 fps vs 91,2 fps => 6,6 fps = 7,2 %
92,7 fps => 8,1 fps = 8,7 %

Valley

83,3 fps vs 89,3 fps => 6,0 fps = 6,7 %
91,1 fps => 7,8 fps = 8,6 %

(with (and without) my LTO+PGO optimization)

Michael can you please 'retest'? - (I'll send you.)
mareko | @pierre-eric any ideas? (Should I send a RFC?)

[agd5f]

Basically, LLVM has quickly gone from the posterchild of innovation to the posterchild of commercial toxicity.

That is one opinion, one could also argue that LLVM has never been more popular. There are more contributors than ever and quite a few major projects are migrating to it from gcc.

[arsenm]

Valve documented their attempts to get things fixed, to just get them stuck in limbo forever due to conflict in what the purpose of it is.

This isn't remotely accurate

[arsenm]

Is amdgpu llvm backend dead now basically?

It's more actively developed than ever. Most of the work is for compute though. It would have been more helpful to have additional help working on graphics use cases rather than reinventing the wheel. If nobody's working on optimizing specific needs, it's not going to improve itself for them.

[pal666]

the point is: we only celebrate if ACO is faster and better in the end.

i understand celebration of aco success. i don't understand celebration of death of llvm. would you have fewer reasons for celebration if there were no llvm at all?

[qarium]

i understand celebration of aco success. i don't understand celebration of death of llvm. would you have fewer reasons for celebration if there were no llvm at all?

lets face it there is only LLVM because apple likes software patents and because of this they hate GNU GPLv3+
these people fooled the people for to long like the Nvidia+apple failure OpenCL...
not only because of software patents but hey my opinion is that apple is incompetent.
in my point of view only incompetent people buy apple products and apple makes a lot of money on incompetent people and because of this they also only hire incompetent people.
and because of this complete failure of incompetent people LLVM is a disease i only had bad experience with LLVM.

all the competent people of google and redhat and valve work on ACO thats the compiler of the more competent people.

and the result of all competent people google/redhat/valve work on ACO and all incompetent people like Apple work on LLVM is in the end the death of LLVM.

and there is nothing wrong in the death of incompetent people.