R600 Gallium3D Patch Boosts Unigine By ~30%

[duby229]

It was a valid response to a blanket statement....

[Nille]

It was a valid response to a blanket statement....

do you miss the *scnr*?

[agd5f]

Well, AMD could host farm of GPU's of various generations/configs. With some automated tools that would allow previlaged devs to submit patches to test performance/piglit regresions.

QA would also had easier time (if dev's could detect bad code earlier).


Great idea, so why its not already done?

What automated tools would you suggest? There weren't any piglit tests which triggered the issue. Unfortunately, automated testing is often a challenge for GPU development. For best results you generally need physical access to the hardware.

[Hamish Wilson]

Or Stop developing the Driver in the Kernel Tree. For an user its much more easy to update an out of tree kernel module. To tell an user he has to recompile his kernel is is a mess.

And for developers it is much more of a mess to maintain an out of kernel module, which will also result in much less out of the box support from the driver, which is much of the point of R600g. If you want a module that is released outside of the kernel use one of the proprietary binary blobs like Catalyst - and then see how well that works out.

[blacknova]

And for developers it is much more of a mess to maintain an out of kernel module, which will also result in much less out of the box support from the driver, which is much of the point of R600g. If you want a module that is released outside of the kernel use one of the proprietary binary blobs like Catalyst - and then see how well that works out.

And the main reason for that mess is that Linux kernel don't provide stable kernel ABI and API. If kernel interfaces are stable you can develop drivers with just kernel headers available.

[Nille]

And the main reason for that mess is that Linux kernel don't provide stable kernel ABI and API. If kernel interfaces are stable you can develop drivers with just kernel headers available.

In the past this was not an problem and i see the reason why this is now an problem.

[Rigaldo]

In the past this was not an problem and i see the reason why this is now an problem.

Actually it was and still is, in the sense the kernel devs who change the interfaces and cause "breakage" are also supposed to change "broken" drivers. Of course it wouldn't matter as much if the kernel had a different model with fewer, but bigger releases.

************************************************** *

I have to agree with posts above, and I find that being able to update drivers separately from the kernel(not having to update the whole of it for one driver) would be cool. Besides, being out of tree and being closed-source/proprietary have nothing to do with each other.
(AFAIK there are out of tree open/free driver as well as in tree closed drivers anyway ..)

[smitty3268]

I have to agree with posts above, and I find that being able to update drivers separately from the kernel(not having to update the whole of it for one driver) would be cool. Besides, being out of tree and being closed-source/proprietary have nothing to do with each other.
(AFAIK there are out of tree open/free driver as well as in tree closed drivers anyway ..)

It would definitely be nice, yes. But you are just shifting more of a burden onto the developers to get that to work and maintaining it all, which seems like a poor decision to make when the existing developers are already so shorthanded and still trying to catch up with current hardware features.

[Rigaldo]

It would definitely be nice, yes. But you are just shifting more of a burden onto the developers to get that to work and maintaining it all, which seems like a poor decision to make when the existing developers are already so shorthanded and still trying to catch up with current hardware features.

It shouldn't be much of an issue if the in-kernel interfaces were backwards compatible. But this won't happen soon I guess ... As needs arise(and hopefully more resources too), things should improve on these sectors too. But sorry, I'm getting a bit of topic now.

[Ericg]

It shouldn't be much of an issue if the in-kernel interfaces were backwards compatible. But this won't happen soon I guess ... As needs arise(and hopefully more resources too), things should improve on these sectors too. But sorry, I'm getting a bit of topic now.

Things are allowed to break internally because the people who are affected also have the skills to fix anything that. THings are also cut from the kernel if they aren't maintained. Its not like that externally (userspace facing) because not every userspace dev is a kernel dev and projects come and go. They want to make sure that the kernel isnt the reason why a userspace application stops working some time down the line.

As far as "fewer, bigger releases" ....No. Just no. The kernel moves quickly, deal with it. Development happens very fast, and id rather not have to constantly recompile from git master if I wanted a specific feature when git isnt guaranteed to be stable. Much better to wait the like 2 months for a new release (personally id prefer monthly releases but thats just me) and have relatively assured stability thanks to the rc's.