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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Jan 16 02:58:45 PST 2016


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

--- Comment #14 from Marek Olšák <maraeo at gmail.com> ---
(In reply to ytrezq from comment #12)
> (In reply to Marek Olšák from comment #11)
> > Yes. If you have a real GPU, any CPU rendering is a bad idea.
> 
> I just thought 2 combined ᴄᴘᴜs or 2 combined ɢᴘᴜs were better than 1. Even
> in the case the power of 1 of the part has an insignificant power compared
> to others.
> 
> That’s why I wrote :
> > Really ? does even exposing llvmpipe as a real ɢᴘᴜ in VulKan will be that
> > bad ?
> By comparison, Direct3D 12 developers don’t use software rendering when they
> use several ɢᴘᴜs, because the Microsoft Software rendering engine don’t show
> up as a ɢᴘᴜ.
> (though the Microsoft rendering engine doesn’t use ꜱɪᴍᴅ at all contrary to
> llvmpipe).
> I don’t see any reason for not getting rendering faster in that Vulkan case
> (It’s up to the programmer to decide to use multi‑ɢᴘᴜs configurations or
> not). At least the aim is to not make the llvmpipe ɢᴘᴜ different from others
> ɢᴘᴜs at the ᴀᴘɪ level.
> 
> It wasn’t in the idea in running Vulkan on only ᴄᴘᴜs of course.
> 
> 
> I already wrote such feature should be made optional at run‑time. So there’s
> would be no problems for users fearing overheat.

You are completely missing the point. The main concern is that applications may
try to use all available renderers, including llvmpipe if it's present. The
problem is that llvmpipe would significantly slow down drawing because of its
slow rendering and high overhead. I know from experience that if applications
are given a way to hurt their performance, they will eagerly take it. And
everybody will blame Linux. Everybody always blames Linux for their problems.

-- 
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/aedbf63b/attachment.html>


More information about the mesa-dev mailing list