Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications

ulkan extension based approach it's really tricky to do this as well. Basically only the driver knows what and how data needs to be mapped and only Wine knows were it can be mapped. So you need to exchange a bunch of information like size and alignment of a mapping to actually make it work.

Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications

k please let me know if that solution works for you and if you're interested in using it. If yes I would go ahead and send the patch to the Linux memory management folks for discussion. Regards, Christian. Am 24.10.24 um 17:06 schrieb Christian König: Darek we are unfortunately both par

Re: libdrm_amdgpu being forked and merged into Mesa

Am 28.10.24 um 11:13 schrieb Michel Dänzer: On 2024-10-25 19:07, Bas Nieuwenhuizen wrote: On Fri, Oct 25, 2024 at 6:57 PM Michel Dänzer mailto:michel.daen...@mailbox.org>> wrote: On 2024-10-25 17:57, Bas Nieuwenhuizen wrote: > On Fri, Oct 25, 2024 at 4:36 PM Michel Dänzer mailto:michel

Re: libdrm_amdgpu being forked and merged into Mesa

ace management conflicts with the CPU virtual address space that ROCm shares between CPU and GPU, that would be a problem. Regards,   Felix On 2024-10-24 09:24, Alex Deucher wrote: On Thu, Oct 24, 2024 at 8:38 AM Christian König wrote: Completely agree, but that's a platform decision which

Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications

<4G address space as described elsewhere in the thread. That would be pretty ideal from a driver vendor perspective. Does that work? Thanks, -James On 10/23/24 06:12, Christian König wrote: I haven't read through the whole mail thread, but if you manage the address space using mmap

Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications

ress space as described elsewhere in the thread. That would be pretty ideal from a driver vendor perspective. Does that work? Thanks, -James On 10/23/24 06:12, Christian König wrote: I haven't read through the whole mail thread, but if you manage the address space using mmap() then you alwa

Re: libdrm_amdgpu being forked and merged into Mesa

hey also likely map them again for themselves - APIs don't share any virtual addresses as far as I know. Marek On Thu, Oct 24, 2024, 08:12 Christian König wrote: Am 22.10.24 um 06:06 schrieb Marek Olšák: > Hi, > > The MR is up: > https://gitlab.freedeskto

Re: libdrm_amdgpu being forked and merged into Mesa

Am 22.10.24 um 06:06 schrieb Marek Olšák: Hi, The MR is up: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31756 It's good to go as long as there is no functional issue. Finally getting rid of all the mid-layering? What about shared VA-space? Regards, Christian. libdrm_amdgpu w

Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications

into that. Regards, Christian. Am 22.10.24 um 19:32 schrieb James Jones: This sounds interesting, but does it come with the same "Only gets 2GB VA" downside Derek pointed out in the thread fork where he was responding to Michel? Thanks, -James On 10/22/24 07:14, Christian König

Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications

Hi guys, one theoretical alternative not mentioned in this thread is the use of mremap(). In other words you reserve some address space below 2G by using mmap(NULL, length, PROT_NONE, MAP_32BIT | MAP_ANONYMOUS, 0, 0) and then use mremap(addr64bit, 0, length, MREMAP_FIXED, reserved_addr). I

Re: Does gbm_bo_map() implicitly synchronise?

-trivial on our implementation. It's not the right tool for e.g., reading back or populating OpenGL textures or X pixmaps. If you don't want to run on the NV implementation, feel free to ignore this advice, but I'd still suggest it's not the best tool for most jobs. Thanks

Re: Does gbm_bo_map() implicitly synchronise?

Am 18.06.24 um 07:01 schrieb Pierre Ossman: On 17/06/2024 20:18, Christian König wrote: Am 17.06.24 um 19:18 schrieb Pierre Ossman: On 17/06/2024 18:09, Michel Dänzer wrote: Can I know whether it is needed or not? Or should I be cautious and always do it? Assuming GBM in the X server uses

Re: Does gbm_bo_map() implicitly synchronise?

