Re: Forcing device loss for debugging

Under the sysfs directory for each PCI device you should have a virtual file called "remove". So if you just do an "echo 1 > /sys/devices/pci/remove" you basically simulate hot unplugging the specific PCI device IIRC the PCI bridge where the device is connected to should then have a

Re: Unit and performance tests for VA-API

Since nobody replied to this in a month I'm explicitly adding Leo to comment. Christian. Am 22.05.23 um 22:01 schrieb Shashank Sharma: Respected sir/mam. I am a 4th year student of National Institute of Technology, Silchar in India. I am currently looking for a summer internship. I read

Re: Regarding project in X.Org Endless Vacation of Code programs

Hi Tushar, Leo is the lead from our multimedia team and should be able to help you with that. Cheers, Christian. Am 18.02.23 um 16:19 schrieb Tushar Gupta: Hello, I am software developer proficient in C++ and python  and interested for contributing to "Unit and Performance test for

Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi

Am 27.04.22 um 17:02 schrieb Matthew Auld: On 27/04/2022 07:55, Christian König wrote: Well usually we increment the drm minor version when adding some new flags on amdgpu. Additional to that just one comment from our experience with that: You don't just need one flag, but two. The first one

Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi

Well usually we increment the drm minor version when adding some new flags on amdgpu. Additional to that just one comment from our experience with that: You don't just need one flag, but two. The first one is a hint which says "CPU access needed" and the second is a promise which says "CPU

Re: [Mesa-dev] Enabling Mesa video frontends on top of D3D12 gallium driver

Hi guys, Am 22.11.21 um 06:49 schrieb Dave Airlie: On Thu, 18 Nov 2021 at 18:45, Sil Vilerino wrote: Hello mesa-dev community, We are starting to work on adding support for D3D12 Video acceleration in the mesa gallium D3D12 driver so that mesa frontends such as VA, VDPAU, etc can

Re: [Mesa-dev] llvmpipe not supporting EGL_EXT_image_dma_buf_import ?

Am 29.10.21 um 11:35 schrieb Michel Dänzer: On 2021-10-28 14:02, Christian König wrote: Well I'm not an expert on llvmpipe, but as far as I know that's a general problem. DMA-buf is used by the Linux kernel drivers to pass hardware bufefrs between processes and drivers. Since llvmpipe

Re: [Mesa-dev] llvmpipe not supporting EGL_EXT_image_dma_buf_import ?

Well I'm not an expert on llvmpipe, but as far as I know that's a general problem. DMA-buf is used by the Linux kernel drivers to pass hardware bufefrs between processes and drivers. Since llvmpipe as a software renderer it has no kernel driver, so there is no easy way to implement that.

Re: [Mesa-dev] Question about display_gpu and render gpu in dri3_create_screen

Mhm, that looks like it's something I should look into. How exactly are you triggering this and which kernel version are you using? Thanks, Christian. Am 14.09.21 um 03:47 schrieb Luc Ma: Yes, I did. It crashed the kernel as follows Sep 14 09:12:34 kernel: [  506.676925][ 4] [ T1045]

Re: [Mesa-dev] [PATCH 15/15] RFC: drm/amdgpu: Implement a proper implicit fencing uapi

Am 23.06.21 um 17:12 schrieb Daniel Vetter: On Wed, Jun 23, 2021 at 05:07:17PM +0200, Christian König wrote: Am 23.06.21 um 17:03 schrieb Daniel Vetter: On Wed, Jun 23, 2021 at 04:58:27PM +0200, Bas Nieuwenhuizen wrote: On Wed, Jun 23, 2021 at 4:50 PM Daniel Vetter wrote: On Wed, Jun 23

Re: [Mesa-dev] [PATCH 15/15] RFC: drm/amdgpu: Implement a proper implicit fencing uapi

Am 23.06.21 um 17:03 schrieb Daniel Vetter: On Wed, Jun 23, 2021 at 04:58:27PM +0200, Bas Nieuwenhuizen wrote: On Wed, Jun 23, 2021 at 4:50 PM Daniel Vetter wrote: On Wed, Jun 23, 2021 at 4:02 PM Christian König wrote: Am 23.06.21 um 15:49 schrieb Daniel Vetter: On Wed, Jun 23, 2021 at 3

Re: [Mesa-dev] [PATCH 15/15] RFC: drm/amdgpu: Implement a proper implicit fencing uapi

Am 23.06.21 um 15:49 schrieb Daniel Vetter: On Wed, Jun 23, 2021 at 3:44 PM Christian König wrote: Am 23.06.21 um 15:38 schrieb Bas Nieuwenhuizen: On Wed, Jun 23, 2021 at 2:59 PM Christian König wrote: Am 23.06.21 um 14:18 schrieb Daniel Vetter: On Wed, Jun 23, 2021 at 11:45 AM Bas

