<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:ytrezq@sdf-eu.org" title="ytrezq@sdf-eu.org">ytrezq@sdf-eu.org</a>
</span> changed
<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>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>jan.vesely@rutgers.edu
</td>
</tr></table>
<p>
<div>
<b><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#c10">Comment # 10</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 <span class="vcard"><a class="email" href="mailto:ytrezq@sdf-eu.org" title="ytrezq@sdf-eu.org">ytrezq@sdf-eu.org</a>
</span></b>
<pre>(In reply to Jan Vesely from <a href="show_bug.cgi?id=93686#c9">comment #9</a>)
<span class="quote">> If GPU<->CPU synchronization is the only problem then the idea should work
> for iGPUs with coherent access to main memory (HSA complaint?). Then again
> those GPUs probably won't need CPU help any time soon.</span >
Intel or ᴀᴍᴅ ᴀᴘᴜs can’t (theoretically) do memory sharing between ᴄᴘᴜ ᴀɴᴅ ɢᴘᴜ.
Intel or ᴀᴍᴅ ᴀᴘᴜs use ᴘᴄɪe even if they are on the same die of the ᴄᴘᴜ. The
ʙɪᴏꜱ or the ᴜᴇꜰɪ firmware allocate a fixed portion of ʀᴀᴍ that appear as part
of “hardware reserved memory” to the ᴏꜱ.
There’s no Unified memory, data has to use the internal ᴘᴄɪe bus. It’s the same
as if the card was an external one with it’s own memory (though it can directly
address ᴄᴘᴜ ram modules).
The main problem with ɢᴘᴜ that only use ᴄᴘᴜ memory is they suffer from
bandwidth problem (so this like they always work with synchronizations
problems) which is why adding a ʀᴀᴍ module can do double framerates. ᴀᴘᴜs only
combine drawbacks.
Though the generation of Nvidia cards based on Pascal will be able to directly
address ᴄᴘᴜ memory while keeping their own ɢᴅᴅʀ. This will effectively provide
unified memory, but this time, the ʀᴀᴍ modules will stay behind a ᴘᴄɪe or
Nvlink bus.
I agree with <a href="show_bug.cgi?id=93686#c1">comment #1</a> this a work for a team of future developers in a ᴘhᴅ,
not for a real software project
There’s probably lot of more than required manpower and synchronisations
definitely looks like to not be the primary issue in the scenario of ɢᴘᴜ
accelerated llvmpipe.
But sum those current 2.5 scenarios :
— Use one or several ɢᴘᴜ to accelerate some part of llvmpipe computing (issues
were raised above).
— Combine the processing power of several ɢᴘᴜs and make appear llvmpipe as a
real ɢᴘᴜ among others.
– do it transparently (this what first version of OpenCl do) (Nvidia is doing
it with high‑level ᴀᴘɪs like Direct3D 11 or OpenGl as long as the card use a
supported driver along the same ᴡᴅᴅᴍ version, they probably use other hardware
things of ꜱʟɪ to do to that). Seems to be theoretically impossible.
– restrict it to Vulkan : very few devices will support this. You’ll need
hardware which is less than 1 year old. This include computers and tablets.
There’s also the problem of all previous work written in OpenGl. Only seems a
good idea in some rare supercomputers scenarios.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>