Re: [PATCH 1/3] drm/amdgpu: fix a typo

On 2017年06月28日 04:50, Bas Nieuwenhuizen wrote: On Tue, Jun 27, 2017 at 10:40 PM, Dave Airlie wrote: On 26 June 2017 at 19:10, zhoucm1 wrote: On 2017年06月26日 03:48, Dave Airlie wrote: Do you not use bo list at all in mesa? radv as well? Currently

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On Tue, Jun 27, 2017 at 10:40 PM, Dave Airlie wrote: > On 26 June 2017 at 19:10, zhoucm1 wrote: >> >> >> On 2017年06月26日 03:48, Dave Airlie wrote: Do you not use bo list at all in mesa? radv as well? >>> >>> Currently radv is creating a bo list

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On 26 June 2017 at 19:10, zhoucm1 wrote: > > > On 2017年06月26日 03:48, Dave Airlie wrote: >>> >>> Do you not use bo list at all in mesa? radv as well? >> >> Currently radv is creating a bo list per command submission. radv does >> not use an offload thread to do command

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On 2017年06月26日 03:48, Dave Airlie wrote: Do you not use bo list at all in mesa? radv as well? Currently radv is creating a bo list per command submission. radv does not use an offload thread to do command submission, as it seems pretty un-vulkan to use a thread for the queue submission thread

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On 23/06/17 07:49 PM, Marek Olšák wrote: > On Fri, Jun 23, 2017 at 11:27 AM, Christian König > wrote: >> Am 23.06.2017 um 11:08 schrieb zhoucm1: >>> On 2017年06月23日 17:01, zhoucm1 wrote: On 2017年06月23日 16:25, Christian König wrote: > Am 23.06.2017 um 09:09 schrieb

Re: [PATCH 1/3] drm/amdgpu: fix a typo

> Do you not use bo list at all in mesa? radv as well? Currently radv is creating a bo list per command submission. radv does not use an offload thread to do command submission, as it seems pretty un-vulkan to use a thread for the queue submission thread the game uses. I have considered

Re: [PATCH 1/3] drm/amdgpu: fix a typo

Am 24.06.2017 um 02:27 schrieb Marek Olšák: On Fri, Jun 23, 2017 at 3:01 PM, Christian König wrote: The key point here is while optimizing this is nice the much bigger pile is the locking done for each BO. In other words even when we optimize all the other locks

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On Fri, Jun 23, 2017 at 3:45 PM, axie wrote: > Hi Marek, > > I understand you spent time on your original logic too. I really don't > understand why you talked about pain if somebody can improve it. > > To reduce the pain, now I am seriously considering dropping this patch. But >

Re: [PATCH 1/3] drm/amdgpu: fix a typo

); Xie, AlexBin; amd-gfx@lists.freedesktop.org; Xie, > AlexBin > Subject: Re: [PATCH 1/3] drm/amdgpu: fix a typo > > On Fri, Jun 23, 2017 at 11:27 AM, Christian König > <deathsim...@vodafone.de> wrote: >> Am 23.06.2017 um 11:08 schrieb zhoucm1: >>> >>> >>> >

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On Fri, Jun 23, 2017 at 3:01 PM, Christian König wrote: > The key point here is while optimizing this is nice the much bigger pile is > the locking done for each BO. > > In other words even when we optimize all the other locks involved into > atomics or RCU, the BO

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On the other hand, after you optimize the BO reservation lock, other locks still need optimization, right? In theory yes, in practice no. There are just way other things we should tackle before taking care of removing any locks that we probably never get to that point even with more

Re: [PATCH 1/3] drm/amdgpu: fix a typo

Hi Christian, I agree with you. On the other hand, after you optimize the BO reservation lock, other locks still need optimization, right? 1. Locking itself is not cheap. 2. Waiting in lock is even more expensive. Thanks, Alex Bin Xie On 2017-06-23 09:01 AM, Christian König wrote: The

Re: [PATCH 1/3] drm/amdgpu: fix a typo

Hi Marek, I understand you spent time on your original logic too. I really don't understand why you talked about pain if somebody can improve it. To reduce the pain, now I am seriously considering dropping this patch. But please read on before you conclude. Let us treat open source software

Re: [PATCH 1/3] drm/amdgpu: fix a typo

The key point here is while optimizing this is nice the much bigger pile is the locking done for each BO. In other words even when we optimize all the other locks involved into atomics or RCU, the BO reservation lock will still dominate everything. One possible solution to this would be per

RE: [PATCH 1/3] drm/amdgpu: fix a typo

From: Marek Olšák [mar...@gmail.com] Sent: Friday, June 23, 2017 6:49 PM To: Christian König Cc: Zhou, David(ChunMing); Xie, AlexBin; amd-gfx@lists.freedesktop.org; Xie, AlexBin Subject: Re: [PATCH 1/3] drm/amdgpu: fix a typo On Fri, Jun 23, 2017 at 11

Re: [PATCH 1/3] drm/amdgpu: fix a typo

