Originally posted by Ancurio
View Post
Announcement
Collapse
No announcement yet.
RadeonSI Gallium3D Gets UBO/TBO Support, OpenGL 3.3
Collapse
X
-
Originally posted by dffx View PostRadeonSI performance is pretty widely spread across the board. With Color Tiling enabled it can get up to 80% catalyst speeds with certain applications, though it averages more around 50-60%. Still not bad, all things considered.
Comment
-
Originally posted by zanny View PostIf you are getting half performance of another software implementation of a driver, there are some fundamental missing features of the gpu you aren't using. Maybe if AMD would stop crippling their gpus with firmware blobs some of the Red Hat or Novell guys would help use the SI architecture to its potential, but as long as we only get face value FOSS drivers over obfuscated hardware we're stuck with the halfhearted efforts AMD is making.
If you are running a game at 50fps instead of 100fps, it just shows that your driver has an extra 10ms of overhead per frame. Could that be because it's missing some hardware feature? Sure. It could also be because the driver is mistakenly pushing out an extra memory flush each frame. It could also be because of a bunch of cpu usage each frame. It could be because of a bunch of different issues.
The main hardware features that are currently missing are: HyperZ, proper-clocking (new kernel will enable it for some, but not all SI cards), and geometry shaders + GL4 features.
Could there be others? Sure - but one other thing you can be sure of is that the performance isn't simply due to AMD using firmware blobs. That's idiotic.
Comment
-
-
Originally posted by zanny View PostIf you are getting half performance of another software implementation of a driver, there are some fundamental missing features of the gpu you aren't using. Maybe if AMD would stop crippling their gpus with firmware blobs some of the Red Hat or Novell guys would help use the SI architecture to its potential, but as long as we only get face value FOSS drivers over obfuscated hardware we're stuck with the halfhearted efforts AMD is making.
Comment
-
Originally posted by Ancurio View PostFeature parity =/= efficiency parity. Everything could be looking correctly graphics wise while still running at 30% of the binary blob's speed.
I have to admit, I'm upgrading for windows gaming performance. Guild Wars 2 @ 2560x1440 is demanding enough that I wouldn't even accept the overhead of the wine layer, and I don't play other games at the moment. Otherwise, my old GPU is fast enough for all my linux needs, so all I'm looking for right now is simply a regression-free upgrade.
I'm hoping that during 2014, when SteamOS takes off, the OSS drivers will have closed the gap enough that I can look at gaming on linux again.
Comment
-
Originally posted by dffx View PostBy your comment it seems you may not be familiar with the method in which the open source drivers are developed. While AMD does provide support for open source driver development (even employing a few developers) they are largely "on their own" and they are not backed up by the large volume of developers and engineers that otherwise work for AMD. I certainly don't profess to know what resources they AMD open source devs have at their disposal, but Xorg devs certainly only have a limited set of resources to work with. If you're going to fault AMD for anything, fault them for not operating like Intel does and don't push for fully open source driver development across the board, don't fault the limited (but steadily increasing) performance of the open source, community developed driver.
RadeonSI was written almost entirely by AMD employees on AMD payroll. Now the time is coming for the community to optimise it.
The experience of r300g and r600g is a really positive one. Both drivers started with poor performance, but increased rapidly until they (almost) matched Catalyst. RadeonSI is on that path now -- mostly working, optimisations beginning.
Comment
-
Originally posted by 89c51 View PostI am not sure there are many that can do this in the community.
Marek did a huge number of optimisations and added many features to r600g and r300g before joining AMD. Christian K?nig figured out and implemented HDMI audio before joining AMD, etc.
Then there are experienced developers such as Dave Airlie and Jerome Glisse of Red Hat, who are paid to work on open drivers, but not by AMD.
Hopefully, there will be new community members popping up. With something as complex as GPU drivers, it will always be a small number, but even a small number of talented guys can make a huge difference.
Comment
Comment