Hi everybody Just want to ask Jeremy about some of my concerns linked to the bug http://xquartz.macosforge.org/trac/ticket/261#comment:8. In the bug there is a comment: If your issue is that it is only at 7fps, then that is another issue entirely... and it's most likely a fallout from rlAccel being removed. That is something that will hopefully be addressed in a new EXA driver for 2D performance gains. Does it basically mean that graphics sensitive utilities like Gimp will significantly suffer from rlAccel removal? I rely on Gimp for my work and if it will be 3-4 times slower it's like a major disaster. Thanks in advance. Platon.
Platon Fomichev wrote:
Hi everybody
Just want to ask Jeremy about some of my concerns linked to the bug http://xquartz.macosforge.org/trac/ticket/261#comment:8. In the bug there is a comment:
If your issue is that it is only at 7fps, then that is another issue entirely... and it's most likely a fallout from rlAccel being removed. That is something that will hopefully be addressed in a new EXA driver for 2D performance gains.
Does it basically mean that graphics sensitive utilities like Gimp will significantly suffer from rlAccel removal? I rely on Gimp for my work and if it will be 3-4 times slower it's like a major disaster.
Thanks in advance.
rlAccel was disabled around 2.1.x and hasn't been on since. It actually isn't a big concern. The fastpaths that it enabled are nice, but the pixman fastpaths are similar in nature, so I don't think we're suffering a big hit. Sure, it would be nicer to offload some of that from the CPU to the GPU, but it's not that critical. This is the first case where it has actually come up. I did some testing and actually re-enabled rlAccel and reran the xscreensaver, and it was only 9fps (as opposed to 7). So it is a slight improvement, but the bottleneck is certainly elsewhere. You said the last time this worked fast for you was on Tiger... a LOT has changed since Tiger, so this will be non-trivial to track down unless you can give more data points. Thanks, Jeremy
Let me ask a different question: If someone else were willing to do the work of repairing and bringing rlAccel up to date, would it be welcome in the tree? On Jul 25, 2009, at 3:40 PM, Jeremy Huddleston wrote:
rlAccel was disabled around 2.1.x and hasn't been on since. It actually isn't a big concern. The fastpaths that it enabled are nice, but the pixman fastpaths are similar in nature, so I don't think we're suffering a big hit. Sure, it would be nicer to offload some of that from the CPU to the GPU, but it's not that critical. This is the first case where it has actually come up. I did some testing and actually re-enabled rlAccel and reran the xscreensaver, and it was only 9fps (as opposed to 7). So it is a slight improvement, but the bottleneck is certainly elsewhere.
On Jul 25, 2009, at 19:32, Jordan K. Hubbard wrote:
Let me ask a different question: If someone else were willing to do the work of repairing and bringing rlAccel up to date, would it be welcome in the tree?
If someone found out why rlAccel is crashing and handed off a fix, I'd certainly welcome it, and if someone is interested in tacking such work, please speak up as it's a nice compact task that can help you get involved... Unfortunately, I don't see myself devoting any time specifically to rlAccel. "the right way" will involve rewriting the 2D operations using the EXA framework which was designed to do exactly what we were using rlAccel for.
On Jul 25, 2009, at 3:40 PM, Jeremy Huddleston wrote:
rlAccel was disabled around 2.1.x and hasn't been on since. It actually isn't a big concern. The fastpaths that it enabled are nice, but the pixman fastpaths are similar in nature, so I don't think we're suffering a big hit. Sure, it would be nicer to offload some of that from the CPU to the GPU, but it's not that critical. This is the first case where it has actually come up. I did some testing and actually re-enabled rlAccel and reran the xscreensaver, and it was only 9fps (as opposed to 7). So it is a slight improvement, but the bottleneck is certainly elsewhere.
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
participants (3)
-
Jeremy Huddleston
-
Jordan K. Hubbard
-
Platon Fomichev