Originally posted by Kano
View Post
Announcement
Collapse
No announcement yet.
Where The Open-Source AMD Driver Is At For Modern GPUs
Collapse
X
-
Originally posted by yaji View PostYup, I would definitely buy a HD5830 to play Quake Live. No wait, Quake 3 was working fine on GeForce2... Well, after thinking about it, I think I'll stick to Catalysts.
Comment
-
Originally posted by pingufunkybeat View PostIt's like GCC vs. ICC. ICC is much faster, but everyone uses GCC anyway, because speed is not everything. We need to cover the needs of the computer users, free software itself is THE killer argument.
Comment
-
Originally posted by deanjo View PostThe difference being is that the gap in performance for a vast majority of compiled items is usually about 5-10% if there is a difference at all when it comes to icc vs gcc. Gcc can also be faster on some items again not by much. Also the resulting binary winds up with the same features no matter what compiles it. Comparing compilers to drivers isn't a good comparison.
Sure, the r600+ drivers have some catching up to do, but they did start far too late, and they did catch up a lot already. If the drivers reach the 75% mark (as they are expected to and like r300g did), then it will indeed be a good comparison.
I also don't see why comparing compilers to drivers is not a good comparison, when a large part of what a modern GPU driver does is actually compiling. In fact, they translate OpenGL code and shaders into a form that the GPU (a processor) can execute.
Comment
-
Originally posted by Jimbo View Postit seems some type of "architectural" problem.
- the amd gpu conception (contrary to nvidia) need that the kernel take time to analyze the command buffer, for security reason. fglrx do not do that.
- there is some limitation is the API, and it's not easy to fix. Moreover the kernel api is freeze, contrary to nouveau.
- r600g have a design that is not the best to do what it do.
To conclude, in fact, the main "problem" with r600g is in the kernel, not really in gallium side.
Comment
-
Originally posted by pingufunkybeat View PostWell, if the performance difference is 20% (if there is one at all), like is the case with r300g, then it is indeed a good comparison.
Comment
-
Originally posted by whitecat View PostYes it is. As J?r?me Glisse said, there is several points :
- the amd gpu conception (contrary to nvidia) need that the kernel take time to analyze the command buffer, for security reason. fglrx do not do that.
- there is some limitation is the API, and it's not easy to fix. Moreover the kernel api is freeze, contrary to nouveau.
- r600g have a design that is not the best to do what it do.
To conclude, in fact, the main "problem" with r600g is in the kernel, not really in gallium side.
Comment
-
mmmm Michael maybe is cuz my card is a 4850 but nexuiz in the most extreme preset is always around 50 fps at 1440x900 using mesa-git, natty, drm git, ddx git, 2.6.38 drm next (2.6.39 broke btrfs so i can't boot it), color tiling, swapwait off, st3c support, etc.
well im using custom cflags but still those results are creepy slow, maybe pts is missing something?
i know you do out of the box benchs but it won't hurt to create some sort of tweaked profile wich is more likely to be closer to the real state of the driver, remember r600 is under heavy development
Comment
Comment