Re: [Mesa-dev] [PATCH 15/15] RFC: drm/amdgpu: Implement a proper implicit fencing uapi

Am 23.06.21 um 15:38 schrieb Bas Nieuwenhuizen: On Wed, Jun 23, 2021 at 2:59 PM Christian König wrote: Am 23.06.21 um 14:18 schrieb Daniel Vetter: On Wed, Jun 23, 2021 at 11:45 AM Bas Nieuwenhuizen wrote: On Tue, Jun 22, 2021 at 6:55 PM Daniel Vetter wrote: WARNING: Absolutely untested

Re: [Mesa-dev] [PATCH 15/15] RFC: drm/amdgpu: Implement a proper implicit fencing uapi

Cc: Michel Dänzer Cc: Daniel Stone Cc: Sumit Semwal Cc: "Christian König" Cc: Alex Deucher Cc: Daniel Vetter Cc: Deepak R Varma Cc: Chen Li Cc: Kevin Wang Cc: Dennis Li Cc: Luben Tuikov Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Daniel Vetter --- drivers/gpu/

Re: [Mesa-dev] [PATCH 03/15] dma-buf: Document dma-buf implicit fencing/resv fencing rules

t dma_resv started there I hope they get this right. In conclusion this IS the contract, both as documented and overwhelmingly implemented, specically as implemented by all render drivers except amdgpu. Amdgpu tried to fix this already in commit 049aca4363d8af87cab8d53de5401602db3b Author: C

Re: [Mesa-dev] [PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)

Am 18.06.21 um 20:45 schrieb Daniel Vetter: On Fri, Jun 18, 2021 at 8:02 PM Christian König wrote: Am 18.06.21 um 19:20 schrieb Daniel Vetter: [SNIP] The whole thing was introduced with this commit here: commit f2c24b83ae90292d315aa7ac029c6ce7929e01aa Author: Maarten Lankhorst Date: Wed

Re: [Mesa-dev] [PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)

y time + ‘weight’ and flattened whenever modified? Something else? Have a great weekend. -d On 18 Jun 2021, at 5:43 pm, Christian König wrote: Am 18.06.21 um 17:17 schrieb Daniel Vetter: [SNIP] Ignoring _all_ fences is officially ok for pinned dma-buf. This is what v4l does. Aside from it's def

Re: [Mesa-dev] [PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)

Am 18.06.21 um 19:20 schrieb Daniel Vetter: On Fri, Jun 18, 2021 at 6:43 PM Christian König wrote: Am 18.06.21 um 17:17 schrieb Daniel Vetter: [SNIP] Ignoring _all_ fences is officially ok for pinned dma-buf. This is what v4l does. Aside from it's definitely not just i915 that does this even

Re: [Mesa-dev] [PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)

Am 18.06.21 um 17:17 schrieb Daniel Vetter: [SNIP] Ignoring _all_ fences is officially ok for pinned dma-buf. This is what v4l does. Aside from it's definitely not just i915 that does this even on the drm side, we have a few more drivers nowadays. No it seriously isn't. If drivers are doing

Re: [Mesa-dev] [PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)

FC status v11 (Daniel Vetter): - Add more CCs to try and get maintainers - Add a patch to document DMA_BUF_IOCTL_SYNC - Generally better docs - Use separate structs for import/export (easier to document) - Fix an issue in the import patch v12 (Daniel Vetter):

Re: [Mesa-dev] [PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)

Am 17.06.21 um 21:58 schrieb Daniel Vetter: On Thu, Jun 17, 2021 at 09:37:36AM +0200, Christian König wrote: [SNIP] But, to the broader point, maybe? I'm a little fuzzy on exactly where i915 inserts and/or depends on fences. When you combine that with complex drivers which use TTM

Re: [Mesa-dev] [PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)

Am 16.06.21 um 20:30 schrieb Jason Ekstrand: On Tue, Jun 15, 2021 at 3:41 AM Christian König wrote: Hi Jason & Daniel, maybe I should explain once more where the problem with this approach is and why I think we need to get that fixed before we can do something like this here. To summa

Re: [Mesa-dev] [PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)

lly better docs - Use separate structs for import/export (easier to document) - Fix an issue in the import patch v12 (Daniel Vetter): - Better docs for DMA_BUF_IOCTL_SYNC v12 (Christian König): - Drop the rename patch in favor of Christian's series - Add a comment to the commit message f

