Superposition Shows How Far RadeonSI Gallium3D Has Evolved vs. AMDGPU-PRO

[duby229]

Wth does an application profile have to do with non-standard behaviour? App profiles are about knowing what an application does and letting the driver take a specific code path instead of a generic one. You know, the power devs have been asking in lower level APIs?

It's basically the same as applying quick sort by default, but using bubble sort when you know some specific app uses mostly sorted collections.

Because compatibility profiles are specified in 3.0 only. It was in the specs at 3.0, it was not in the specs at 4.0. Behaviour outside of specifications is non-standard. Relying on compatibility profiles and using specifications outside of OpenGL 3.0 is non-standard behaviour.

EDIT: Actually, that's not right, I misunderstood. See here. https://www.phoronix.com/forums/foru...655#post945655

[pal666]

I can never expect open source driver to preform as well as ones provided by the manufactures.

most of open source drivers are provided by the manufactures

[pal666]

again?! why AMD continues with two official drivers? Why they don't simply give up from closed one? and put more ppl working with open ones?

again?! why you continue spewing bullshit? why you don't simply listen to answers? and put more time educating yourself?

[pal666]

I was never able to make it work correctly with the driver provided.

card does not provide driver. your linux distro does, so switch distro if your is broken

[pal666]

Why doesn't AMD instead decide to take the financial and human resources it wastes on proprietary drivers and use them to assist it's customers in modernizing their codebases to actually work with correct modern drivers? It seems like that -would- actually benefit linux and AMD and foremost their customers.

why don't you enable your brain and understand that mesa does not work on windows?

[pal666]

Then where's the open source code? I'll tell you, it's in radv right now, and no thanks to AMD at all.

you are from fantasy world where mesa works on windows or amd does not have almost all customers on windows. in reality fixes from amd vulkan driver get into radv via radeonsi

[duby229]

you are from fantasy world where mesa works on windows or amd does not have almost all customers on windows. in reality fixes from amd vulkan driver get into radv via radeonsi

And that's bad how exactly?

[imirkin]

Because compatibility profiles are specified in 3.0 only. It was in the specs at 3.0, it was not in the specs at 4.0. Behaviour outside of specifications is non-standard. Relying on compatibility profiles and using specifications outside of OpenGL 3.0 is non-standard behaviour.

Not that anyone cares about facts, but that's just false.

Compatibility profiles are very much part of the spec for GL 3.1, 3.2, 3.3, 4.0, ..., 4.5. For example:

https://khronos.org/registry/OpenGL/specs/gl/glspec45.compatibility.pdf

There are some questionable and under-specified interactions between some of the legacy and "new" features [I'll leave that without further qualification as I'm not immediately familiar with the specifics], but that doesn't make the spec any less there. And no spec is ever fully complete.

[duby229]

Not that anyone cares about facts, but that's just false.

Compatibility profiles are very much part of the spec for GL 3.1, 3.2, 3.3, 4.0, ..., 4.5. For example:

https://khronos.org/registry/OpenGL/...patibility.pdf

There are some questionable and under-specified interactions between some of the legacy and "new" features [I'll leave that without further qualification as I'm not immediately familiar with the specifics], but that doesn't make the spec any less there. And no spec is ever fully complete.

Doesn't mean I'm wrong, it just means I misunderstood what I read.

Here's a quote from document.

D.1 Core and Compatibility Profiles

The

core profile

of OpenGL defines essential functionality for the modern pro-

grammable shading model introduced in OpenGL 2.0, but does not include features

marked as removed for that version of the Specification (see section D.2).

The

compatibility profile

does not remove any functionality.

It is not possible to implement both core and compatibility profiles in a single

GL context, since the core profile mandates functional restrictions not present in the

compatibility profile. Refer to the

WGL_ARB_create_context_profile

and

GLX_ARB_create_context_profile

extensions (see appendix I.3.3.66) for in-

formation on creating a context implementing a specific profile.

D.2 Deprecated and Removed Features

OpenGL 3.0 defined a set of

deprecated features

. OpenGL 3.1 removed most of the

deprecated features and moved them into the optional

GL_ARB_compatibility

extension. The OpenGL 3.2 core profile removes the same features as OpenGL

3.1, while the optional compatibility profile supports all those features.

Deprecated and removed features are summarized below in two groups: fea-

tures which are marked deprecated by the core profile, but have not yet been re-

moved, and features actually removed from the core profile of the current version

of OpenGL (no features have been removed from or deprecated in the compatibility

profile).

Functions which have been removed will generate an

INVALID_OPERATION

error if called in the core profile or in a forward-compatible context. Functions

which are partially removed (e.g. no longer accept some parameter values) will

generate the errors appropriate for any other unrecognized value of that parame-

ter when a removed parameter value is passed in the core profile or a forward-

compatible context. Functions which are deprecated but have not yet been removed

from the core profile continue to operate normally except in a forward-compatible

context, where they are also removed.

Sorry formatting sucks in the pdf.

[duby229]

So basically, It's made specifically for allowing non-standard behaviour. I thought it wasn't part of the spec, for that I was wrong. And its damn unfortunate too. Khronos did apparently make it part of the spec. Dumbasses.