<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTABUG - Performance improvement : Please consider hardware ɢᴘᴜ rendering in llvmpipe" href="https://bugs.freedesktop.org/show_bug.cgi?id=93686#c21">Comment # 21</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTABUG - Performance improvement : Please consider hardware ɢᴘᴜ rendering in llvmpipe" href="https://bugs.freedesktop.org/show_bug.cgi?id=93686">bug 93686</a> from <a class="email" href="mailto:jfonseca@vmware.com" title="Jose Fonseca <jfonseca@vmware.com>"> Jose Fonseca</a> <pre>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 -- <a href="http://chromium.sourceforge.net/">http://chromium.sourceforge.net/</a></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>