81 Fresh Patches For AMDGPU's DC (DAL) Display Code

[agd5f]

Can you let us know what that entails or is the list still too long to go over in detail?

You can read the threads from the previous code reviews. Mainly de-midlayering things and cleaning up the interactions with the atomic code. It may seem to go slowly to the outside observer since we are busy adding support for new asics (e.g., vega10 and Raven) and fixing bugs on top of reworking the code to get it upstream and other reviewers in the community are busy with other things. It's a huge amount of code to review so we don't want to waste other people's time until we feel we made enough progress. That said, we send the display patches to the mailing list just like everything else so people can review the patches and watch the program if they are inclined.

[pal666]

Torvalds does not like HALs, and has told maintainers to not accept them.

actually torvalds said he could accept it. so just say no to drugs

[pal666]

I haven't seen any continued tirades from maintainers, so looks like they just keep saying "nope".

looks like you have vivid imagination

[gnarlin]

We are trying to get everyone to stop calling it DC (since that is the name of the abstraction layer) or DAL (since that stands for Display Abstraction Layer) since neither of those make sense when we are de-mid-layering the display code. Let's just call it display code, OK ?

(the use of DC/DAL came from a desire to distinguish between this display code and the more limited display code already upstream, but probably not worth the confusion)

Too late

[smitty3268]

You can read the threads from the previous code reviews.

You mean the stuff from 8 months ago, or are there more recent code reviews I'm not aware of? I was hoping maybe some of that original review wasn't relevant anymore and had been cleaned up since then.

[jrdls]

Hi Alex, if I recall correctly, you were asking the maintainers to merge the code with the midlayer because, among other things, it would make it easier for you guys to test and debug the code and therefore you wouldn't have to duplicate your efforts. Have you guys come up with a way to do this with your windows and your linux code in way that doesn't duplicate your efforts and without requiring a midlayer?

[Hi-Angel]

Hi Alex, if I recall correctly, you were asking the maintainers to merge the code with the midlayer because, among other things, it would make it easier for you guys to test and debug the code and therefore you wouldn't have to duplicate your efforts. Have you guys come up with a way to do this with your windows and your linux code in way that doesn't duplicate your efforts and without requiring a midlayer?

Judging by "at least for Linux" from the comment

The "DC" name was partially an attempt to bridge over the DCE/DCN transition but unfortunately it was also the name of the abstraction layer we need to largely eliminate (at least for Linux).

, I'd guess the code gonna talk directly to kernel on GNU/Linux, and to a mid-layer on Windows. Which sounds justified — so they take the side that cares about the code, and they can use Linux as a main development platform because this is where contributors will be coming from.

[Inopia]

Judging by "at least for Linux" from the comment , I'd guess the code gonna talk directly to kernel on Linux, and to a mid-layer on Windows.

Kernel maintainers don't like HALs and Windows doestn't really care so just make a mid layer which looks like Linux to use on Windows and everyone's golden

[agd5f]

Hi Alex, if I recall correctly, you were asking the maintainers to merge the code with the midlayer because, among other things, it would make it easier for you guys to test and debug the code and therefore you wouldn't have to duplicate your efforts. Have you guys come up with a way to do this with your windows and your linux code in way that doesn't duplicate your efforts and without requiring a midlayer?

We never asked anyone to merge any code. We sent out several RFCs, some of which resulted in some rather heated discussions. The point that I and others were trying to make is that we want to keep the core programming sequences in dc as common as possible since those are used for both pre and post silicon validation as well as for mode setting in the driver.

[agd5f]

You mean the stuff from 8 months ago, or are there more recent code reviews I'm not aware of? I was hoping maybe some of that original review wasn't relevant anymore and had been cleaned up since then.

There were several later discussions via email and IRC. Additionally, the ongoing development display patches are sent to the mailing lists just like any other driver patches. If you are curious about that changes we are making, take a look at the patches or compare the display code in older and newer amd-staging branches.