[AMD Official Use Only - Internal Distribution Only]
At the risk of asking a dumb question, does amdgpu default to using DC on SI
and CI ?
I'm asking because a lot of people seem to be using amdgpu successfully with
analog outputs today on SI/CI... suggests that they are not using DC ?
If so t
>>Uh, that doesn't work. If you want infinite compute queues you need the
amdkfd model with preempt-ctx dma_fence. If you allow normal cs ioctl to
run forever, you just hang the kernel whenever userspace feels like. Not
just the gpu, the kernel (anything that allocates memory, irrespective of
proc
[AMD Official Use Only - Internal Distribution Only]
Suggest you use something more demanding that glxgears as a test - part of the
problem is that glxgears runs so fast normally (30x faster than your display)
that even a small amount of overhead copying a frame from one place to another
makes
[AMD Official Use Only - Internal Distribution Only]
>Hi! I noticed that the AQL packets are more concise compared with PM4 packets.
>It seemed that AQL packets need more post-processing than PM4 packets.
>I was wondering where the AQL packets are processed, such like calculating the
>code addre
[AMD Official Use Only - Internal Distribution Only]
If you want to pick up the firmware directly it is maintained at...
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amdgpu
-rw-r--r-- sienna_cichlid_ce.bin 263296 logstatsplain
-rw-r--r-- sienna_cichlid_dmcu
Do we still need the HSA_AMD option ?
Seems to me that KFD stopped being "something we only sometimes include" a long
time ago.
Thanks,
John
From: amd-gfx on behalf of StDenis, Tom
Sent: December 10, 2018 10:02 AM
To: Kuehling, Felix
Cc: Huang, JinHuiEric;
Don't we want PDE faults to be treated the same way as page faults? Or am I
misinterpreting the commit message?
Thanks,
John
Original Message
From: Alex Deucher
Sent: Monday, February 25, 2019 21:53
To: Zhao, Yong
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Set VM_L2_CNTL
Or is the idea that we should never see a PDE fault unless something goes
wrong, and that we would set up an entry corresponding to an unmapped subtree
as an invalid PTE for a very large page rather than an invalid PDE?
Thanks,
John
Original Message
From: Bridgman, John
Sent: Monday, February
[AMD Official Use Only - Internal Distribution Only]
The decoded MCE info doesn't look right... if the last bit is a zero I believe
that means the watchdog timer is not enabled.
That said, I'm not sure how the decoder you found works, but it seems like a
bit more information would be required t
ch ones to recommend.
From: amd-gfx on behalf of Bridgman,
John
Sent: March 8, 2020 2:45 PM
To: Clemens Eisserer ; amd-gfx@lists.freedesktop.org
Subject: Re: Possibility of RX570 responsible for spontaneous reboots (MCE)
with Ryzen 3700x?
[AMD Official Use Only
[AMD Public Use]
Fixing the security tag...
From: amd-gfx on behalf of Bridgman,
John
Sent: March 8, 2020 3:10 PM
To: Clemens Eisserer ; amd-gfx@lists.freedesktop.org
Subject: Re: Possibility of RX570 responsible for spontaneous reboots (MCE)
with Ryzen
0 2:30 AM
To: Bridgman, John ; amd-gfx@lists.freedesktop.org
Subject: Re: Possibility of RX570 responsible for spontaneous reboots (MCE)
with Ryzen 3700x?
Hi John,
Thanks a lot for taking the time to look at this, even if it doesn't
seem to be GPU related at first.
> OK, that's a
Hi Nick,
I can see your username on the radeon IRC channel, so that much is working.
When I try to chat it just hands up at "offering DCC CHAT to haweh" though.
What kind of error message are you getting ?
Thanks,
John
From: amd-gfx on behalf of nick
Sen
[AMD Official Use Only - Internal Distribution Only]
Does the VBIOS come up with something like a splash screen, ie is VBIOS able to
initialize and drive the card ?
If so then another option might be to use a VESA driver rather than VGA.
From: amd-gfx on behal
ng you are using a 32-bit CPU ? Is it possible to talk to whoever
does SBIOS for your platform to see if you could maybe reduce address space
allocated to RAM and bump up the MMIO space ?
From: Christian König
Sent: February 18, 2020 9:19 AM
To: Bridgman, Joh
[AMD Official Use Only - Internal Distribution Only]
The one suggestion I saw that definitely seemed worth looking at was adding
download caches if the larger CI systems didn't already have them.
Then again do we know that CI traffic is generating the bulk of the costs ? My
guess would have bee
L programs were written. I'll
try to dig up some history for that and ask around internally as well.
From: Andres Rodriguez
Sent: December 23, 2016 11:30 AM
To: Bridgman, John
Cc: Koenig, Christian; Zhou, David(ChunMing); Huan, Alvin; Mao, David;
Sagalovitch, Serguei; amd-gfx@lists.fre
play stops responding) might be acceptable.
From: Sagalovitch, Serguei
Sent: December 23, 2016 12:10 PM
To: Bridgman, John; Andres Rodriguez
Cc: Koenig, Christian; Zhou, David(ChunMing); Huan, Alvin; Mao, David;
amd-gfx@lists.freedesktop.org; Andres Rodriguez; Pierre-Loup A. Griffais;
Zhang, Hawki
One question I just remembered - the amdgpu driver includes some scheduler
logic which maintains per-process queues and therefore avoids loading up the
primary ring with a ton of work.
Has there been any experimentation with injecting priorities at that level
rather than jumping straight to HW
t: Friday, February 10, 2017 12:57 PM
>To: Andres Rodriguez
>Cc: Kuehling, Felix; Bridgman, John; amd-gfx@lists.freedesktop.org;
>Deucher, Alexander; Jay Cornwall
>Subject: Re: Change queue/pipe split between amdkfd and amdgpu
>
>I don't have a repo, nor do I have the source code.
In patch "drm/amdgpu: implement ring set_priority for gfx_v8 compute" can you
remind me why you are only passing pipe and not queue to vi_srbm_select() ?
+static void gfx_v8_0_ring_set_priority_compute(struct amdgpu_ring *ring,
+ int priority)
+{
This is a request for Dave to pull changes from Alex's tree into Dave's
"drm-fixes" tree, which is the last step before it gets sent to Linus.
Dave is the drm subsystem maintainer, and drm-next / drm-fixes branches are
where code from multiple GPU driver maintainers comes together. Dave would g
code for a number of different
vendors.
Some people felt that would be a big help while others felt it would not make
any difference - how do you feel about that ?
>-Original Message-
>From: Bridgman, John
>Sent: Wednesday, August 31, 2016 10:22 PM
>To: Huang, Ray; F
Right... the microcode is part of the HW design; some vendors build the
microcode images into the chip, while others have the BIOS or driver load them
at start-up.
The industry is generally moving to driver-loaded microcode, but I don't
believe any vendor is planning to start opening up their
h only supports cards that
people can't buy yet.
From: Dave Airlie
Sent: December 11, 2016 9:57 PM
To: Wentland, Harry
Cc: dri-devel; amd-gfx mailing list; Bridgman, John; Deucher, Alexander;
Lazare, Jordan; Cheng, Tony; Cyr, Aric; Grodzovsky, Andrey
Su
couple of typo fixes re: top posting and "only supports" -> "is only used for"
____
From: Bridgman, John
Sent: December 11, 2016 10:21 PM
To: Dave Airlie; Wentland, Harry
Cc: dri-devel; amd-gfx mailing list; Deucher, Alexander; Lazare, Jordan;
v3 with typo fixes and additional comments/questions..
From: Bridgman, John
Sent: December 11, 2016 10:21 PM
To: Dave Airlie; Wentland, Harry
Cc: dri-devel; amd-gfx mailing list; Deucher, Alexander; Lazare, Jordan; Cheng,
Tony; Cyr, Aric; Grodzovsky, Andrey
Yep, good point. We have tended to stay a bit behind bleeding edge because our
primary tasks so far have been:
1. Support enterprise distros (with old kernels) via the hybrid driver
(AMDGPU-PRO), where the closer to upstream we get the more of a gap we have to
paper over with KCL code
2. Pus
>>If the Linux community contributes to DC, I guess those contributions
can generally be assumed to be GPLv2 licensed. Yet a future version
of the macOS driver would incorporate those contributions in the same
binary as their closed source OS-specific portion.
My understanding of the "general ru
An upcoming GPU generation (Vega).
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Mike
Lothian
Sent: Monday, December 19, 2016 10:49 PM
To: Liu, Monk; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 02/23] drm/amdgpu: add kiq into compiling
I'd be curious to know wh
amd-gfx is the mailing list for the amdgpu kernel driver, which is part of the
drm subsystem in the Linux kernel.
It lives in the drivers/gpu/drm/amd/amdgpu portion of the Linux kernel tree.
We also release modified versions of the amdgpu driver in the AMDGPU-PRO and
ROCm driver stacks.
From:
Acked-by: John Bridgman
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Christian König
>Sent: Monday, September 18, 2017 8:34 AM
>To: amd-gfx@lists.freedesktop.org
>Subject: [PATCH] drm/amdgpu: use 2MB fragment size for GFX6,7 and 8
>
>From
For clarity, are you saying that when you go back to whatever distro you had
installed on the machine previously it is still not booting correctly ?
The only problems I see in the xorg log are the following lines at the end, but
not sure if they are serious or not.
[ 205.542] (WW) RADEON(0)
Agreed... one person's "best" is another person's "OMG I didn't want that". IMO
we should have bits correspond to specific options as much as possible, modulo
HW capabilities.
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Xie, AlexBin
>Se
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
>Of Alex Deucher
>Sent: Wednesday, July 12, 2017 11:59 AM
>To: Kuehling, Felix
>Cc: amd-gfx list
>Subject: Re: [PATCH 05/12] drm/amdgpu: Send no-retry XNACK for all fault
>types
>
>On Wed, Jul 12, 2
Agreed... I thought we had already made this change but if not then...
Reviewed-by: John Bridgman
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
>Of Felix Kuehling
>Sent: Wednesday, July 12, 2017 1:41 AM
>To: amd-gfx@lists.freedesktop.org
>Su
IIRC the amdgpu devs had been holding back on publishing the updated MEC
microcode (with scratch support) because that WOULD have broken Kaveri. With
this change from Felix we should be able to publish the newest microcode for
both amdgpu and amdkfd WITHOUT breaking Kaveri.
IOW this is the "scr
If it helps, my recollection was that Intel was also pushing some pre-silicon
support code upstream.
Agree that if the changes get big/messy/invasive we should rethink this, but my
impression is that the changes can be fairly small. There will be one Big
Honkin' function that programs ~10,000 r
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Christian König
>Sent: Monday, February 05, 2018 11:49 AM
>To: Alex Deucher; Liu, Shaoyun
>Cc: amd-gfx list
>Subject: Re: [PATCH] drm/amdgpu: Basic emulation support
>
>Am 05.02.2018 um 17:45 s
e and delete them later or replace a short file with a
20,000 line file and then replace it again later... so maybe we don't need to
move the function out after all.
From: Liu, Shaoyun
Sent: February 6, 2018 4:55 PM
To: Alex Deucher; Bridgman, John
Cc: am
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ming Yang
>Sent: Tuesday, February 13, 2018 4:59 PM
>To: Kuehling, Felix
>Cc: Deucher, Alexander; amd-gfx@lists.freedesktop.org
>Subject: Re: Documentation about AMD's HSA implementation?
>
>Th
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Bridgman, John
>Sent: Tuesday, February 13, 2018 6:42 PM
>To: Ming Yang; Kuehling, Felix
>Cc: Deucher, Alexander; amd-gfx@lists.freedesktop.org
>Subject: RE: Document
If you look about half way down this page under "The latest ROCm platform -
ROCm 1.7" you should see a list of links to component repos. Each of those
component repos has information on building:
https://github.com/RadeonOpenCompute/ROCm
If you have questions or problems building/installing y
>-Original Message-
>From: Ming Yang [mailto:minos.fut...@gmail.com]
>Sent: Saturday, March 17, 2018 12:35 PM
>To: Kuehling, Felix; Bridgman, John
>Cc: amd-gfx@lists.freedesktop.org
>Subject: Re: Documentation about AMD's HSA implementation?
>
>Hi,
>
>Af
I have seen a couple of reports that booting Raven desktop parts requires
disabling DC, although I'm not sure if that actually makes sense (I didn't
think we implemented non-DC display paths for Vega/Raven).
Might be specific to people with a dGPU plugged in, I guess ?
Let's separate out OpenCL from HCC/HIP and the rest of the ROCm stack.
We are working on a solution to deliver OpenCL without requiring atomics, but
not the rest of the ROCm stack.
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Luke A. Gu
Agreed - MEC microcode uses atomics when the queue type is set to AQL (rather
than PM4).
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Liu, Shaoyun
>Sent: Wednesday, January 03, 2018 11:24 AM
>To: tstel...@redhat.com; Felix Kühling; amd-gf
Microcode for the GPU hardware blocks is not permanently updated in the chip,
but rather is loaded at power-up. Usually the files will be distributed via a
package with a name like linux-firmware.
I didn't see a mention of which distro/version you are using but along with new
kernel you will ne
Yes, please file a bugzilla ticket and attach dmesg output.
From: Min Xu [mailto:min.xu.pub...@gmail.com]
Sent: Monday, January 29, 2018 3:04 PM
To: Bridgman, John
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: Strange issue on Vega 8 Mobile (HP Envy x360 Laptop)
Thanks for explaining that
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
>Of Daniel Vetter
>Sent: Thursday, August 04, 2016 1:23 PM
>To: Alex Deucher
>Cc: Deng, Emily; amd-gfx list; Maling list - DRI developers
>Subject: Re: [PATCH 00/13] drm/amdgpu: Add virtual displ
50 matches
Mail list logo
