Hardware Based XRender Slower than Software Rendering?

Neon Spiral Injector writes "Rasterman of Enlightenment fame has finally updated the news page of his personal site. It seems that the behind the scenes work for E is coming along. He is investigating rendering backends for Evas. The default backend is a software renderer written by Raster. Trying to gain a little more speed he ported it to the XRender extension, only to find that it became 20-50 times slower on his NVidia card. He has placed some sample code on this same news page for people to try, and see if this is also experienced on other setups."

Comments

2D acceleration using OpenGL?

[gloth]

He didn't really get too far into that, but it would be interesting to see how feasible it is to do all the 2D rendering using OpenGL, encapsulated by some layer, like his Evas.

Has anyone done that? Any interesting results? One would think that there's a lot of potential here...

Not enough details

[bobtodd]

Raster doesn't say whther he had 'Option "RenderAccel" "True"' enabled, which you must do on Nvidia cards if you want XRender acceleration.

Here is the entry from the driver README:

Option "RenderAccel" "boolean" Enable or disable hardware acceleration of the RENDER extension. THIS OPTION IS EXPERIMENTAL. ENABLE IT AT YOUR OWN RISK. There is no correctness test suite for the RENDER extension so NVIDIA can not verify that RENDER acceleration works correctly. Default: hardware acceleration of the RENDER extension is disabled.

Following that option, this one is noted:

Option "NoRenderExtension" "boolean" Disable the RENDER extension. Other than recompiling the X-server, XFree86 doesn't seem to have another way of disabling this. Fortunatly, we can control this from the driver so we export this option. This is useful in depth 8 where RENDER would normally steal most of the default colormap. Default: RENDER is offered when possible.

Graphics cards and computation

[Amit J. Patel]

There has been some work on using graphics cards for computation. The tough part is figuring out how to rephrase your algorithm in terms of what the GPU can handle. You'd expect matrix math to work out but people have tried to implement more interesting algorithms too. :-)

- Amit

Raster's on holiday

[Rabid Penguin]

Normally, he would answer some questions or comments posted about something he has written, but he will be out of town for at least a few days.

I highly doubt he meant for this to get wide-spread exposure beyond developers of Enlightenment or X. Since it has, this is a good opportunity. I'll make this clear for anyone that didn't catch it, raster WANTS XRENDER TO BE FASTER! If there is a way to alter configuration or to recode the benchmark to do so, he wants to know about it.

Rather than posting questions about his configuration (which he can't answer right now), grab the benchmarks that he put up and get better results.

Now back to your regularly scheduled trolling...

The results are not obviously broken

[asnare]

A lot of people are questioning the results claimed by Rasterman; however try downloading the thing and running it for yourself. I see the same trend that Rasterman claims when I do it.

My system: Athlon 800, nVidia 2-GTS.
Drivers: nVidia driver, 1.0.4363 (Gentoo)
Kernel: 2.4.20-r6 (Gentoo)
X11: XFree86 4.3.0

I've checked and:

1. agpgart is being used;
2. XF86 option "RenderAccel" is on.

The benchmark consists of rendering an alphablended bitmap to the screen repeatedly using Render extension (on- and off-screen) and imlib2. Various scaling modes are also tried.

When there's no scaling involved, the hardware Render extension wins; it's over twice as fast. That's only the first round of tests though. The rest of the rounds all involve scaling (half- and double-size, various antialiasing modes). For these, imlib2 walks all over the Render extension; we're talking three and a half minutes versus 6 seconds in one of the rounds; the rest are similar.

I'm not posting the exact figures since the benchmark isn't scientific and worrying about exact numbers isn't the point; the trend is undeniable. Things like agpgart versus nVidia's internal AGP driver should not account for the wide gap.

Given that at least one of the rounds in the benchmark shows the Render extension winning, I'm going to take a stab at explaining the results by suggesting that the hardware is probably performing the scaling operations each and every time, while imlib2 caches the results (or something). The results seem to suggest that scaling the thing once and then reverting to non-scaling blitting would improve at least some of the rounds; this is too easy, however, since while it helps the application that knows it's going to repeatedly blit the same scaled bitmap, not all applications know this a priori.

- Andrew