Re: [Mesa-dev] Linux Graphics Next: Userspace submission update

Christian König <mailto:ckoenig.leichtzumer...@gmail.com>> wrote: Hi guys, maybe soften that a bit. Reading from the shared memory of the user fence is ok for everybody. What we need to take more care of is the writing side. So my current thinking is that we allow

Re: [Mesa-dev] Linux Graphics Next: Userspace submission update

at 03:58:26PM +0200, Christian König wrote: > Am 09.06.21 um 15:19 schrieb Daniel Vetter: > > [SNIP] > > > Yeah, we call this the lightweight and the heavyweight tlb flush. > > > > > > The lighweight can be used when you are sure that

Re: [Mesa-dev] Linux Graphics Next: Userspace submission update

Am 09.06.21 um 15:19 schrieb Daniel Vetter: [SNIP] Yeah, we call this the lightweight and the heavyweight tlb flush. The lighweight can be used when you are sure that you don't have any of the PTEs currently in flight in the 3D/DMA engine and you just need to invalidate the TLB. The

Re: [Mesa-dev] Linux Graphics Next: Userspace submission update

Am 04.06.21 um 10:57 schrieb Daniel Vetter: On Fri, Jun 04, 2021 at 09:00:31AM +0200, Christian König wrote: Am 02.06.21 um 21:19 schrieb Daniel Vetter: On Wed, Jun 02, 2021 at 08:52:38PM +0200, Christian König wrote: Am 02.06.21 um 20:48 schrieb Daniel Vetter: On Wed, Jun 02, 2021 at 05:38

Re: [Mesa-dev] Linux Graphics Next: Userspace submission update

Am 02.06.21 um 21:19 schrieb Daniel Vetter: On Wed, Jun 02, 2021 at 08:52:38PM +0200, Christian König wrote: Am 02.06.21 um 20:48 schrieb Daniel Vetter: On Wed, Jun 02, 2021 at 05:38:51AM -0400, Marek Olšák wrote: On Wed, Jun 2, 2021 at 5:34 AM Marek Olšák wrote: Yes, we can't break

Re: [Mesa-dev] Linux Graphics Next: Userspace submission update

Am 02.06.21 um 20:48 schrieb Daniel Vetter: On Wed, Jun 02, 2021 at 05:38:51AM -0400, Marek Olšák wrote: On Wed, Jun 2, 2021 at 5:34 AM Marek Olšák wrote: Yes, we can't break anything because we don't want to complicate things for us. It's pretty much all NAK'd already. We are trying to

Re: [Mesa-dev] Linux Graphics Next: Userspace submission update

Am 02.06.21 um 11:58 schrieb Marek Olšák: On Wed, Jun 2, 2021 at 5:44 AM Christian König <mailto:ckoenig.leichtzumer...@gmail.com>> wrote: Am 02.06.21 um 10:57 schrieb Daniel Stone: > Hi Christian, > > On Tue, 1 Jun 2021 at 13:5

Re: [Mesa-dev] Linux Graphics Next: Userspace submission update

Am 02.06.21 um 10:57 schrieb Daniel Stone: Hi Christian, On Tue, 1 Jun 2021 at 13:51, Christian König wrote: Am 01.06.21 um 14:30 schrieb Daniel Vetter: If you want to enable this use-case with driver magic and without the compositor being aware of what's going on, the solution is EGLStreams

Re: [Mesa-dev] Linux Graphics Next: Userspace submission update

Am 01.06.21 um 14:30 schrieb Daniel Vetter: On Tue, Jun 1, 2021 at 2:10 PM Christian König wrote: Am 01.06.21 um 12:49 schrieb Michel Dänzer: On 2021-06-01 12:21 p.m., Christian König wrote: Am 01.06.21 um 11:02 schrieb Michel Dänzer: On 2021-05-27 11:51 p.m., Marek Olšák wrote: 3

Re: [Mesa-dev] Linux Graphics Next: Userspace submission update

Am 01.06.21 um 12:49 schrieb Michel Dänzer: On 2021-06-01 12:21 p.m., Christian König wrote: Am 01.06.21 um 11:02 schrieb Michel Dänzer: On 2021-05-27 11:51 p.m., Marek Olšák wrote: 3) Compositors (and other privileged processes, and display flipping) can't trust imported/exported fences

Re: [Mesa-dev] Linux Graphics Next: Userspace submission update

Am 01.06.21 um 11:02 schrieb Michel Dänzer: On 2021-05-27 11:51 p.m., Marek Olšák wrote: 3) Compositors (and other privileged processes, and display flipping) can't trust imported/exported fences. They need a timeout recovery mechanism from the beginning, and the following are some possible

