Page 5 of 21 FirstFirst ... 3456715 ... LastLast
Results 41 to 50 of 202

Thread: A Big Comparison Of The AMD Catalyst, Mesa & Gallium3D Drive

  1. #41
    Join Date
    Jun 2009
    Posts
    2,647

    Default

    Quote Originally Posted by Wyatt View Post
    Wow, so r600g is usable? The Gallium feature matrix indicates otherwise, but it hasn't been updated in a few months. http://xorg.freedesktop.org/wiki/GalliumStatus

    Good work, graphics-stack programmers!
    r600g is better at some things and worse at some things than r600c now, and most of the current effort is going into r600g.

    r600g is faster, but less stable than r600c for me. I switch back and forth.

  2. #42
    Join Date
    Jan 2009
    Posts
    233

    Default

    Yah.. r300g is still CPU limited at least to some extent. I'm only getting 10 or less FPS out of openarena on a 2xPII@300Mhz w/ radeon 9800 SE (not nearly as fast as the 9800 Pro but still respectible)

    Course its common knowledge that openarena is quite CPU limited itself...

    It might have improved some in the last month though.. since I checked

    Are there any benchmarks/games that are severly GPU limited but light on the CPU I could try?

  3. #43
    Join Date
    Jan 2009
    Posts
    1,251

    Default

    i read about CPU being the bottleneck (or one of) and i have to ask.

    how come the blobs are not affected by it?? or is just that the other optimizations they have compensate for that??

  4. #44
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,618

    Default

    Quote Originally Posted by 89c51 View Post
    i read about CPU being the bottleneck (or one of) and i have to ask.

    how come the blobs are not affected by it??
    That's a wrong question. "It" doesn't exist as an entity. A bottleneck is not an entity that exists, it's just a behavior resulting from non-optimal code. Otherwise we would use bottleneck firewalls so that those evil bottlenecks are kept out :-P

    The blobs are written with performance in mind. If they weren't, people would not buy the cards. The open source drivers and surrounding stack are not written with performance in mind. The developers struggle to make the stuff work as it is. Trying to match the performance of the blobs at the same time would probably mean that we would have to wait another 10 years for the drivers.

  5. #45
    Join Date
    Oct 2008
    Posts
    2,122

    Default

    Quote Originally Posted by 89c51 View Post
    i read about CPU being the bottleneck (or one of) and i have to ask.

    how come the blobs are not affected by it?? or is just that the other optimizations they have compensate for that??
    To clarify, the blobs are CPU limited on most of those tests as well. It's just that they are optimized to use less CPU and so perform much better. I suspect that in a shader heavy test the results might be closer together because it would rely more on the GPU and less on the CPU, but I really don't know if that's true or not. Michael's never really tried that kind of situation on any of these tests.

  6. #46
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    6,909

    Default

    The binary drivers are also multi-threaded, which helps to hide CPU overhead *if* you have at least 2 cores.

    Multithreading mostly helps when drawing is the bottleneck, however, but some of the initial profiling efforts suggest that state changes may be a bigger time sink than drawing right now. Not sure if that has been confirmed though.

  7. #47
    Join Date
    Nov 2007
    Posts
    957

    Default

    Quote Originally Posted by BlackStar View Post
    No, that won't cut it. Compiz *can* do what you suggest, but this 'feature' is extremely userunfriendly and is thankfully disabled by default. If you disable compositing for fullscreen windows and a notification pops up, you are in for a flicker-fest.
    How about disable compositing only for full-screen windows that are above all other windows?

    Enable compositing if something else pops up on top, full speed if there's nothing in the way.

    I'm not familiar enough with how the compositing is enabled/disabled for existing windows and whether or not this is feasible.

  8. #48
    Join Date
    Aug 2007
    Posts
    6,496

    Default

    With the exception of Q nobody would use a highend gfx card with oss drivers to play games. Some results are a bit weird that some tests are faster with a higher res but basically every noob should see that oss drivers are not made for gaming, they handle compiz, maybe some very old games but thats all.

  9. #49
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,618

    Default

    Quote Originally Posted by elanthis View Post
    How about disable compositing only for full-screen windows that are above all other windows?

    Enable compositing if something else pops up on top, full speed if there's nothing in the way.
    Uhm, that's exactly how this is currently done in both Compiz as well as KDE.

  10. #50
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,045

    Default

    Quote Originally Posted by RealNC View Post
    Uhm, that's exactly how this is currently done in both Compiz as well as KDE.
    Except when it isn't. It works that way in theory, yes.

Posting Permissions

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