The Issues With The Linux Kernel DRM, Continued

[squirrl]

Ok

So how does AMD's Windows division write their drivers?

Are there test plan's, deliverable documents that have to be written explaining timings, mode setting and caveats? Do developers have deadlines and code freezes?

Does Microsoft allow you to change their APIs?

[allquixotic]

So how does AMD's Windows division write their drivers?

Are there test plan's, deliverable documents that have to be written explaining timings, mode setting and caveats?

From what I understand, yes. The hardware team creates two sets of documents: the internal-only documents that contain full disclosure, including all the info about the parts they will never reveal in open documentation (e.g. UVD); and, later on, a set of sanitized documents for the general public and their open source developers to use to write their drivers.

Do developers have deadlines and code freezes?

Yes, because they are responsible for delivering a product targeted at end-users of a commercial product (i.e. Windows).

Does Microsoft allow you to change their APIs?

No, because they actually have an API (e.g. WDDM 1.1 in the kernel and Direct3d in userspace) that is sufficiently expressive to allow most modern graphics hardware to at least be shoehorned into this mold. Aside from that, consider these other factors:

*While WDDM is being developed, many many ATI, Intel and Nvidia engineers are constantly involved in meetings with Microsoft to work out what APIs will be acceptable for them. Microsoft didn't just go and develop it in a vacuum; it's a custom-fit API to work with the hardware that the companies are building. These meetings and associated engineering work involved manpower on a scale that makes FOSS graphics engineering look picayune by comparison.
*WDDM is a finished product now. Developing a new driver or maintaining an existing driver to add new features/ASICs is much, much easier when you have a graphics driver infrastructure that is proven to work well with previous generation hardware.
*Because WDDM is so prevalent, it gets special treatment at a very low level: hardware designers intentionally build hardware that they think might work well with the operating principles of WDDM, and vice versa. The sheer popularity of WDDM (via the popularity of Windows) is an impetus for ensuring that the API and the hardware will match up well -- a convenience we lack in the free world.
*All the patent deals needed are licensed way ahead of time, so the engineers don't have to have any heartburn about dodging patents left and right in the specs they're implementing.

Just because something works well in one set of circumstances doesn't mean it can work well in another set of completely different circumstances.

[bridgman]

From what I understand, yes. The hardware team creates two sets of documents: the internal-only documents that contain full disclosure, including all the info about the parts they will never reveal in open documentation (e.g. UVD); and, later on, a set of sanitized documents for the general public and their open source developers to use to write their drivers.

One minor tweak - the hardware team creates documentation about how the hardware is implemented (which gives some information on how to program it) and writes diagnostic programs - proprietary driver/VBIOS software teams work with hardware teams to create and document the software design, then open source team (primarily agd5f) creates sanitized programming info based on internal HW doc + diags + info from VBIOS & driver teams.

We have tried a few different approaches for getting the *right* information into developer's hands and have concluded that getting basic driver code working before writing docs is the most effective way - otherwise we spend a lot of time writing & reviewing docs only to find that the information was wrong.

[bridgman]

Stinkin' edit limit...

Now that development is mostly "caught up" with new hardware development (at least we're starting less than a year after the proprietary driver team now) we're trying to piggyback open source design & planning onto the proprietary driver work. We won't be able to do this fully for the next generation of parts but hope to be in sync after that.

[curaga]

Stinkin' edit limit...

Now that development is mostly "caught up" with new hardware development (at least we're starting less than a year after the proprietary driver team now) we're trying to piggyback open source design & planning onto the proprietary driver work. We won't be able to do this fully for the next generation of parts but hope to be in sync after that.

Please cite for the interwebs, which next generation are we talking about?

[bridgman]

Please cite for the interwebs, which next generation are we talking about?

The "next generation" is the one we aren't talking about yet, other than acknowledging that we are in fact continuing to design new GPUs

We were not able to start at the same time as the proprietary driver folks for that generation but at least they are still working on it. The generation *after* that is the first where we are able to design & plan the open source support at the same time as the proprietary driver support.

[marek]

http://phoronix.com/forums/showthread.php?39380-Some-Distributions-Still-Live-In-A-KMS-Less-World&p=187364&highlight=#post187364

[curaga]

The "next generation" is the one we aren't talking about yet, other than acknowledging that we are in fact continuing to design new GPUs

We were not able to start at the same time as the proprietary driver folks for that generation but at least they are still working on it. The generation *after* that is the first where we are able to design & plan the open source support at the same time as the proprietary driver support.

No, no no, in abstract terms at least. I'm unsure whether you're talking about hd7xxx, hd8xxx or hd9xxx, or even something else.

[squirrl]

Thanks

Thanks for all the information guys.

[bridgman]

No, no no, in abstract terms at least. I'm unsure whether you're talking about hd7xxx, hd8xxx or hd9xxx, or even something else.

Marketing names get picked pretty late in the game, but if the same pattern holds then we're starting to look at what you would call hd7xxx but that's still almost a year behind the earliest proprietary driver design work.

What you call hd8xxx is the first generation where we can start open source driver design efforts more or less in sync with hd8xxx.

They could end up being called something completely different from hd7xxx and hd8xxx, of course.