Page 3 of 3 FirstFirst 123
Results 21 to 30 of 30

Thread: R600 Gallium3D Patch Boosts Unigine By ~30%

  1. #21
    Join Date
    Jun 2010
    Posts
    46

    Default

    Quote Originally Posted by Ericg View Post
    Things are allowed to break internally because the people who are affected also have the skills to fix anything that.
    If instead of fixing kernel breaks people with skill would spend the same time working on actual drivers, the drivers in question would be much better.

  2. #22
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,935

    Default

    Quote Originally Posted by blacknova View Post
    If instead of fixing kernel breaks people with skill would spend the same time working on actual drivers, the drivers in question would be much better.
    You dont get the driver right the first time. Like the major nouveau rewrite that happened 2 releases ago. To write good quality drivers someimes you have to stop and go "....We fucked this up." Scrap some work and start over. Which breaks things in the process.

  3. #23
    Join Date
    Jun 2010
    Posts
    46

    Default

    Quote Originally Posted by Ericg View Post
    You dont get the driver right the first time. Like the major nouveau rewrite that happened 2 releases ago. To write good quality drivers someimes you have to stop and go "....We fucked this up." Scrap some work and start over. Which breaks things in the process.
    And how complete driver rewrite correlate to stable kernel interfaces? Driver seriously is independent piece of software which strongly relying on some services provided by kernel, e.g. pci bus support, memory management, etc.
    Are you saying that driver rewrite would become any simpler just because kernel interfaces have been changed and now developers need to figure out the new way, to do something that have been already working. Yeah, right.

  4. #24
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,935

    Default

    Quote Originally Posted by blacknova View Post
    And how complete driver rewrite correlate to stable kernel interfaces? Driver seriously is independent piece of software which strongly relying on some services provided by kernel, e.g. pci bus support, memory management, etc.
    Are you saying that driver rewrite would become any simpler just because kernel interfaces have been changed and now developers need to figure out the new way, to do something that have been already working. Yeah, right.
    When the driver changes sometimes their interfaces change. It happens. And I'm not relating to simplicity of anything. You said they should stop changing the interfaces and just worry about writing a better driver. I just pointed out that sometimes TO write a better driver you have to change some interfaces.

  5. #25
    Join Date
    Jan 2009
    Posts
    466

    Default

    Let's have a 5 year old argument, the result of which was the inclusion of GPU drivers into the kernel.

    We've been here before.

    F

  6. #26
    Join Date
    Jun 2011
    Posts
    1,107

    Default

    Quote Originally Posted by blacknova View Post
    And how complete driver rewrite correlate to stable kernel interfaces? Driver seriously is independent piece of software which strongly relying on some services provided by kernel, e.g. pci bus support, memory management, etc.
    Are you saying that driver rewrite would become any simpler just because kernel interfaces have been changed and now developers need to figure out the new way, to do something that have been already working. Yeah, right.
    One thing you "Stable Kernel API" people don't get is this: The API does not just arbitrarily change for the hell of it. If/When it changes it's changing because the change makes things work better / have a better design, It's not like they're going "Mwahahahaha what can we do to break the drivers this week?", and the only way a stable kernel driver API is even semi-sane for drivers is if you're operating off of a Microkernel because then there shouldn't be enough in kernel changes for it to matter once it's at it's "fully-developed" state, because everything is out in userspace. Even Microsoft is only somewhat staying stable, trying to run an XP driver on Vista/7 (as in a pre-vista driver) is going to be hit or miss due to kernel changes, and WDDM was a driver API break and redesign, and was part of what screwed up the Vista launch.

    Furthermore just look at Xorg for just why stable apis don't really belong in monolithic designs, part of the entire reason it's so crappy is that it's got a Stable API that they can't touch and thus they've been forced to write extensions to get around the problem (I.E. they have to work around the issues of the X.org protocol). Does this really sound like something that should be happening with the kernel as well? Even Qt which insures ABI and API compatibility over major versions and is modularly designed does breaks which cause the creation of a new major version. Which means even something like it doesn't really have a stable API but a versioned API, which is the only thing you might have an argument for but that falls through due to the monolithic design of the kernel.
    Last edited by Luke_Wolf; 02-18-2013 at 07:42 PM.

  7. #27
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,935

    Default

    Actually X's way of depreciating interfaces is even nicer.... accidentally, quietly, break an interface / API. Someone comes along years later, notices that its been broken for years and no one noticed. The assumption is "Well no ones complained so I guess no one uses that anymore" Then they vocally and deliberately remove that interface/API and that chunk of code is gone lol

  8. #28
    Join Date
    Oct 2008
    Posts
    3,244

    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.
    Making the in-kernel interfaces backwards compatible would itself add a lot of extra work onto the developers, because they'd have to keep building compatibility interfaces on top of every change they made. Check out win32 if you think that wouldn't add up.

    But you keep on #TiltingAtWindmills

  9. #29
    Join Date
    Sep 2010
    Posts
    731

    Default

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

    1) Github ot other git repo for code upload with hooks for compilation with various configurations. (Did you know that mesa 9.0 wont compile with comands from radeonBuildHowTo? I know. I was told that on IRC after 4h of traying )

    2) PTS + some defined collection of apps (open source so you can be sure that "testing" code is in fact bug free), for performance testing.

    3) Piglit for any regressions in OpenGL that can be detected that way.

    4) PTS + games + automated screen shot + diff for images and warnings for too much difference between reference image (taken on Catalyst drivers..), and currently obtained.

    5) Whatever you can get for testing delays between following frames.

    6) Restoration of "clean" configuration on multiple failed boots.


    Everyghtin of above compared to reference (either last stable mesa+kernel+server, or Catalyst, which is better for you).

    Oh, and Server that would manage automatic restart of hw/ queuing test request from various developers, and replicating test runs on different hw configurations, as well as managing reporting.


    Better?
    Last edited by przemoli; 02-19-2013 at 06:51 AM.

  10. #30
    Join Date
    Sep 2010
    Posts
    731

    Default

    Quote Originally Posted by Ericg View Post
    Actually X's way of depreciating interfaces is even nicer.... accidentally, quietly, break an interface / API. Someone comes along years later, notices that its been broken for years and no one noticed. The assumption is "Well no ones complained so I guess no one uses that anymore" Then they vocally and deliberately remove that interface/API and that chunk of code is gone lol


    Unfortunately that do not work for core X protocol.

    So we still have paining of cool squares...

Posting Permissions

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