ATI R600 Gallium3D Driver Continues Advancing

[droidhacker]

I think that there are two things to think about regarding bugs;

1) at a constant rate of errors per lines of code, doubling the code means doubling the bugs.
2) as the complexity increases, the rate of bugs tends to rise as well since it becomes exponentially more difficult to analyse the code in the "big picture".... especially when bad development methodologies are used, as is likely more common in closed source code.

[bridgman]

It's a pretty safe bet that proprietary driver development is using more advanced processes than open source these days. I think you'll find that the defect density ((latent + known defects) / LOC) is actually lower for closed source drivers than for open source drivers. I can't go into a lot of details but you might be surprised how far proprietary driver development has come in the last decade.

I agree with the exponential rise in complexity as the driver grows though... that is a problem for open and closed drivers. The open source stack for ATI radeon GPUs has gone from ~50 KSLOC to over 250 KSLOC in the last couple of years (not counting close to 1,000 KSLOC of common Mesa code) and there is probably still some growing to do. By way of comparison, the proprietary drivers are well over 10,000 KSLOC.

That said, the main challenges with closed source Linux drivers are more related to "big expectations vs. small market share/resources" and "large code size due to code sharing across multiple OSes" than to development process.

Open source has one big advantage over closed source development, however, which is that users can bisect regression failures. We really need to get something similar implemented in the closed source world (the problem is sanitizing out future product info, not tools/process).

I think this post added 5 or 6 to my post count... maybe 7 now.

[chrisr]

Open source has one big advantage over closed source development, however, which is that users can bisect regression failures.

With OSS, you don't get exchanges like this:
User: Hi, The fglrx driver is having trouble running on my laptop.
AMD: Did you buy a discrete graphics card from us?
User: No, it's a laptop with an integrated AMD graphics chip.
AMD: Then go talk to your laptop vendor instead. Goodbye.

[darkbasic]

Open source has one big advantage over closed source development, however, which is that users can bisect regression failures. We really need to get something similar implemented in the closed source world

This implies answering to your users. As soon as amd released the specs I bought an ati card and I started to use it with fglrx discovering some issues with libdrm v.<something>. I contacted the debian maintainer and he told me he was unable to do anything, so I contacted ati's technical support (linking the bugs reports) and I received no answer. I don't think they wanted some kind of user interaction and in fact I reported fglrx issues no more.

[nikai]

Open source has one big advantage over closed source development, however, which is that users can bisect regression failures. We really need to get something similar implemented in the closed source world (the problem is sanitizing out future product info, not tools/process).

Something like walking a customer through a bisect session with a script on a web server?

You'd probably need a server with a huge repository of binary patches corresponding to commits, and with every bisect step merge the necessary patches to a single one for download, so the customer can easily apply and test.

I guess that would be a real win for your customers.

[Qaridarium]

Open source has one big advantage over closed source development, however, which is that users can bisect regression failures. We really need to get something similar implemented in the closed source world (the problem is sanitizing out future product info, not tools/process).

i do Git Bisect for wine sometimes and this needs a lot of time with a lot of hand testing the bug very single step and you need an fast multicore pc

but yes its an powerfull tool for the customers to find the source of the 'bug'

the power of Bisect for the cloused source world ?

if the hell is frozen then the cloused source world will get an opensource tool like Bisect LOL

DEV's save a lot of time if the users found the bug by bisect and companys like AMD save a lot of money if the users find the bug by Bisect ;-)

[Qaridarium]

This implies answering to your users. As soon as amd released the specs I bought an ati card and I started to use it with fglrx discovering some issues with libdrm v.<something>. I contacted the debian maintainer and he told me he was unable to do anything, so I contacted ati's technical support (linking the bugs reports) and I received no answer. I don't think they wanted some kind of user interaction and in fact I reported fglrx issues no more.

thats it ;-)

they wana interact with the cloused beta programm users....

sign a NDA and they start to speak with you ;-)

[spirit]

last piglit test with r600g (22 september) : 824/930

http://people.freedesktop.org/~airlied/piglit/r600g/

19 august r600c : 642/711
http://people.freedesktop.org/~airlied/piglit/r600c/


R600G WIN !

[Schmaker]

What does that mean in general usage? Is it faster/more feature complete/more bugfree...?

[darkbasic]

Is it faster/more feature complete/more bugfree...?

No.

[stupid 10 characters limit]