Early Radeon DRM-Next Tests Ahead Of Linux 4.7, Mesa 11.3: Many Improvements, One Card Falls

[theriddick]

Whatever, so I'm wrong. I just thought the PRO driver was a plugin that ran on top of the standard mesa amdgpu stuff, guess I'm wrong.

I really haven't had a chance to use the preview pro driver anyway so hopefully when the NEW one comes out it will work on newest kernel versions and show some different performance then the radeon/amdgpu oss driver stacks. Again I game at 4k, (or at least try too), so I generally look at gains around that resolution.
(it should be mentioned my 980GTX I had a while back did 4k@60fps fine!)

[Azrael5]

theriddick, I replied but my post disappeared when I hit "Post Reply"... I'll wait a bit and see if it re-appears.



The OpenGL application (the KDE compositor is just another OpenGL application) can request either a core profile or a compatibility profile. OpenGL implementations (drivers) must support core profiles but support for compatibility profiles is optional. If an app requires a compatibility context then the highest GL version it will be able to get is 3.0, while if it can use a core context then it can get 3.3. Any app written to run on the open source drivers will normally only request a core profile. Not 100% sure if that is the case for KDE but I imagine it is.

many thanks. Of course my system uses mesa drivers so I assume it should implement the core profile. Anyway, if the core profile won' work because of compatibility mode prevails for any reason in one or more apps, will be used 2.1 opengl acceleration or the acceleration will be disabled for that specific case? How to know if acceleration works or not works and which opengl features are operating for a specific app?

[bridgman]

You pointing out something highly speculative as a fact... In my point of view the customers will not do this.

No more speculative than anticipating what would happen if I walked out onto a busy highway. In both cases it's a function of momentum and reaction time.

What AMD really should do is drop compatibility profiles and instead of this they should offer help to the customers to fix the code of the problematic software.

Yes, but not in that order.

In my point of view it is better for everyone if a problem is fixed at the point location were the problem has its root. And not some driver side hack to fix the application problem on driver side.

Yep, agree completely. It's a big hole though, and we're not the only ones digging.

[GreatEmerald]

So your game does not even uses shaders at all? And so it is unable to compute custom effects on GPU side? Sorry to inform you, but that's pretty much outdated, even for opensource gaming. Ever seen, say, water computed by shaders, dammit? I wonder how the hell one could do it without shaders. All fixed-function games I've seen just drawn some half-transparent mud and pretended it is water. Which is lame :P.

It's a 2D card game

[theriddick]

You're kidding, right ? You want us to go from doing development in the open (where code is pushed into development trees months before the kernel release) to keeping it internal and not putting it into the upstream development flow (where testing & fixing happens) until it has been fully QA'ed and fixed ?

The fact that Michael finds problems with code at this point just means that he is acting as a valuable part of the development community, not that bad code is going into *released* kernel & userspace drivers.

Don't mean that at all, just saying you guys should include 290 and 390 cards in your tests between kernels/drivers whatever instead of waiting for the community to post benchmark results showing that performance is decreasing on these specific high end cards that should have more optimization focus then what their getting!

Otherwise its going to take years to AMD to catch up to NVIDIA in terms of the 'average' OpenGL performance (I said average as we know AMD cards perform quite well with certain games/tests).

[theriddick]

This forum enjoys eating my replies.. sigh

[bridgman]

I used to type them in again from memory but now I just wait a while and usually they show up eventually. No idea where they are in the meantime, there's no indication of them being moderated.

Maybe the hosting site has a slow network cable somewhere

[Oxalin]

One of the things that is not exposed by these tests is the fact that the radeon kernel driver should now be wired up to handle the last remaining prerequisit to enable compute shader 4.3 and OpenGL 4.3: by displaying DRM version 2.45 for SI chip class (as requested in Mesa's commit 464cef5b06e65aa740704e4adac68b7f5fee1b88). Mesa checks if the kernel allows register writes on GPUs prior to CIK that were still disabled up until recently (available under kernel 4.7 wip but not under 4.6). With that in place and the last proposed patches to fix the Unreal engine compute shader bug with Mesa, we should see OpenGL 4.3 enabled very soon.

The DRM version is displayed in the boot log or through glxinfo.

[SystemCrasher]

- use of a "kernel compatibility layer" (not allowed upstream) which encapsulates backporting effort to specific older kernels

Ahh, these slowly moving dinosaurs of corporate world... okay, I've got the idea. Though I'm not really sure why they're so eager to update fairly critical user-mode parts, where failure could easily leave 'em in the dark, without picture on screen or causing nasty GPU crashes, while disregarding kernel upgrades, which are hardly more harmful, but it is up to them.

- support for additional IOCTLs or other functionality in the kernel driver, either not allowed upstream or on its way but not upstream yet

Hmm, wouldn't it be more logical to bolt 'em to MESA, etc. I guess AMD does not adds IOCTLs just for lulz, eh?

The "relatively old kernel" aspect is a problem but the "change slowly" aspect helps

To my taste it usually ends in awful mess, only few programs/drivers bother self to handle such a great burden, and overall distro turns into horrible mutant monster full of outdated software. I understand breakages are bad, but sometimes software necromancy is even worse :P. But if AMD and some customers needs it I can understand it, sure. Hopefully you have idea on how NOT to get these failed *buntu upgrades which were plaguing Catalyst and nvidia blob for many years. This basically means user-mode driver (even Pro) should be able to take off with "stock" amdgpu in new kernel, right?

[SystemCrasher]

It's a 2D card game

Then I do not really get why you need OpenGL at all. It appears pretty much like use case for SDL & somesuch.