Am 17.06.24 um 19:18 schrieb Pierre Ossman: On 17/06/2024 18:09, Michel Dänzer wrote: Can I know whether it is needed or not? Or should I be cautious and always do it? Assuming GBM in the X server uses the GPU HW driver, I'd say it shouldn't be needed. It does not (except the driver lib

Re: Does gbm_bo_map() implicitly synchronise?

Am 17.06.24 um 16:55 schrieb Michel Dänzer: On 2024-06-17 16:52, Christian König wrote: Am 17.06.24 um 16:50 schrieb Michel Dänzer: On 2024-06-17 12:29, Pierre Ossman wrote: Just to avoid any uncertainty, are both of these things done implicitly by gbm_bo_map()/gbm_bo_unmap()? I did test

Re: Does gbm_bo_map() implicitly synchronise?

Am 17.06.24 um 16:50 schrieb Michel Dänzer: On 2024-06-17 12:29, Pierre Ossman wrote: Just to avoid any uncertainty, are both of these things done implicitly by gbm_bo_map()/gbm_bo_unmap()? I did test adding those steps just in case, but unfortunately did not see an improvement. My order was:

Re: Does gbm_bo_map() implicitly synchronise?

Am 17.06.24 um 12:29 schrieb Pierre Ossman: On 17/06/2024 10:13, Christian König wrote: Let me try to clarify a couple of things: The DMA_BUF_IOCTL_SYNC function is to flush and invalidate caches so that the GPU can see values written by the CPU and the CPU can see values written by the GPU

Re: Does gbm_bo_map() implicitly synchronise?

Am 17.06.24 um 09:32 schrieb Pierre Ossman: On 15/06/2024 13:35, Marek Olšák wrote: It's probably driver-specific. Some drivers might need glFlush before you use gbm_bo_map because gbm might only wait for work that has been flushed. That would be needed on the "writing" side, right? So if I'm

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

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 th

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 VA-API"

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 firs

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 acc

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 leverage

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 llv

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

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

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

-Daniel Cc: mesa-dev@lists.freedesktop.org Cc: Bas Nieuwenhuizen Cc: Dave Airlie Cc: Rob Clark Cc: Kristian H. Kristensen 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 Wan

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

- I didn't audit the ttm drivers, but given that 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

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)

red by 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 fro

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

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 thi

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

aWwiLCJXVCI6Mn0%3D%7C1000&sdata=MM5c55nspWbUxzajqBv1iNHdz2TYAImG2XPOSnDE6qQ%3D&reserved=0 v10 (Jason Ekstrand, Daniel Vetter): - Add reviews/acks - Add a patch to rename _rcu to _unlocked - Split things better so import is clearly RFC status v11 (Daniel Vetter): - Add

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 TT

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)

tainers - 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): - Better docs for DMA_BUF_IOCTL_SYNC v12 (Christian König): - Drop the rename patch in favo

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

33 PM 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 a

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

d, Jun 09, 2021 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 yo

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 heavyweigh

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

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 gat

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 EGLSt

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 f

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 so

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

at OK? Marek On Fri, May 28, 2021 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 hav

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 by

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 cou

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

- I didn't audit the ttm drivers, but given that 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

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 th

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

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 the

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 com

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

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 r

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

--Jason > > > > On Mon, May 3, 2021 at 9:42 AM Alex Deucher mailto:alexdeuc...@gmail.com>> wrote: > > > > > > On Sat, May 1, 2021 at 6:27 PM Marek Olšák mailto:mar...@gmail.com>> wrote: > > > >

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

lex Deucher wrote: On Sat, May 1, 2021 at 6: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 o

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 co

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'

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

quot;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_

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

iently talking with other people, 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 synch

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

hink about the "other" 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 onl

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

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 th

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 req

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 c

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

niel Thanks, Marek On Tue, 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

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 how

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 in

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

g successfully. 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 betwe

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

but figured I'd 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:1

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

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 o

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 a/src/gallium/win

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 for

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 + src/gallium/auxiliary/meson.bu

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

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

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

  1   2   3   4   5   6   7   8   9   10   >