Why is it that with Intel there is support for the latest generation graphics even before its been sent to manufacturing?
While with AMD, there is still no support even 6 months after its hit the shelves?
Why is it that with Intel there is support for the latest generation graphics even before its been sent to manufacturing?
While with AMD, there is still no support even 6 months after its hit the shelves?
Two part answer...
One part is that different HW vendors don't make big architectural changes at the same time. A better comparison might be Trinity vs Ivy Bridge, both of which had support before launch, although as I understand it the Ivy Bridge changes were probably somewhere between Trinity and SI in complexity.
Second part is that we've been catching up over the last 5 years (as a bunch of people have already mentioned) and are almost-but-not-quite caught up. SI was the first new GPU generation where we were able to get substantial work done before launch, but that still meant we were working almost a year behind Catalyst. The next generation will be the first where open source graphics driver development is able to run more or less in parallel with Catalyst development work -- agd5f already has initial kernel driver support written.
More people, no accumulated backlog to clear, and much earlier access to hardware prototypes/simulators.
With AMD, the latter two are improving, but more manpower would help. It's hard to find good programmers who would make an immediate difference, though.
I was hoping that there would be at least basic GL 2.1 + EXA support for SI by now. I wanted to buy a new card already in March, but I won't do it until the card works for everyday stuff (including basic GL and accelerated 2d).
JB,
How many OSS developers are working on the next generation architecture (9000 series for release in the 2014 timeframe)?
There's two ways to arrive at a destination earlier. Leave earlier, and go faster.
F
You mean next-next, right ? Current gen is 7000, presumably next gen is 8000 and the one after that is 9000 ?
Once we get past next-gen we'll be working in parallel with the Catalyst and diags teams. Starting earlier than them isn't really practical.
Yep, that's what we were hoping for as well. The code has been written and published for a while, but it's hard to predict how long it will take for the last few "in theory we're programming it right but in practice something is obviously wrong" gotchas, although the range of variation goes down significantly if you are debugging the code early enough to lean on emulators and HW debug teams a bit.
Last edited by bridgman; 07-24-2012 at 12:06 PM.
While I don't expect OOTB support for 9000, it is good to know that the OSS team will be starting to ramp up at the same time fglrx is starting to ramp up. Unfortunately, and this is speculation, I fear that the hardware teams are so used to working with the catalyst team's processes that there will be some growing pains for the OSS team. True parity will likely never occur. That's OK though, as long as the OSS team can produce an acceptable driver in a reasonable amount of time.
While a number of us complain that OSS isn't delivered as fast as FGLRX, what we're really trying to say is that we want an acceptable driver in a reasonable amount of time. The fact that FGLRX exists annoys us, because it reminds us constantly of what-could-have-been had AMD shared our utopian software development philosophy. Really, you just want your purchased product to work, and work now, and align with your philosophy.
I'll be looking forward to AMD's 9000 offering. I hope that they can deliver a working OSS driver in an acceptable timeframe.
F