RE: Change queue/pipe split between amdkfd and amdgpu

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. >

RE: Add support for high priority scheduling in amdgpu

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) +{

RE: AMD and free and open source software

microcode 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

RE: AMD and free and open source software

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

Re: [RFC] Using DC in amdgpu for upcoming GPU

t people can't buy yet. From: Dave Airlie <airl...@gmail.com> 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 Subject: Re:

Re: [RFC] Using DC in amdgpu for upcoming GPU

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.

Re: [RFC] Using DC in amdgpu for upcoming GPU

>>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

Re: [RFC] Mechanism for high priority scheduling in amdgpu

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

Re: [RFC] Mechanism for high priority scheduling in amdgpu

written. I'll try to dig up some history for that and ask around internally as well. From: Andres Rodriguez <andre...@gmail.com> Sent: December 23, 2016 11:30 AM To: Bridgman, John Cc: Koenig, Christian; Zhou, David(ChunMing); Huan, Alvin; Mao, David; Sagalovitch, Serguei; a

Re: [pull] radeon drm-fixes-4.11

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

RE: [PATCH 16/19] drm/amdkfd: Update PM4 packet headers

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

RE: [PATCH 05/12] drm/amdgpu: Send no-retry XNACK for all fault types

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:

RE: [PATCH 05/12] drm/amdgpu: Send no-retry XNACK for all fault types

>-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,

RE: [PATCH 3/3] drm/amdgpu: Add kernel parameter to control use of ECC/EDC.

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

RE: What is the relationship between amd-gfx and kernel?

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:

RE: [PATCH] drm/amdgpu: use 2MB fragment size for GFX6,7 and 8

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

RE: Did my graphics card get damaged?

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)

RE: PCIe3 atomics requirement for amdkfd

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.

RE: Strange issue on Vega 8 Mobile (HP Envy x360 Laptop)

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

RE: Strange issue on Vega 8 Mobile (HP Envy x360 Laptop)

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

RE: [PATCH 1/2] drm/amdgpu: Set module parameter for emulation

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

RE: [PATCH] drm/amdgpu: Basic emulation support

>-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

Re: [PATCH] drm/amdgpu: Add place holder for soc15 asic init on emulation

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: amd-gfx list

RE: Documentation about AMD's HSA implementation?

>-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

RE: Documentation about AMD's HSA implementation?

>-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? >

RE: PCIe3 atomics requirement for amdkfd

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;

Re: SOC15 DC support warning

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 ?

Re: ROCm installation from source

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

RE: Documentation about AMD's HSA implementation?

>-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, > >After d

Re: amdkfd build regression if HSA_AMD is disabled

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;

Re: [PATCH] drm/amdgpu: Set VM_L2_CNTL.PDE_FAULT_CLASSIFICATION to 0

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

Re: [PATCH] drm/amdgpu: Set VM_L2_CNTL.PDE_FAULT_CLASSIFICATION to 0

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

Re: Irc and Other Things

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

Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services

[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

Re: writing custom driver for VGA emulation ?

[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

Re: writing custom driver for VGA emulation ?

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, John ; Alex D

Re: Possibility of RX570 responsible for spontaneous reboots (MCE) with Ryzen 3700x?

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 - Internal

Re: Possibility of RX570 responsible for spontaneous reboots (MCE) with Ryzen 3700x?

[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

Re: Possibility of RX570 responsible for spontaneous reboots (MCE) with Ryzen 3700x?

[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

Re: Possibility of RX570 responsible for spontaneous reboots (MCE) with Ryzen 3700x?

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 bit strang

Re: slow rx 5600 xt fps

[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

Re: Enabling AMDGPU by default for SI & CIK

[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

Re: [bug] Radeon 3900XT not switch to graphic mode on kernel 5.10

[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--

Re: [amdkfd] where are AQL packets processed after writing the userspace doorbell

[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

Re: [amdgpu] deadlock

‎>>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