https://bugs.freedesktop.org/show_bug.cgi?id=93686
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #22 from [email protected] --- (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.
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
