If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

AMD Already Adds On Two Open-Source Developers

Phoronix: AMD Already Adds On Two Open-Source Developers

AMD's John Bridgman has now confirmed that they have hired two open-source developers. These two new development hires was done previous to the announcement a few days ago that they are still looking for another open-source developer to work on their open-source Linux (kernel DRM, Mesa / Gallium3D, DDX) stack for Radeon graphics hardware...

Since they are hired by AMD, does that mean they can access the intel to create a better open-source driver, or are they on their own because that kind of intel is reserved to closed-source driver devs ?

Actually, I don't think that any of the problems with the current AMD OSS driver have anything to do with the lack of information. The main problems are:

- lack of manpower, where this will help
- they are still behind when it comes to the very latest hardware, although this gap is shortening rapidly. New developers will be helpful here too
- the general state of Mesa does not allow for OpenGL3, especially the GLSL compiler is the bottleneck. Here the strategy seems to be to wait for Intel to finish this. I don't know if general Mesa development is in AMD's plans.

EDIT: All this is from an interested observer, I'm not an insider. Take it with a truck of salt.

The main impetus for hiring additional developers now was interest in the open source drivers from our embedded customers -- not just embedded Linux users (where there's an obvious fit) but customers using other OSes and using the open source drivers as a starting point for implementing support in their own environment.

Our embedded customers have a slightly different set of priorities from "desktop" users although there is a fair amount of overlap -- so the idea is that the new developers will be part of the same team but we will now be able to spend more time on embedded business priorities rather than just setting priorities based on Phoronix forum posts

The new developers will work the same way that Richard and Alex did - with direct access to hardware design info, direct access to hardware and software developers, and as-needed access to Catalyst driver source code.

You probably remember that back in 2008 we put a lot of effort into using our proprietary code as a foundation for open driver work (we tried both tcore and the hardware layer for the new OpenGL driver) but in both cases we found that the differences in size and internal architecture made this much less effective than it first appeared.

The new developers will work on kernel, x and mesa drivers / state trackers, and hopefully a bit more on the common code as well.

Well, here's to hoping that one of your "embedded customers" is willing to sink millions to help you guys work on Gallium3d-based desktop OpenGL, rather than going off somewhere in the tumbleweeds and having you work on some specific embedded technology, like Android support for AMD Fusion. That'd be cool and all, but (1) probably not open source, and (2) useless to me.

It's not like I'm a real customer anyway; I've only sunk about $2000 in graphics cards over the last 5-6 years....

Bridgman are there any customers of yours that use g3d as their graphic stack???

I don't know if any customers are using the Gallium3D paths today but I expect that some of them are and the rest will flip over pretty quickly.

Originally Posted by allquixotic

...rather than going off somewhere in the tumbleweeds and having you work on some specific embedded technology, like Android support for AMD Fusion. That'd be cool and all, but (1) probably not open source, and (2) useless to me.

There is a fair degree of overlap between embedded and desktop priorities -- I wouldn't worry. Anyways, there's very little difference between what Android needs and what a desktop user running Wayland needs - it's just the plumbing that is different. We use the same core GPU technology between Fusion and discrete parts so no split there either.