Page 2 of 6 FirstFirst 1234 ... LastLast
Results 11 to 20 of 60

Thread: Bettering Radeon Gallium3D Performance With PCI-E 2.0

  1. #11
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    906

    Default

    It isn't so simple, even not considering the legal stuff (thanks software patents) they are two completely different stacks.
    I will keep my HD5870 so my childrens will be able to take advantage of its full potential
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

  2. #12
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    574

    Default

    Quote Originally Posted by Azpegath View Post
    Unless they start merging stuff from Catalyst to the FOSS drivers. I don't quite understand why they don't do that. I assume that the FOSS devs have access to the closed source code for Catalyst. I mean, what's the difference between merging actual Catalyst code and re-implementing it from open specifications? In the end, the functionality (and to some extent the code) should be the same.
    For one Catalyst is written in C++ and the kernel code and mesa are written in C
    Last edited by FireBurn; 01-20-2012 at 07:21 AM. Reason: typo

  3. #13
    Join Date
    Dec 2009
    Posts
    492

    Default

    Quote Originally Posted by darkbasic View Post
    Just in time for PCI-E 3.0
    Didn't image such a big boost, at least in Windows the boost is very little with pci-e 2.0
    On Windows, the boost was very small with PCIe 2.0.
    Windows has PCIe 2.0 support from day 1. Back in those days, the cards available couldn't use the added bandwidth, but if you'd do the tests today, you'd definitely see bigger gains.

  4. #14
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,988

    Default

    Quote Originally Posted by darkbasic View Post
    Just in time for PCI-E 3.0
    Didn't image such a big boost, at least in Windows the boost is very little with pci-e 2.0
    This highlights a problem in mesa - mainly, it moves more data over the bus than the Windows drivers.

  5. #15
    Join Date
    Dec 2007
    Posts
    2,327

    Default

    Quote Originally Posted by Azpegath View Post
    Unless they start merging stuff from Catalyst to the FOSS drivers. I don't quite understand why they don't do that. I assume that the FOSS devs have access to the closed source code for Catalyst. I mean, what's the difference between merging actual Catalyst code and re-implementing it from open specifications? In the end, the functionality (and to some extent the code) should be the same.
    We do not have access to the catalyst source code due to the fact that it contains 3rd party code that's not ours to release. Additionally, the actual software stacks are very different and largely incompatible.

  6. #16
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,020

    Default

    But I imagine looking at e.g. the power saving code could still tell a very good programmer why radeon on the "low" profile still uses more power than fglrx.

    I mean, why doesn't AMD simply have somebody going over the code of catalyst, deleting everything patented or "secret" and release the nonfunctional rest? Could still be helpful for low level stuff like power saving and communicating properly with the hardware...

  7. #17
    Join Date
    Dec 2009
    Posts
    492

    Default

    Quote Originally Posted by ChrisXY View Post
    But I imagine looking at e.g. the power saving code could still tell a very good programmer why radeon on the "low" profile still uses more power than fglrx.

    I mean, why doesn't AMD simply have somebody going over the code of catalyst, deleting everything patented or "secret" and release the nonfunctional rest? Could still be helpful for low level stuff like power saving and communicating properly with the hardware...
    That's legal territory. Do not attempt to apply logic.

  8. #18
    Join Date
    Jun 2009
    Posts
    1,093

    Default

    Quote Originally Posted by ChrisXY View Post
    But I imagine looking at e.g. the power saving code could still tell a very good programmer why radeon on the "low" profile still uses more power than fglrx.

    I mean, why doesn't AMD simply have somebody going over the code of catalyst, deleting everything patented or "secret" and release the nonfunctional rest? Could still be helpful for low level stuff like power saving and communicating properly with the hardware...
    by the time thats get done mesa 12.1 would be the distro standard version, beside that code is useless for mesa is like asking microsoft to release their kernel code to improve linux powermanagement in laptops.

    mesa ppl already knows very clearly (prolly) what all the missing bits are and globally whats needed to face catalyst very close, what ppl seems to don't understand no matter how many times is explained is that mesa have like 5 DEVELOPERS and the code to handle GPU is EXTREMELY COMPLEX so is not like you can't magically shave out of your ass a couple of houndred thousand of lines code to magically make all work

  9. #19
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    500

    Default

    I just have the bad feeling that AMD will lose against intel in the GPU side too, on Linux.
    I wished they could focus on one thing but make it right.
    Missing features from r600g are 2D Tiling,HiZ, apparently PCI-E2, power saving. Why it is a problem for AMD employee to look at the catalyst, and see how these features are implemented(registers involved, state transitions, specific chips code-paths, etc), and re implement them on r600g? I am not talking here about *super secret* shader compiler(which nvidia may steal, and somehow adapt to their totally different architecture), but just enablement code.

  10. #20
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    500

    Default

    Quote Originally Posted by bug77 View Post
    That's legal territory. Do not attempt to apply logic.
    I don't mean copy-paste. I mean actual rewrite, but the code was already R&D.
    Apparently Intel are not afraid from legal issues.

Posting Permissions

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