[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 04:25:24 PST 2016


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

ytrezq at sdf-eu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alexdeucher at gmail.com

--- Comment #15 from ytrezq at sdf-eu.org ---
(In reply to Alex Deucher from comment #13)
> I can't speak for intel, but on AMD APUs, while the GPU appears as a device
> on the PCIE bus, it actually has a much faster internal connection to the
> memory controller.
You’re still confusing things. Of course they use the same memory controller
directly. Of course they share the same memory modules.
However they can’t read or write in memory of each others. So this behave like
an external card ᴘᴄɪe card with it’s own memory modules (if we forget the
bandwidth is also shared with an another device so each ones slow each others).

So if you want to send or receive data it can only happens over the ᴘᴄɪe bus,
triggering the same synchronisations problems of external chipsets due to the
bus bandwidth and instructions overhead.

Unified memory will only happen in future generations of graphics cards, but
only behind a ᴘᴄɪe bus (which will slow things because there’s still the memory
controller bus adding overhead), so we’re far from the time were ɢᴘᴜs of ᴀᴘᴜs
will be able to access ʀᴀᴍ of ᴄᴘᴜs with the same overhead (at that time it’s
expected ʀᴀᴍ modules would have been merged into the ᴄᴘᴜ chip meaning there
would be no longer separated ʀᴀᴍ modules).

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


More information about the mesa-dev mailing list