public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Arnd Bergmann <arnd@arndb.de>, Arnd Bergmann <arnd@kernel.org>,
	Alex Deucher <alexander.deucher@amd.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	Dave Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>
Cc: Hawking Zhang <Hawking.Zhang@amd.com>,
	Lijo Lazar <lijo.lazar@amd.com>,
	Mario Limonciello <mario.limonciello@amd.com>,
	YiPeng Chai <YiPeng.Chai@amd.com>, Le Ma <le.ma@amd.com>,
	Bokun Zhang <Bokun.Zhang@amd.com>,
	Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>,
	Shiwu Zhang <shiwu.zhang@amd.com>,
	amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()
Date: Wed, 5 Jul 2023 14:27:03 +0200	[thread overview]
Message-ID: <cf414be3-40fa-7a7f-1d31-9c8efd54d587@amd.com> (raw)
In-Reply-To: <2dff4d81-9b45-4d69-9e30-972f2c9318d9@app.fastmail.com>

Am 04.07.23 um 17:24 schrieb Arnd Bergmann:
> On Tue, Jul 4, 2023, at 16:51, Christian König wrote:
>> Am 04.07.23 um 16:31 schrieb Arnd Bergmann:
>>> On Tue, Jul 4, 2023, at 14:33, Christian König wrote:
>>>> Modern AMD GPUs have 16GiB of local memory (VRAM), making those
>>>> accessible to a CPU which can only handle 32bit addresses by resizing
>>>> the BAR is impossible to begin with.
>>>>
>>>> But going a step further even without resizing it is pretty hard to get
>>>> that hardware working on such an architecture.
>>> I'd still like to understand this part better, as we have a lot of
>>> arm64 chips with somewhat flawed PCIe implementations, often with
>>> a tiny 64-bit memory space, but otherwise probably capable of
>>> using a GPU.
>> Yeah, those are unfortunately very well known to us :(
>>
>>> What exactly do you expect to happen here?
>>>
>>> a) Use only part of the VRAM but otherwise work as expected
>>> b) Access all of the VRAM, but at a performance cost for
>>>      bank switching?
>> We have tons of x86 systems where we can't resize the BAR (because of
>> lack of BIOS setup of the root PCIe windows). So bank switching is still
>> perfectly supported.
> Ok, good.
>
>> After investigating (which sometimes even includes involving engineers
>> from ARM) we usually find that those boards doesn't even remotely comply
>> to the PCIe specification, both regarding power as well as functional
>> things like DMA coherency.
> Makes sense, the power usage is clearly going to make this
> impossible on a lot of boards. I would have expected noncoherent
> DMA to be a solvable problem, since that generally works with
> all drivers that use the dma-mapping interfaces correctly,
> but I understand that drivers/gpu/* often does its own thing
> here, which may make that harder.

Yeah, I've heard that before. The problem is simply that the dma-mapping 
interface can't handle those cases.

User space APIs like Vulkan and some OpenGL extensions make a coherent 
memory model between GPU and CPU mandatory.

In other words you have things like ring buffers between code running on 
the GPU and code running on the CPU and the kernel is not even involved 
in that communication.

This is all based on the PCIe specification which makes it quite clear 
that things like snooping caches is mandatory for a compliant root complex.

There has been success to some degree by making everything uncached, but 
then the performance just sucks so badly that you can practically forget 
it as well.

Regards,
Christian.

>
>       Arnd


      reply	other threads:[~2023-07-05 12:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-03 12:35 [PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar() Arnd Bergmann
2023-07-04  6:54 ` Christian König
2023-07-04 12:24   ` Arnd Bergmann
2023-07-04 12:33     ` Christian König
2023-07-04 14:31       ` Arnd Bergmann
2023-07-04 14:51         ` Christian König
2023-07-04 15:24           ` Arnd Bergmann
2023-07-05 12:27             ` Christian König [this message]

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=cf414be3-40fa-7a7f-1d31-9c8efd54d587@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Bokun.Zhang@amd.com \
    --cc=Hawking.Zhang@amd.com \
    --cc=Xinhui.Pan@amd.com \
    --cc=YiPeng.Chai@amd.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=le.ma@amd.com \
    --cc=lijo.lazar@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=shiwu.zhang@amd.com \
    --cc=srinivasan.shanmugam@amd.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox