From: Matthew Auld <matthew.auld@intel.com>
To: Dave Airlie <airlied@gmail.com>,
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] DG1 VRAM question
Date: Tue, 7 Jul 2020 09:36:16 +0100 [thread overview]
Message-ID: <d2f3ea69-96a3-e7c0-5762-e14b034fde1e@intel.com> (raw)
In-Reply-To: <CAPM=9tzBrvMPtwaEkAyMYaOv1W71De3-ZM82GpFfeHV_+XKq8g@mail.gmail.com>
On 01/07/2020 00:27, Dave Airlie wrote:
> On Sat, 27 Jun 2020 at 03:17, Daniele Ceraolo Spurio
> <daniele.ceraolospurio@intel.com> wrote:
>>
>>
>>
>> On 6/26/20 12:14 AM, Lucas De Marchi wrote:
>>> Cc Matt and Daniele
>>>
>>> On Thu, Jun 25, 2020 at 9:38 PM Dave Airlie <airlied@gmail.com> wrote:
>>>>
>>>> I can't figure this out easily so I'd thought I'd just ask, but does
>>>> DG1 have VRAM > PCIE aperture, I'm not sure I've see any mention of
>>>
>>> We'd need to go via lmem since there's no mappable aperture. There are
>>> a few patches in tree for that
>>> (see e.g. 54b512cd7a6d ("drm/i915: do not map aperture if it is not
>>> available.")) but more missing.
>>>
>>
>> To clarify, although the legacy aperture mapping that allowed the CPU to
>> access memory via the GGTT for swizzling is gone, VRAM/LMEM is still
>> cpu-mappable via pci bar.
>> Will leave the questions about possible trashing to Matt as he's more
>> familiar than me with how this works.
>
> Matt?
>
> Is DG1 assuming we can get 64-bit BARs always and the CPU will have
> access to the complete VRAM? or is there any ideas about what happens
> in those situations where 64-bit BARs aren't available and there is
> memory pressure on the PCI BAR space.
>
> With other discrete GPUs we've got lots of things like visible VRAM
> limitations, writing page tables with GPU hw instead of from the CPU,
> having mapping bring things into the visible area, so you can stream
> something into VRAM, but then it'll migrated to non-visible area if
> it's unmapped and there is memory pressure.
Yes, we just assume that LMEM size == LMEMBAR size, where the whole
thing is 1:1 mapped and CPU visible. We don't currently have the concept
of CPU visible/non-visible LMEM.
>
> Dave.
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-07-07 8:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-26 4:37 [Intel-gfx] DG1 VRAM question Dave Airlie
2020-06-26 7:14 ` Lucas De Marchi
2020-06-26 17:17 ` Daniele Ceraolo Spurio
2020-06-30 23:27 ` Dave Airlie
2020-07-07 8:36 ` Matthew Auld [this message]
2020-07-13 4:45 ` Dave Airlie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d2f3ea69-96a3-e7c0-5762-e14b034fde1e@intel.com \
--to=matthew.auld@intel.com \
--cc=airlied@gmail.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.