[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 #17 from ytrezq at sdf-eu.org ---
(In reply to Marek Olšák from comment #14)
> 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.

Only because it’s the ᴄᴘᴜ (if yes why?) or it’s because mixing slower ɢᴘᴜ
hardware slows down faster ɢᴘᴜs in general (imagining the case of an intel ɢᴍᴀ
with a geforce 7xx if they would support Vulkan (which won’t happen)) ?
As I never heard such thing for OpenCl, I guess it’s the first case (again why
?)

Otherwise, yes the aim is that applications try to use all available renderers,
llvmpipe included. (I thought adding a renderer even it’s llvmpipe would be
able to make things faster)

In the second case, then, it might only be useful in the rare case of an old
ɢᴘᴜ with a fast modern ɢᴘᴜ.
In the meantime, I’m not aware of any desktop supporting ꜱꜱᴇ4.2 and being able
to output video without a ɢᴘᴜ. So OpenGl support for llvmpipe is already for
rare cases (e.g a supercomputer without a set of graphic cards being
occasionally used for graphics rendering)

I also can’t imagine users blaming Linux after intentionally setting an
environment variable and complaining things runs slower compared to when it’s
not set.

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