I agree with you about the spinlock. You seem to be good at this. It's always good to do measurements to validate that a code change improves something, especially when the code size and code complexity has to be increased. A CPU profiler such as sysprof can show you improvements on the order of

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On Fri, Jun 23, 2017 at 11:27 AM, Christian König wrote: > Am 23.06.2017 um 11:08 schrieb zhoucm1: >> >> >> >> On 2017年06月23日 17:01, zhoucm1 wrote: >>> >>> >>> >>> On 2017年06月23日 16:25, Christian König wrote: Am 23.06.2017 um 09:09 schrieb zhoucm1: > >

Re: [PATCH 1/3] drm/amdgpu: fix a typo

Am 23.06.2017 um 11:08 schrieb zhoucm1: On 2017年06月23日 17:01, zhoucm1 wrote: On 2017年06月23日 16:25, Christian König wrote: Am 23.06.2017 um 09:09 schrieb zhoucm1: On 2017年06月23日 14:57, Christian König wrote: But giving the CS IOCTL an option for directly specifying the BOs instead of a

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On 2017年06月23日 17:01, zhoucm1 wrote: On 2017年06月23日 16:25, Christian König wrote: Am 23.06.2017 um 09:09 schrieb zhoucm1: On 2017年06月23日 14:57, Christian König wrote: But giving the CS IOCTL an option for directly specifying the BOs instead of a BO list like Marek suggested would indeed

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On 2017年06月23日 16:25, Christian König wrote: Am 23.06.2017 um 09:09 schrieb zhoucm1: On 2017年06月23日 14:57, Christian König wrote: But giving the CS IOCTL an option for directly specifying the BOs instead of a BO list like Marek suggested would indeed save us some time here. interesting,

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On 2017年06月23日 16:25, Christian König wrote: Am 23.06.2017 um 09:09 schrieb zhoucm1: On 2017年06月23日 14:57, Christian König wrote: But giving the CS IOCTL an option for directly specifying the BOs instead of a BO list like Marek suggested would indeed save us some time here. interesting,

Re: [PATCH 1/3] drm/amdgpu: fix a typo

Am 23.06.2017 um 09:09 schrieb zhoucm1: On 2017年06月23日 14:57, Christian König wrote: But giving the CS IOCTL an option for directly specifying the BOs instead of a BO list like Marek suggested would indeed save us some time here. interesting, I always follow how to improve our cs ioctl,

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On 2017年06月23日 14:57, Christian König wrote: But giving the CS IOCTL an option for directly specifying the BOs instead of a BO list like Marek suggested would indeed save us some time here. interesting, I always follow how to improve our cs ioctl, since UMD guys aften complain our command

Re: [PATCH 1/3] drm/amdgpu: fix a typo

Hi Alex, actually Marek is right, command submission is actually not much of a bottleneck to us because it is handled from a separate userspace thread. So those micro optimizations you do here on CPU cycles are actually rather superfluous. But giving the CS IOCTL an option for directly

Re: [PATCH 1/3] drm/amdgpu: fix a typo

Hi Marek, So do you agree that spinlock disables CPU preemption, contrary to your original idea? If you have new reason that this patch does not improve, please speak out. Many patches in GPU driver aim at improving performance and power efficiency. Does most patches submitted in AMDGPU

Re: [PATCH 1/3] drm/amdgpu: fix a typo

That's all nice, but does it improve performance? Have you been able to measure some performance difference with that code? Were you targeting a specific inefficiency you had seen e.g. with a CPU profiler? Marek On Thu, Jun 22, 2017 at 8:19 PM, axie wrote: > To clarify, local IRQ

Re: [PATCH 1/3] drm/amdgpu: fix a typo

Hi Marek, Spin lock and spin unlock is fast. But it is not so fast compared with atomic, which is a single CPU instruction in x86. 1. spinlock does NOT allow preemption at local CPU. Let us have a look at how spin lock was implemented. static inline void __raw_spin_lock(raw_spinlock_t

Re: [PATCH 1/3] drm/amdgpu: fix a typo

On Thu, Jun 22, 2017 at 5:33 PM, Xie, AlexBin wrote: > Hi Christian, > > > In fact, the change from spinlock to atomic is quite painful. When I > started, I thought it was easy but later I found there might be race > condition here and there. Now I think the change looks more

Re: [PATCH 1/3] drm/amdgpu: fix a typo

t:* Re: [PATCH 1/3] drm/amdgpu: fix a typo Am 22.06.2017 um 04:42 schrieb Alex Xie: > Signed-off-by: Alex Xie <alexbin@amd.com> With the commit message fixed as Michel suggested patches #1 and #2 are Reviewed-by: Christian König <christian.koe...@amd.com> as well. On patch #3 Marek

Re: [PATCH 1/3] drm/amdgpu: fix a typo

md-gfx@lists.freedesktop.org Subject: Re: [PATCH 1/3] drm/amdgpu: fix a typo Am 22.06.2017 um 04:42 schrieb Alex Xie: > Signed-off-by: Alex Xie <alexbin@amd.com> With the commit message fixed as Michel suggested patches #1 and #2 are Reviewed-by: Christian König <christian.koe...@amd.com>

Re: [PATCH 1/3] drm/amdgpu: fix a typo

Am 22.06.2017 um 04:42 schrieb Alex Xie: Signed-off-by: Alex Xie With the commit message fixed as Michel suggested patches #1 and #2 are Reviewed-by: Christian König as well. On patch #3 Marek needs to take a look, cause I don't know the