[Mesa-dev] [Bug 93686] Performance improvement ?=:=?UTF-8?Q? Please consider hardware ɢᴘᴜ rendering in llvmpipe

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93686

--- Comment #21 from Jose Fonseca <jfonseca at vmware.com> ---
I'm one of llvmpipe authors (particularly the initial bring up of the driver).


Enabling llvmpipe to run on top of, or side-by-side with, GPUs or clusters via
OpenCL/whatever is not something we're interested.


OpenCL is inadequate for 3D graphics, and it also abstracts away too much of
the CPU details to be useful for the highly optimized x86 code in llvmpipe.  If
somebody wants to use GPUs for 3D graphics, they should use the 3D graphics GPU
drivers.

Mixing GPUs with something else is also pointless as others have pointed here. 
_Even_ if it made sense from a performance POV (which does not), it's
impossible merely from a correctness POV -- you'd have rasterzation
differences, depth fighting, all sort of nasty issues, which all together are
insurmountable.  (I.e, take many life times of work to nail and for little or
no benefit.)

If somebody wants to fork llvmpipe and pursue it they're free to do so, but
there's no way we would merge any of that work back into llvmpipe (or likely
not even Mesa).



The only exception IMO, is Xeon Phi -- it looks like a GPU in some regards, but
it has a x86-like ISA and runs its own OS --, so it wouldn't be too much of a
stretch to port llvmpipe to run inside the Xeon Phi micro OS.  In order for
this to be useful we'd need to have a thin transport gallium driver that would
runs on the host OS and communicates with the llvmpipe driver in the Xeon Phi. 
That is, mimic the Larrabee architecture (but this time without any of the GPU
fixed function that Larrabee had like texture caches.)


We have no plan to work on this ourselves -- performance would never beat a
dedicated GPU with 3D graphics specific circuits --- but it's a cool project
and not disruptive, so if somebody wanted to pursue this, I think this is
something we could accommodate.


Of course, this is not what the bug reporter asked for: llvmpipe would only run
inside Xeon Phi, it would not cooperate with another llvmpipe instance on the
host.



BTW, what you asked has been attempted -- http://chromium.sourceforge.net/

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20160116/c990e917/attachment.html>