AMD Ports Open-Source Linux Driver To Windows Embedded

[bridgman]

AFAIK all the code will be available in source form, but only the files which do not include MS-supplied code/headers will be covered by the X11 license. Anything coming from open source or authored by AMD should go out in open source form as well. That's the plan anyways.

[pingufunkybeat]

I like that plan.

The way I understand it, so far the focus seems to be on a basic driver providing modesetting and simple acceleration, with work going into video acceleration and computation (Christian and Tom, IIUC). These are cool things that the Linux driver is missing, so I like that too.

Is OpenGL and 3d performance going to be a factor for this driver at all, and how much do you think that this will impact the Linux drivers?

[V!NCENT]

Windows on medical hardware is rebooted every hour or so (regulations) and ofcourse tested for a long time like any other OS. Believe me, this on Windows Embedded, is absolutely no problem. It's not as if you run Windows 98 with consumer feature-rush driver stuff. If it passes medical testing; it works. Period.

There is the AROS port of the nouveou but AROS isn't like most operating systems as its mostly stuck in the past as far as design (no protected memory etc...)

Well that's kind of a fun thing. You see AmigaOS 4.1 has that support, but disabled. The upcomming AmigaOS (2012 netbook) is, according to the kernel dev, highly likely going to feature memory protection and paging, or its update will. This is a high priority project and therefore likely to see its way into AROS.

AROS is also not AmigaOS; it's just API compatible and binary compatible on 68000 with Wine-like emulation and recompiling of older source code. That is not to say that it doesn't have the ability to have memory protection.

I realy dug into this and was highly dissapointed that they didn't took the time to also include Radeon GPU's, especialy because AmigaOne has Radeon GPU support.

[libv]

Wasn't the original plan for AMD to provide the docs and for the community to write the driver?

I wonder if taking the code written by the community, port it to windows embedded and add some proprietary sauce to it was also part of the original plan. So maybe AMD sees Linux community as a form of cheap labor?

Of course that plan didn't work out very well. For some reason there aren't many people in the Linux community lining up to contribute to the graphics stack. I wonder if the license of the graphics stack has something to do with that

The 2007 plan was quite different indeed, in countless many ways, as you all could see just a month or so ago when Michael posted our proposal to AMD.

[Laughing1]

AFAIK all the code will be available in source form, but only the files which do not include MS-supplied code/headers will be covered by the X11 license. Anything coming from open source or authored by AMD should go out in open source form as well. That's the plan anyways.

I see. So the MS headers which are required to get MS driver certification will be closed. (That is fine) Hopefully the rest of the code to get gallium running on Windows will be shown so that the open source driver will now support being compiled into Linux and Windows.

[bridgman]

I see. So the MS headers which are required to get MS driver certification will be closed. (That is fine)

I think the idea is that the MS code/headers plus any code which touches them will still be provided in source form, just under the MS source license rather than X11 (open) license. I believe you can download the ddk in source form, it's just not under an open license.

Something like that anyways... blended license stuff is even hard to explain, let alone implement

[Thatguy]

I think the idea is that the MS code/headers plus any code which touches them will still be provided in source form, just under the MS source license rather than X11 (open) license. I believe you can download the ddk in source form, it's just not under an open license.

Something like that anyways... blended license stuff is even hard to explain, let alone implement

I have a serious question if AMD is using gallium. I assume that the jit "compiling side of gallium that turns tgsl into machine code" will likely see ALLOT of work, and it needs it. Will these changes and hopefully improvements to the compiler side of the driver make there way into the gallium3d project ??

[bridgman]

I doubt that code will need to change at all, ie it won't be any different from the upstream project contents.

Our plans are still for all ongoing development to be in the upstream projects, not the ports.

Edit - Thatguy, are you talking about our use of Gallium3D in the WEC7 port (where I imagine it is being used but am not sure) or in the upstream open source drivers (where it is definitely being used but *is* the upstream project) ?

[V!NCENT]

If you look at it strictly from a money and customer demand standpoint, I think it's saner to have everything that can be upstreamed, be upstream commited

But I am not a disgusting lawyer, so how would I know?

[Thatguy]

I doubt that code will need to change at all, ie it won't be any different from the upstream project contents.

Our plans are still for all ongoing development to be in the upstream projects, not the ports.

Edit - Thatguy, are you talking about our use of Gallium3D in the WEC7 port (where I imagine it is being used but am not sure) or in the upstream open source drivers (where it is definitely being used but *is* the upstream project) ?

No I am specifically referring to the quality and speed with which the current gallium3d stack compiles code for the card "gpu" itself. Its factors slower then your closed source driver, a situation that really isn't good at all. It really begs to ask the point, why bother with a open source driver if the performance is fractional that of the closed source driver.

Will AMD invest the time, money and resources into making the gallium3d arch run worth a shit???