Re: [Mesa-dev] Linux Graphics Next: Userspace submission update

021 at 10:41 AM Christian König mailto:ckoenig.leichtzumer...@gmail.com>> wrote: Hi Marek, well I don't think that implicit and explicit synchronization needs to be mutual exclusive. What we should do is to have the ability to transport an synchro

Re: [Mesa-dev] Linux Graphics Next: Userspace submission update

Hi Marek, well I don't think that implicit and explicit synchronization needs to be mutual exclusive. What we should do is to have the ability to transport an synchronization object with each BO. Implicit and explicit synchronization then basically become the same, they just transport the

Re: [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules

Am 25.05.21 um 17:23 schrieb Daniel Vetter: On Tue, May 25, 2021 at 5:05 PM Christian König wrote: Hi Daniel, Am 25.05.21 um 15:05 schrieb Daniel Vetter: Hi Christian, On Sat, May 22, 2021 at 10:30:19AM +0200, Christian König wrote: Am 21.05.21 um 20:31 schrieb Daniel Vetter: This works

Re: [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules

Hi Daniel, Am 25.05.21 um 15:05 schrieb Daniel Vetter: Hi Christian, On Sat, May 22, 2021 at 10:30:19AM +0200, Christian König wrote: Am 21.05.21 um 20:31 schrieb Daniel Vetter: [SNIP] We could provide an IOCTL for the BO to change the flag. That's not the semantics we need. But could we

Re: [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules

Am 21.05.21 um 20:31 schrieb Daniel Vetter: [SNIP] We could provide an IOCTL for the BO to change the flag. That's not the semantics we need. But could we first figure out the semantics we want to use here? Cause I'm pretty sure we don't actually need those changes at all and as said before

Re: [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules

Am 21.05.21 um 17:16 schrieb Daniel Vetter: On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote: On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote: On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote: On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote: ---

Re: [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules

t dma_resv started there I hope they get this right. In conclusion this IS the contract, both as documented and overwhelmingly implemented, specically as implemented by all render drivers except amdgpu. Amdgpu tried to fix this already in commit 049aca4363d8af87cab8d53de5401602db3b Author: C

Re: [Mesa-dev] [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

Am 20.05.21 um 23:38 schrieb Jason Ekstrand: On Thu, May 20, 2021 at 10:46 AM Matthew Brost wrote: On Thu, May 20, 2021 at 01:11:59PM +0200, Christian König wrote: Am 19.05.21 um 18:51 schrieb Matthew Brost: On Wed, May 19, 2021 at 01:45:39PM +0200, Christian König wrote: Oh, yeah we call

Re: [Mesa-dev] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

Am 19.05.21 um 18:51 schrieb Matthew Brost: On Wed, May 19, 2021 at 01:45:39PM +0200, Christian König wrote: Oh, yeah we call that gang submit on the AMD side. Had already some internal discussions how to implement this, but so far couldn't figure out how to cleanly introduce that into the DRM

Re: [Mesa-dev] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

Oh, yeah we call that gang submit on the AMD side. Had already some internal discussions how to implement this, but so far couldn't figure out how to cleanly introduce that into the DRM scheduler. Can you briefly describe in a few words how that is supposed to work on the Intel side?

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 04.05.21 um 13:13 schrieb Daniel Vetter: On Tue, May 4, 2021 at 12:53 PM Christian König wrote: Am 04.05.21 um 11:47 schrieb Daniel Vetter: [SNIP] Yeah, it just takes to long for the preemption to complete to be really useful for the feature we are discussing here. As I said when

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 04.05.21 um 11:47 schrieb Daniel Vetter: [SNIP] Yeah, it just takes to long for the preemption to complete to be really useful for the feature we are discussing here. As I said when the kernel requests to preempt a queue we can easily expect a timeout of ~100ms until that comes back. For

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 04.05.21 um 10:27 schrieb Daniel Vetter: On Tue, May 4, 2021 at 10:09 AM Christian König wrote: Am 04.05.21 um 09:32 schrieb Daniel Vetter: On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote: Unfortunately as I pointed out to Daniel as well this won't work 100% reliable

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 04.05.21 um 09:32 schrieb Daniel Vetter: On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote: Unfortunately as I pointed out to Daniel as well this won't work 100% reliable either. You're claiming this, but there's no clear reason why really, and you did't reply to my last mail

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

ailto:alexdeuc...@gmail.com>> wrote: > > > > > > On Sat, May 1, 2021 at 6:27 PM Marek Olšák mailto:mar...@gmail.com>> wrote: > > > > > > > > On Wed, Apr 28, 2021 at 5:07 AM Michel Dänzer mailto:mic...@daenzer.net>> wro

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

:27 PM Marek Olšák wrote: On Wed, Apr 28, 2021 at 5:07 AM Michel Dänzer wrote: On 2021-04-28 8:59 a.m., Christian König wrote: Hi Dave, Am 27.04.21 um 21:23 schrieb Marek Olšák: Supporting interop with any device is always possible. It depends on which drivers we need to interoperate

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 30.04.21 um 10:58 schrieb Daniel Vetter: [SNIP] When the user allocates usermode queues, the kernel driver sets up a queue descriptor in the kernel which defines the location of the queue in memory, what priority it has, what page tables it should use, etc. User mode can then start writing

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 28.04.21 um 16:34 schrieb Daniel Vetter: On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote: Am 28.04.21 um 15:34 schrieb Daniel Vetter: On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote: Am 28.04.21 um 14:26 schrieb Daniel Vetter: On Wed, Apr 28, 2021 at 02:21

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 28.04.21 um 15:34 schrieb Daniel Vetter: On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote: Am 28.04.21 um 14:26 schrieb Daniel Vetter: On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote: On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote: Am 28.04.21

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 28.04.21 um 14:26 schrieb Daniel Vetter: On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote: On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote: Am 28.04.21 um 12:05 schrieb Daniel Vetter: On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote: On Tue, Apr 27

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 28.04.21 um 12:05 schrieb Daniel Vetter: On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote: On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote: On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach wrote: Ok. So that would only make the following use cases broken for now: - amd

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

to be updated and evaluate the cost/benefit aspect. Marek On Tue, Apr 27, 2021 at 2:38 PM Dave Airlie <mailto:airl...@gmail.com>> wrote: On Tue, 27 Apr 2021 at 22:06, Christian König mailto:ckoenig.leichtzumer...@gmail.com>> wrote: > > Correct, we wouldn't have sy

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

"external -> amd" into "external <-> amd"? Marek On Tue., Apr. 27, 2021, 08:50 Christian König, <mailto:ckoenig.leichtzumer...@gmail.com>> wrote: Only amd -> external. We can easily install something in an user queue which waits for a dma_fence

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

e, maybe we should avoid a repeat of this ... -Daniel > > Marek > > On Tue., Apr. 27, 2021, 08:06 Christian König, mailto:ckoenig.leichtzumer...@gmail.com>> wrote: >> >> Correct, we wouldn't have synchronization between device with and w

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

r" fences which don't participate in the implicit sync here. Christian. -Daniel Marek On Tue., Apr. 27, 2021, 08:06 Christian König, wrote: Correct, we wouldn't have synchronization between device with and without user queues any more. That could only be a problem for A+I Laptops

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Correct, we wouldn't have synchronization between device with and without user queues any more. That could only be a problem for A+I Laptops. Memory management will just work with preemption fences which pause the user queues of a process before evicting something. That will be a dma_fence,

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 20.04.21 um 19:44 schrieb Daniel Stone: Hi, On Tue, 20 Apr 2021 at 16:46, Jason Ekstrand > wrote: It's still early in the morning here and I'm not awake yet so sorry if this comes out in bits and pieces... No problem, it's helpful. If I weren't on

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 20.04.21 um 17:07 schrieb Daniel Stone: On Tue, 20 Apr 2021 at 15:58, Christian König <mailto:ckoenig.leichtzumer...@gmail.com>> wrote: Am 20.04.21 um 16:53 schrieb Daniel Stone: On Mon, 19 Apr 2021 at 11:48, Marek Olšák mailto:mar...@gmail.com>> wrote:

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 20.04.21 um 16:53 schrieb Daniel Stone: Hi, On Mon, 19 Apr 2021 at 11:48, Marek Olšák > wrote: Deadlock mitigation to recover from segfaults: - The kernel knows which process is obliged to signal which fence. This information is part of the Present

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi Daniel, Am 20.04.21 um 14:01 schrieb Daniel Vetter: On Mon, Apr 19, 2021 at 06:47:48AM -0400, Marek Olšák wrote: Hi, This is our initial proposal for explicit fences everywhere and new memory management that doesn't use BO fences. It's a redesign of how Linux graphics drivers work, and it

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Apr 20, 2021 at 6:34 AM Daniel Vetter wrote: On Tue, Apr 20, 2021 at 12:15 PM Christian König wrote: Am 19.04.21 um 17:48 schrieb Jason Ekstrand: Not going to comment on everything on the first pass... On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote: Hi, This is our initial proposal for ex

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 19.04.21 um 17:48 schrieb Jason Ekstrand: Not going to comment on everything on the first pass... On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote: Hi, This is our initial proposal for explicit fences everywhere and new memory management that doesn't use BO fences. It's a redesign of

Re: [Mesa-dev] Dmabuf based render buffers!?

Am 15.01.21 um 11:26 schrieb Michel Dänzer: On 2021-01-14 8:02 p.m., Blueroom wrote: Hi Everyone! I have a program that’s using dmabuf’s to create a zero copy camera->GL texture pipeline and it’s working great on my RPi4. Now as a last step I want to access the pixels that Iv’e processed

Re: [Mesa-dev] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup on Radeon HD6320

. On Mon, Dec 2, 2019 at 9:16 AM Christian König mailto:christian.koe...@amd.com>> wrote: The reason we had to switch to VDPAU with Ubuntu 16.04 is that we saw a major regression with mpeg2 playback using va-api. What regression was that? The difference between VDPAU and

Re: [Mesa-dev] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup on Radeon HD6320

ask anyway. We are more than welcome to work together on this, especially since the hardware is older and probably hard to find. Just needing to find a solution so we can move forward on upgrading the software and on these older hardware. On Thu, Nov 28, 2019 at 7:15 AM Christian König

Re: [Mesa-dev] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup on Radeon HD6320

Hi Will, well that's the very first APU generation and unfortunately nobody is working on that old hardware any more. MPEG2 is known to not be fully supported by that chipset in general. So the best approach is probably to not use hardware acceleration for MPEG2 clips in general. Regards,

Re: [Mesa-dev] [PATCH] pipe-loader: use radeonsi for MM if amdgpu dri is used

Am 15.07.19 um 16:15 schrieb Michel Dänzer: On 2019-07-15 4:11 p.m., Newton, Jeremy wrote: Sorry about that, I've only used git email maybe three times in my life :) Nothing to apologize for, everybody has to learn that kind of thing. :) To be honest even after more than a decade I still get

Re: [Mesa-dev] [PATCH] radeonsi: Expose support for 10-bit VP9 decode

Vishwakarma Reviewed-by: Christian König --- src/gallium/drivers/radeonsi/si_get.c | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/drivers/radeonsi/si_get.c b/src/gallium/drivers/radeonsi/si_get.c index 4e23d283ab7..8cc5933f9bc 100644 --- a/src/gallium/drivers/radeonsi/si_get.c

Re: [Mesa-dev] [PATCH] radv: Change memory type order for GPUs without dedicated VRAM

Am 10.06.19 um 15:56 schrieb Bas Nieuwenhuizen: On Sat, Jun 8, 2019 at 3:36 PM Alex Smith wrote: On Mon, 3 Jun 2019 at 13:27, Koenig, Christian wrote: Am 03.06.19 um 14:21 schrieb Alex Smith: On Mon, 3 Jun 2019 at 11:57, Koenig, Christian wrote: Am 02.06.19 um 12:32 schrieb Alex Smith:

Re: [Mesa-dev] [PATCH] radeon/uvd: fix poc for hevc encode

It would be better to have those checks in the state tracker than in the backend code. Christian. Am 27.05.19 um 20:41 schrieb boyuan.zh...@amd.com: From: Boyuan Zhang MaxPicOrderCntLsb should be at 16 according to the spec, therefore add minimum value check. Also use poc value passed from

Re: [Mesa-dev] [PATCH] winsys/amdgpu: add VCN JPEG to no user fence group

Am 08.05.19 um 15:23 schrieb Liu, Leo: On 5/8/19 9:19 AM, Koenig, Christian wrote: Am 08.05.19 um 15:14 schrieb Liu, Leo: On 5/8/19 9:02 AM, Christian König wrote: [CAUTION: External Email] Am 08.05.19 um 14:56 schrieb Liu, Leo: There is no user fence for JPEG, the bug triggering kernel

Re: [Mesa-dev] [PATCH] winsys/amdgpu: add VCN JPEG to no user fence group

Am 08.05.19 um 14:56 schrieb Liu, Leo: There is no user fence for JPEG, the bug triggering kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT) Oh, we are probably going to need to check for this in the kernel as well. Currently we only check for UVD and VCE there, do you want to take a look Leo

Re: [Mesa-dev] [PATCH] winsys/amdgpu: Restrict allocation to GTT for small vram size

Am 25.04.19 um 13:37 schrieb Agrawal, Akshu: To avoid evictions, use GTT only for allocation on devices with small vram size. Signed-off-by: Akshu Agrawal --- src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git

Re: [Mesa-dev] [PATCH v2 1/7] gallium/auxiliary/vl: Move dirty define to header file

Am 07.02.19 um 15:21 schrieb James Zhu: On 2019-02-07 4:49 a.m., Christian König wrote: Patches #1, #2, #5, #7  are Reviewed-by: Christian König Patch #3 the csc_matrix need a better name since we now store more and more additional info in there, but that can as well be a follow up patch

Re: [Mesa-dev] [PATCH v2 1/7] gallium/auxiliary/vl: Move dirty define to header file

Patches #1, #2, #5, #7  are Reviewed-by: Christian König Patch #3 the csc_matrix need a better name since we now store more and more additional info in there, but that can as well be a follow up patch. Patch #4 is Acked-by: Christian König Patch #6 I think there was a simpler option

Re: [Mesa-dev] [PATCH 3/6] gallium\auxiliary\vl: Add compute shader to support video compositor render

Am 04.02.19 um 20:12 schrieb James Zhu: On 2019-02-04 1:47 p.m., Liu, Leo wrote: On 2/1/19 11:28 AM, Zhu, James wrote: Add compute shader to support video compositor render. Signed-off-by: James Zhu --- src/gallium/auxiliary/Makefile.sources | 2 +

Re: [Mesa-dev] [PATCH 6/6] gallium\auxiliary\vl: Add video compute shader render

Am 01.02.19 um 17:28 schrieb Zhu, James: Add video compute shader render. export CS_COMPOSITOR_RENDER=true to enable video compute shader render. Ok that actually makes more sense, but I would either put everything into one file or cleanly separate between gfx and compute implementation.

Re: [Mesa-dev] [PATCH 3/6] gallium\auxiliary\vl: Add compute shader to support video compositor render

Am 01.02.19 um 17:28 schrieb Zhu, James: Add compute shader to support video compositor render. I don't think that this is actually a good approach. It adds a second implementation of the compositor instead of adapting the original one to use compute shaders when available. Christian.

Re: [Mesa-dev] [PATCH 1/6] gallium\auxiliary\vl: Move dirty define to header file

Am 01.02.19 um 17:28 schrieb Zhu, James: Move dirty define to header file to share with compute shader. Signed-off-by: James Zhu --- src/gallium/auxiliary/vl/vl_compositor.c | 3 --- src/gallium/auxiliary/vl/vl_compositor.h | 2 ++ 2 files changed, 2 insertions(+), 3 deletions(-) diff

Re: [Mesa-dev] [PATCH 1/3] radeonsi: allow si_cp_dma_clear_buffer to clear GDS from any IB

Are those committed yet? They don't seem to apply cleanly on master. Christian. Am 27.11.18 um 02:56 schrieb Marek Olšák: From: Marek Olšák --- .../drivers/radeonsi/si_compute_blit.c| 4 +- src/gallium/drivers/radeonsi/si_cp_dma.c | 49 ++-

Re: [Mesa-dev] [PATCH 3/3] winsys/amdgpu: use optimal VM alignment for CPU allocations

0, , _handle, AMDGPU_VA_RANGE_HIGH)) For userptrs the VA alignment is most likely irrelevant because they are composed out of 4k pages anyway. On the other hand it shouldn't hurt to handle them the same way. Feel free to add an Acked-by: Christian König to the series. Christian.

Re: [Mesa-dev] [PATCH 0/7] winsys/amdgpu: slab allocators and tweaks for address translation

Patch #5 and #6 are Reviewed-by: Christian König For patch #7 I think we really need some testing if that gives us an improvement. As you noted as well that we have buffer which are slightly smaller than a power of two is rather unlikely. Christian. Am 24.11.18 um 00:40 schrieb Marek Olšák

Re: [Mesa-dev] [PATCH 1/3] vl: get h264 profile idc

Am 23.10.18 um 17:43 schrieb boyuan.zh...@amd.com: From: Boyuan Zhang Adding a function for converting h264 pipe video profile to profile idc Signed-off-by: Boyuan Zhang Series is Acked-by: Christian König --- src/gallium/auxiliary/util/u_video.h | 24 1 file

Re: [Mesa-dev] [PATCH] st/va: use provided sizes and coords for vlVaGetImage

Acked-by: Christian König Am 10.10.2018 um 21:18 schrieb Ilia Mirkin: Reviewed-by: Ilia Mirkin On Wed, Oct 10, 2018 at 3:12 PM wrote: From: Boyuan Zhang vlVaGetImage should respect the width, height, and coordinates x and y that passed in. Therefore, pipe_box should be created

Re: [Mesa-dev] [PATCH] st/va: use provided sizes and coords for getimage

If that also fixes the problem, then yeah that makes perfect sense to me as well. Christian. Am 05.10.2018 um 18:11 schrieb Ilia Mirkin: This is an improvement, but I think you need to clip the box to 1. Size of the surface 2. Size of the image I think that there are clipping helpers

Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.

dth/height for vaCreateImage as well as surface. But as you said that depends on codec , So I think either we can use width/height aligned based on codec or use passed width/height in vlvaGetImage to fix this issue. Thanks, Deepak -Original Message----- From: Christian König Sent: Tuesday, October 2, 20

Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.

Am 02.10.2018 um 03:47 schrieb Sharma, Deepak: From: suresh guttula In case of decoding of resolution like 40x24, while allocating surface video buffer is always aligned with macroblock width/height which is 16. But when application tries to get data after decoding through vaCreateImage

Re: [Mesa-dev] [PATCH] vl: reorder H264 profiles

Am 26.09.2018 um 00:11 schrieb boyuan.zh...@amd.com: From: Boyuan Zhang Fix the wrong h264 profiles order. Previously, the constrained baseline was added in between baseline and main profiles, which breaked the logic in radeon/vce when converting from pipe_video_profile to profile_idc I

Re: [Mesa-dev] Request for Mentor - XorgEvoc - Piglit for VA-API

Am 09.09.2018 um 12:49 schrieb Naveen Naidu: On Sun 9 Sep, 2018, 4:06 PM Christian König, <mailto:ckoenig.leichtzumer...@gmail.com>> wrote: Am 09.09.2018 um 09:55 schrieb Naveen Naidu: Thank you for the information. Yes I have a AMD GPU, It is a Radeon r5 m430. But unfo

Re: [Mesa-dev] Request for Mentor - XorgEvoc - Piglit for VA-API

Am 09.09.2018 um 09:55 schrieb Naveen Naidu: Thank you for the information. Yes I have a AMD GPU, It is a Radeon r5 m430. But unfortunately it does not have a video decoder. But I also have an integrated Intel HD 620 GPU, it's a kabylake and It had a video encoder and video decoder. I have

Re: [Mesa-dev] [PATCH] ac/radeonsi: fix CIK copy max size

Am 29.08.2018 um 05:53 schrieb Dave Airlie: From: Dave Airlie While adding transfer queues to radv, I started writing some tests, the first test I wrote fell over copying a buffer larger than this limit. Checked AMDVLK and found the correct limit. Cc: --- src/amd/common/sid.h | 4 +++- 1

Re: [Mesa-dev] libdrm: Fix amdgpu build failure

Hi Mike, it is not the right mailing list, but thanks for the info. I'm going to push that patch ASAP. Christian. Am 07.08.2018 um 14:38 schrieb Mike Lothian: Hi I'm not sure if this is the right mailing list or not but the following patch gets things building with meson again

Re: [Mesa-dev] [PATCH] st/vdpau: allow progressive video surface with interop

Am 07.05.2018 um 15:03 schrieb Leo Liu: On 05/07/2018 05:10 AM, Christian König wrote: Am 02.05.2018 um 16:51 schrieb Leo Liu: mpv now interop with video surface instead of output surface previously, so it fails with "vlVdpVideoSurfaceDMABuf", this's fine for Mesa GL, since the

Re: [Mesa-dev] [PATCH] st/vdpau: allow progressive video surface with interop

r others Signed-off-by: Leo Liu <leo@amd.com> Cc: Christian König <christian.koe...@amd.com> Cc: "18.1 18.0" <mesa-sta...@lists.freedesktop.org> That won't work correctly. The NV_VDPAU_interop extension we implement with that needs interlaced layout or otherwis

Re: [Mesa-dev] [PATCH] radeon/vcn: fix mpeg4 msg buffer settings

;mesa-sta...@lists.freedesktop.org> Signed-off-by: Boyuan Zhang <boyuan.zh...@amd.com> Reviewed-by: Leo Liu <leo@amd.com> Reviewed-by: Christian König <christian.koe...@amd.com> as well. --- src/gallium/drivers/radeon/radeon_vcn_dec.c | 18 +- 1 file changed, 9 insertions(

Re: [Mesa-dev] [PATCH 1/3] radeonsi: implement mechanism for IBs without partial flushes at the end (v6)

Am 15.04.2018 um 20:46 schrieb Nicolai Hähnle: On 07.04.2018 04:31, Marek Olšák wrote: From: Marek Olšák (This patch doesn't enable the behavior. It will be enabled in a later commit.) Draw calls from multiple IBs can be executed in parallel. v2: do emit partial flushes

  1   2   3   4   5   6   7   8   9   10   >