Nouveau NVC0 & RadeonSI Now Officially Expose OpenGL 4.3

[soulsource]

What exactly is meant by "putting Unreal 4 into bad shape"? Are there rendering bugs, performance regressions, or even crashes?

Radeon need llvm 3.9? why? this non sense need to stop, why mesa devs are using unstable branch of llvm?

Maybe you missed it, but the shader compiler for RadeonSI is part of the LLVM project, not of mesa. For users this sadly means that if they want to stick to stable releases, they have to wait until both, mesa and llvm, to release new versions in order to get new driver functionality that requires changes in the shader compiler.

[valeriodean]

The issue related to the LLVM release is a point in favor of NIR (developed by Intel devs mostly, plus rob and eric, I guess): they can release new versione of mesa, with new bug fix, features and optimizations togheter with an upgraded version of NIR that can enable those new things immediately, without hold on other's project release schedule. Would LLVM consider to switch to a 3 month release cadence instead? It could mitigate the issue.

[log0]

What exactly is meant by "putting Unreal 4 into bad shape"? Are there rendering bugs, performance regressions, or even crashes?

Probably this https://bugs.freedesktop.org/show_bug.cgi?id=95005

[bridgman]

The issue related to the LLVM release is a point in favor of NIR (developed by Intel devs mostly, plus rob and eric, I guess): they can release new versione of mesa, with new bug fix, features and optimizations togheter with an upgraded version of NIR that can enable those new things immediately, without hold on other's project release schedule. Would LLVM consider to switch to a 3 month release cadence instead? It could mitigate the issue.

That's not really a NIR-vs-LLVM thing, more a question of whether a separate copy of LLVM should be maintained in the Mesa tree. IIRC that's how it was done initially, but once the GPU code was upstreamed it became cleaner to pull code directly from the LLVM trees instead.

[haagch]

With SI and linux 3.6 compute shaders are disabled.

This is the commit to enable compute shaders on SI: https://cgit.freedesktop.org/~agd5f/...143b511383fc6b

(You possibly also want https://cgit.freedesktop.org/~agd5f/...aa16b19ceaa6c7)

This has not been backported to linux 3.6, but you can simply apply those two patches to linux 3.6, there are no conflicts and compute shaders work fine with it.

[bridgman]

With SI and linux 3.6 compute shaders are disabled.

This is the commit to enable compute shaders on SI: https://cgit.freedesktop.org/~agd5f/...143b511383fc6b

(You possibly also want https://cgit.freedesktop.org/~agd5f/...aa16b19ceaa6c7)

This has not been backported to linux 3.6, but you can simply apply those two patches to linux 3.6, there are no conflicts and compute shaders work fine with it.

Guessing you meant 4.6 ?

[haagch]

Indeed I did

[zanny]

Isn't developement usually happening in non-stable branches anyway?
Or do you want stable branches/builds to not be stable anymore?

Honestly, having been on kernel / Mesa / KDE / many other gits for years, I think in practice complicated branch / beta / release products are a waste of time. When something breaks in mesa-git nowadays, it is patched immediately the next day, at worst. I cannot imagine why you would not just branch when new important features land (and in most projects just by merging the patches you know they work, because they were heavily audited prior to merging) give a ~week grace period for all the trunk-users to catch regressions and fix them, and then push the new version.

Practically all commercial software is released on that kind of cadence, rather than a semi-annual release cycle. Because it just makes sense to release new versions when new features are finalized. If your project is tiny and has low participation or isn't as rigorous in its patch acceptance policy, sure, do complex betas to mitigate the shortage of eyes or the lack of discipline. But anything of scale like Mesa, the kernel, or LLVM have little need in practice to do so.

The alternative is just to speed up all the annoying parts of timed releases, which is something thankfully LLVM is considering doing. If you are a big heterogeneous project that is ill equipped to judge what major features are to justify a release, you could just do monthly releases where the last week of the month is a branch window to clean out regressions.

[M@GOid]

This morning, padoka PPA update give me OpenGL4.3 without use of any EV.

Some quick tests:

- Unreal Elemental OpenGL4 demo play, but some scenes the lava is black, not orange;

- Shadow of Mordor can play with everything at maximum, but there is some artifacts. It is playable at lower settings;

- Tomb Rider can play at ultra settings, but there is artifacts. But the TressFX thing is working. In fact, is working so well that setting is stuck in "On", you cannot have the simpler hair mode back, for now :-) Looks like there is no performance gains because OpenGL4.3, though;

- Alien: Isolation is playing the nicest among these examples, no artifacts and the performance with everything at the top is reasonable.

- SNOW is a Cryengine free game, but it still cannot launch.

These are the most graphically (OpenGL wise) advanced games I have access now. Using a R9 290 GPU and a i7 3770K CPU.

[pal666]

Is everyone with radeonsi now getting OpenGL 4.3? Only getting 4.2 at the moment.

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN (DRM 2.43.0 / 4.6.0-meow, LLVM 3.9.0)

si bug was fixed in driver drm 2.45.0, you need kernel 4.7
recipe for fedora users: https://copr.fedorainfracloud.org/coprs/dionney/mesa/ + kernel from rawhide