AMDGPU DC Display Code Tacks On Another 28 Patches

[duby229]

The problem is that AMD doesn't have an infinite amount of resources. Putting resources on some task would be at the detriment of another.



Please keep in mind that, while Linux has become ubiquitous or even dominant on nearly every other platform (embed, routers, modems, IoT, smart-phones, smart-TV, clusters, fileserver, web server, NAS boxes, in-vehicle infotainment, Cloud server, etc.), desktop is one of the last few corners where Linux is still a small player.

90% of a small part of the market share is still a small total result.

In theory, it would be hard to argument in favor of Linux development, even if in practice AMD (as well as Intel) DO believe in open-source, and DO set aside resources for it (publishing docs, having developers on their payroll, etc.)

But still, more resources put toward Linux development is fewer resources put toward making sure that the Windows gaming experience is good on day one.

Of course, long-term, that's what AMDGPU and DC/DAL/"the code" hopes to achieve : shared concepts across platforms so one platform won't be anymore to the detriment of another.
But we still aren't there yet.

Still, big kudos to AMD who keeps trying even if it is still an uphill battle for them.
At least they ARE trying and putting lots of efforts ! (Nvidia, I'm looking at you...)



Even the datasheets themselves require going through legal department to validate and authorise them. Which takes time.
Again at least AMD will eventually publish theirs, unlike some of their competition.

For me "slow but eventually getting there" is still better than "not even bothering to try".
Good luck trying to run Nvidia drivers reliably on a rolling distro.

About datasheets - AMD already tried releasing enough documentation that community devs could write their own code. But it didn't end up happening. AMD ended up writing most of everything anyway. They still do release important documentation, but not to the same extent anymore.

[bridgman]

If the Linux dev community had got complete datasheets i doubt it would have taken them this long to implement the support from scratch.

This comment deserves a bit of a reality check. Working Vega driver code has been in public for what, six months now ? AMD developers are online pretty much 24/7 to answer questions. Existing upstream display code has been public since pretty much forever.

If the community was going to do something (I assume you are talking about adding Vega support to the existing upstream code rather than implementing something that our HW diags team would be willing & able to maintain) it would have happened already.

Do you really think a thousand pages of hardware documentation would have sped things up ?

[trek]

19 months and still no open source vulkan driver....

are you talking about the nvidia driver?

[OneBitUser]

Seriously, if you don't like that there's always RADV and if you're not satisfied with the current state of it maybe you should roll up your sleeves and fix it yourself? It is an open source project after all...

I think you misunderstood me: I was not complaining!
AMD's efforts sit perfectly fine with me, I support them wholeheartedly, even though I'm not on the level to help out in driver development.
To be honest, it also does not affect me right now, since I (reluctantly) became an NVidia user about two months ago.
Hopefully the mining craze will pass by the time I'm going to be in the market for a new graphics card, so I can buy an AMD card at sane prices.

[geearf]

RADV is slower then OpenGL in all the tests I have seen.

Well you haven't seen all tests then

[varikonniemi]

This comment deserves a bit of a reality check. Working Vega driver code has been in public for what, six months now ? AMD developers are online pretty much 24/7 to answer questions. Existing upstream display code has been public since pretty much forever.

If the community was going to do something (I assume you are talking about adding Vega support to the existing upstream code rather than implementing something that our HW diags team would be willing & able to maintain) it would have happened already.

Do you really think a thousand pages of hardware documentation would have sped things up ?

I am saying that in the case of complete, proper documentation being available, it is not that hard to implement it. Apparently such a thing does not exist, since even the AMD engineers tasked to do the work are often not really sure how to do something and resort to trial and error (this impression is from some of their posts online that i have seen, and commit messages).

[L_A_G]

I think you misunderstood me: I was not complaining!

Well that's what it came off as and it doesn't even work as a random remark as it's just stating something that's well know. It's like pointing out that GNU Hurd still isn't done in the comments to some random article about GCC.

[duby229]

I am saying that in the case of complete, proper documentation being available, it is not that hard to implement it. Apparently such a thing does not exist, since even the AMD engineers tasked to do the work are often not really sure how to do something and resort to trial and error (this impression is from some of their posts online that i have seen, and commit messages).

That's sort of understandable in the sense that these devs are not the ones that designed the actual hardware. Trial and error in many cases is a good problem solving technique. But I do agree with you in the sense that available information can make trial and error redundant.

[JordanL]

How is it possible AMD does not allocate enough resources to have proper release day open source support for the Vega, when all other aspects were decent.

Small nitpick, but there was "open source" Vega support at launch. What you mean is likely "upstream" support, which is a matter of aligning schedules (generally difficult to do) and the outstanding work to become upstreamed.

[bridgman]

I am saying that in the case of complete, proper documentation being available, it is not that hard to implement it. Apparently such a thing does not exist, since even the AMD engineers tasked to do the work are often not really sure how to do something and resort to trial and error (this impression is from some of their posts online that i have seen, and commit messages).

The problem is not lack of documentation, the problem is that the complexity of modern display hardware results in too *much* documentation. There are literally thousands of pages of documentation that would have to be distilled down to some kind of mega-programming-guide, and that would be every bit as much work as writing the driver. The same is true for a number of other blocks as well.

Remember that the goal of this initiative is to implement a framework which allows the HW and diags people to contribute directly to the upstream driver, rather than having them write validation code in one format and then have SW teams re-implement for production drivers.