The First DRM Pull Request For Linux 2.6.35 Kernel

[marek]

The absence of anything relating to Nouveau isn't necessarily a bad thing - it may indicate that the devs are happy with the kernel layer for the moment, and spending all their time on the userspace code. That's the important part, after all - now that modesetting works pretty well, the biggest issues are things like OpenGL, or accelerated video, all userspace...

I haven't seen a nouveau commit in Mesa for a long time.

[marek]

I thought a while I'd managed to figure some of this stuff out myself and chip in but I'm suffering from way too many C++isms and using a good toolkit on top of that. Going to the metal of GPU programming in C was hard.

C++ism is actually an advantage, Gallium is object-oriented and even though it's in C, you'll see the pattern there. The only think we miss is C++ templates, besides that we have everything we need.

[cg512]

A strength of Windows is that it has full featured graphics drivers at launch of graphics card x. In the OSS graphics drivers department this is where Linux is still lacking. I'd personally rather see Linux play catch-up there at the cost of supporting museum-pieces forever.

The bleeding edge are the minority. Its stretching facts a bit to call AGP 'museum piece'. I for one am tired of the fadish nature of the video card scene. Constantly being told to throw away expensive hardware because the latest game needs yet another new latest ultra mega cool version video card gets old real quick..

[monraaf]

The bleeding edge are the minority. Its stretching facts a bit to call AGP 'museum piece'. I for one am tired of the fadish nature of the video card scene. Constantly being told to throw away expensive hardware because the latest game needs yet another new latest ultra mega cool version video card gets old real quick..

The 'bleeding edge' is where AMD makes it's money. I don't think that people who are still using 10 year old r100/r200 cards are very profitable customers for AMD. So to me it doesn't make sense to invest any AMD time or money in supporting these cards. Closed or open source.

As for AGP. It's an aging technology and I think developers have stated it numerous times that it's a pain in the ass to support. IIRC this is mostly because other factors such as the chipset that are a large factor contributing to the (in)stability of AGP cards.

[cg512]

The 'bleeding edge' is where AMD makes it's money. I don't think that people who are still using 10 year old r100/r200 cards are very profitable customers for AMD. So to me it doesn't make sense to invest any AMD time or money in supporting these cards. Closed or open source.

As for AGP. It's an aging technology and I think developers have stated it numerous times that it's a pain in the ass to support. IIRC this is mostly because other factors such as the chipset that are a large factor contributing to the (in)stability of AGP cards.

I don't agree.

Part of the COST to you of purchasing your l33t new video adapter card is not just the engineering devoted to create it, but the implicit expectation engineering will be devoted to SUPPORTING it.

Companies that develop a reputation for abandoning their past customers lose future customers. I applaud AMD for having the good sense to sensibly apportion support resources to their existing customers.

You're obviously not a business person, the notion of 'good will' & reputation is obviously completely lost on you. Gamers are not AMD's only market. They supply huge quantities of chips to OEM's. These companies have an expectation that THEIR customers will remain happy & not come back to haunt them if AMD does not take care to support their chips with drivers.

I have no tolerance for people who buy (expensive) hardware in the full knowledge that it does not have essential software (drivers) to enable it's use in a particular OS setting.

[allquixotic]

A strength of Windows is that it has full featured graphics drivers at launch of graphics card x. In the OSS graphics drivers department this is where Linux is still lacking. I'd personally rather see Linux play catch-up there at the cost of supporting museum-pieces forever.

I'm not sure that sacrificing the one would bolster the success of the other. Combine the seminal wisdom of the Mythical Man Month, with the fact that there is a significant chance of driver developers being less familiar with one type of technology than another. For example, some developers who know AGP hardware really well (maybe airlied) are working on that because they have the knowledge. Senior developers who are privy to all the NDAs and the latest docs (provided that those docs are useful) are probably equally capable of hacking on r800 or r300, but junior developers -- of which there are many -- may not have access to the docs they need; or they may be running up against a learning curve as they begin work with new hardware, or new architectures such as Gallium3D.

Also, a lot of the hold-up for r800 with the open source drivers in particular is the legal team at AMD. They have to carefully screen documentation for anything that might be used by Nvidia to let them extract new technical knowledge they don't currently possess. These two companies are constantly at one another's throats about this kind of thing, hiding their internal R&D technology from the other. With the demolishment of Nvidia's official open source strategy, they are much less at risk now of exposing their IP, while AMD is still trying to stick its neck out there.

The funny thing is, the legal team is still a bottleneck even if all the code we need is written! AMD's internal developers (who get paid to work on the open source graphics stack) definitely have access to all the AMD documentation they need to write a driver, but they can't release that code as open source until they clear it with legal. Protecting their patents and other such nonsense.

So yeah, the issues with slow development of the r800 OSS driver (and, in general, the development of open source graphics drivers for the latest chipsets) is impeded by the quagmire of our legal system, as much as (if not more than) the lack of manpower. I can't blame AMD for protecting their "IP" any more than I blame Red Hat for taking out defensive software patents, though: both companies reluctantly play by the rules of the legal system, as a means of survival. If they were to ignore the patent landscape entirely and just give us the code/docs as they are, it would be like dismantling your entire nuclear weapon arsenal during the most tense period of the Cold War. Suicide.

[IsawSparks]

Sure. And you are free to add support for it. But when AMD employees spend a disproportionate amount of time on AGP and other legacy support I find this quite problematic. An hour spent on legacy support is an hour not spent on support for more recent hardware. And this is precisely an area where AMD is lacking.

Define disproportionate. There are whole departments worldwide who've not upgraded from PCI, let alone AGP, not to mention all of the notebooks around which are AGP. You can't ignore something which has been backburnered forever.

[cl333r]

Supporting obsolete stuff (10+ years) is for those who have extra work force and don't know where to apply it.
As a customer, even if I bought a cool OpenGL 4.0 capable video card I wouldn't expect AMD to provide support for it until like 2025, I'd upgrade anyway in like 3 to 5 years, or 7 years at most.

[bridgman]

Isn't this all hypothetical anyways ? The AMD developers haven't spent much time working on AGP anways.

I suspect the issue here is lack of clarity between working on GPUs which happen to be available on AGP cards (the transition to KMS covered the range from r100 through r7xx) and working on AGP itself (mostly helping end users understand how to slow down the AGP bus and turn off AGP-sensitive optimizations in order to get their systems running).

If you're saying that our developers should not have helped with the transition to KMS and GEM/TTM that's a fair argument but I guess we disagree on that.

[bridgman]

Supporting obsolete stuff (10+ years) is for those who have extra work force and don't know where to apply it.

What about 10 year old parts that are still being actively designed into new servers ? The rv100 derivatives (eg ES1000) are still active in the embedded market and we do support them for that reason.