Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 30

Thread: R600 Gallium3D Patch Boosts Unigine By ~30%

  1. #11
    Join Date
    Nov 2007
    Posts
    1,353

    Default

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

  2. #12
    Join Date
    Jul 2008
    Location
    Germany
    Posts
    677

    Default

    Quote Originally Posted by duby229 View Post
    It was a valid response to a blanket statement....
    do you miss the *scnr*?

  3. #13
    Join Date
    Dec 2007
    Posts
    2,371

    Default

    Quote Originally Posted by przemoli View Post
    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.

  4. #14
    Join Date
    Oct 2011
    Location
    Rural Alberta, Canada
    Posts
    1,030

    Default

    Quote Originally Posted by Nille View Post
    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.

  5. #15
    Join Date
    Jun 2010
    Posts
    46

    Default

    Quote Originally Posted by Hamish Wilson View Post
    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.

  6. #16
    Join Date
    Jul 2008
    Location
    Germany
    Posts
    677

    Default

    Quote Originally Posted by blacknova View Post
    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.

  7. #17
    Join Date
    Aug 2012
    Posts
    245

    Default

    Quote Originally Posted by Nille View Post
    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 ..)

  8. #18
    Join Date
    Oct 2008
    Posts
    3,130

    Default

    Quote Originally Posted by Rigaldo View Post
    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.

  9. #19
    Join Date
    Aug 2012
    Posts
    245

    Default

    Quote Originally Posted by smitty3268 View Post
    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.

  10. #20
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,890

    Default

    Quote Originally Posted by Rigaldo View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •