The State Of The SWR Software Rasterizer In Mesa

[phoronix]

Phoronix: The State Of The SWR Software Rasterizer In Mesa

New to the upcoming Mesa release is the OpenSWR software rasterizer developed by Intel and geared for faster performance, at least for the workloads of most interest to the Intel engineers working on this driver...

http://www.phoronix.com/scan.php?page=news_item&px=SWR-Software-Rast-Mesa-GL3

[blackshard]

What is the point to have three software rasterizers that do the same thing and none of them is up to latest standard too?

[microcode]

What is the point to have three software rasterizers that do the same thing and none of them is up to latest standard too?

They're all pretty architecturally different. You could possibly replace LLVMPipe with OpenSWR, but as it stands OpenSWR has been developed with the sole purpose of supporting large-scale main memory visualizations, not desktop compositing or games. The things which make OpenSWR good for large scale visualization might in fact make it worse for desktop compositing and games.

Softpipe I'm not too familiar with, but I suspect it's intended to be a simpler software renderer; not requiring LLVM to compile shaders; I don't know what specific value this offers though. I will say that it probably isn't as simple as "lol, let's have three of the same thing for no reason!".

[Serafean]

LLVMpipe is interesting in that it leverages an existing compiler infrastructure, producing machine code that should be the best possible for your CPU. (meaning it may use AVX/2 instructions) Bringing this to the default software renderer would be a PITA. You may say that LLVM might replace softpipe, but then you'd limit yourself to llvm targets, wheras softpipe should work anywhere that mesa compiles. I agree that it is a pity that none of them target GL4.X. But consider this : would it actually be useful? IMO not so much. microcode : thanks for the info on openswr.

[devius]

The things which make OpenSWR good for large scale visualization might in fact make it worse for desktop compositing and games.

Namely?

[Veerappan]

Namely?

The way that SWR works is highly threaded with lots of effort done to load balance and synchronize work between threads. It is conceivable that some of that synchronization only makes sense in systems with lots of cores and a complex workload. We won't necessarily know until someone takes the time to run some benchmarks on large/small systems for comparison purposes... which could happen any time now.

[stalkerg]

The way that SWR works is highly threaded with lots of effort done to load balance and synchronize work between threads. It is conceivable that some of that synchronization only makes sense in systems with lots of cores and a complex workload. We won't necessarily know until someone takes the time to run some benchmarks on large/small systems for comparison purposes... which could happen any time now.

I have access to 512 cores Power8 IBM machine interesting try this. What about NUMA and lock-free algorithms?

[eydee]

I agree that it is a pity that none of them target GL4.X. But consider this : would it actually be useful? IMO not so much. microcode : thanks for the info on openswr.

If implemented properly, yes. It could be used as a reference, which is used to tell application bugs from mesa/driver bugs. Especially useful for end-users, who lack the knowledge of debugging drivers. Let's say you can't run an application you should be able to. Does it run in software mode? If yes, then the problem is in the hardware implementation. If it doesn't work in software mode either, chances are you have to file a bug report for the application developer, as they probably messed something up in their code.

[illwieckz]

Another example is testing a build, you can run an OpenGL software in a virtual machine without graphic acceleration using the software renderer, if it works, even slowly, you can say the build is OK and can be delivered.

[Serafean]

If implemented properly, yes. It could be used as a reference, which is used to tell application bugs from mesa/driver bugs. Especially useful for end-users, who lack the knowledge of debugging drivers. Let's say you can't run an application you should be able to. Does it run in software mode? If yes, then the problem is in the hardware implementation. If it doesn't work in software mode either, chances are you have to file a bug report for the application developer, as they probably messed something up in their code.

Hadn't thought of that... Good point.
OTOH, that's what piglit is for.