[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

ytrezq at sdf-eu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jfonseca at vmware.com

--- Comment #22 from ytrezq at sdf-eu.org ---
(In reply to Jose Fonseca from comment #21)
> 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.
Yeah, OpenCl is only useful for general purposes computations
> 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.
This is what I thought : each technical issue is solvable. But put together it
turns lack of manpower in a blocking state. (Though in the case in the case of
Vulkan, I still think many users will try to get a better performance by
combining the processing power of their integrated intel ʜᴅ with a Geforce 1000
combined with a top modern ᴀᴍᴅ card (this use case of slow ɢᴘᴜ with fast ɢᴘᴜ is
even advertised for Direct3D 12))
> 
> 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.
> 
I have doubts for the ꜱɪᴍᴅ nature in that case (since llvmpipe heavily rely on
ꜱɪᴍᴅ) : isn’t Xeon phi internally a set of the legacy pentium pro burned on the
same chip ?
> 
> BTW, what you asked has been attempted -- http://chromium.sourceforge.net/
A Google search on chromium revealed nothing : could give more detailed links
please ?

-- 
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/566012e9/attachment-0001.html>