Re: GL framebuffer fetch behavior

AMD lowers it to an image load, which follows the rules for image views, so (x, 0, 0, 1) for R8_UNORM. Marek On Wed, Apr 23, 2025 at 12:25 PM Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > Hi, > > An issue recently came up in the GL working group: what is the robustness > behavior

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

On Mon, Jan 20, 2025 at 1:41 PM Simona Vetter wrote: > On Mon, Jan 20, 2025 at 08:58:20AM +0100, Thomas Zimmermann wrote: > > Hi > > > > > > Am 18.01.25 um 03:37 schrieb Marek Olšák: > > [...] > > > > > > 3) Implementing DRM_FORMAT_MOD_LINEAR as

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

15, 2025 at 12:20:07PM +, Daniel Stone wrote: > > On Wed, 15 Jan 2025 at 04:05, Marek Olšák wrote: > > > On Tue, Jan 14, 2025 at 12:58 PM Daniel Stone > wrote: > > >> AMD hardware is the only hardware I know of which doesn't support > > >> overalig

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

On Tue, Jan 14, 2025 at 1:34 PM Faith Ekstrand wrote: > On January 14, 2025 03:39:45 Marek Olšák wrote: > >> I would keep the existing modifier interfaces, API extensions, and >> expectations the same as today for simplicity. >> >> The new linear modifier definit

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

On Tue, Jan 14, 2025 at 12:58 PM Daniel Stone wrote: > Hi, > > On Tue, 14 Jan 2025 at 09:38, Marek Olšák wrote: > > I would keep the existing modifier interfaces, API extensions, and > expectations the same as today for simplicity. > > Well yes, not just for simplicity

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

On Tue, Jan 14, 2025 at 12:55 PM James Jones wrote: > I don't see how that fits in the current modifier usage patterns. I'm > not clear how applications are supposed to programmatically "look at the > modifiers of other drivers to find commonalities," nor how that "keeps > "expectations the same

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

I would keep the existing modifier interfaces, API extensions, and expectations the same as today for simplicity. The new linear modifier definition (proposal) will have these fields: 5 bits for log2 pitch alignment in bytes 5 bits for log2 height alignment in rows 5 bits for log2 offset

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

On Fri, Dec 20, 2024 at 10:24 AM Simona Vetter wrote: > On Thu, Dec 19, 2024 at 05:09:33PM +0100, Michel Dänzer wrote: > > On 2024-12-19 10:02, Daniel Stone wrote: > > > > > > How this would be used in practice is also way too underdocumented. We > > > need to document that exact-round-up 64b is

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

> > * Modifiers must uniquely encode buffer layout. In other words, a buffer > must > * match only a single modifier. > That sentence is misleading and impossible to meet. Specifications are sometimes changed to reflect the overwhelming reality. Multiple modifiers can represent identical layouts

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

On Thu, Dec 19, 2024 at 5:32 AM Brian Starkey wrote: > On Wed, Dec 18, 2024 at 09:53:56PM +0000, Marek Olšák wrote: > > On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey > wrote: > > > > > On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote: > > > >

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey wrote: > On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote: > > > > For that reason I think linear modifiers with explicit pitch/size > > alignment constraints is a sound concept and fits into how modifiers work > > overall. > > -Sima > >

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

On Mon, Dec 16, 2024 at 9:53 AM Simona Vetter wrote: > On Mon, Dec 16, 2024 at 11:46:13AM +0100, Lucas Stach wrote: > > Am Montag, dem 16.12.2024 um 10:27 +0100 schrieb Michel Dänzer: > > > On 2024-12-15 21:53, Marek Olšák wrote: > > > > The com

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

On Mon, Dec 16, 2024 at 5:46 AM Lucas Stach wrote: > Am Montag, dem 16.12.2024 um 10:27 +0100 schrieb Michel Dänzer: > > On 2024-12-15 21:53, Marek Olšák wrote: > > > The comment explains the problem with DRM_FORMAT_MOD_LINEAR. > > > > > > Signed-off-

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

On Mon, Dec 16, 2024 at 4:27 AM Michel Dänzer wrote: > On 2024-12-15 21:53, Marek Olšák wrote: > > The comment explains the problem with DRM_FORMAT_MOD_LINEAR. > > > > Signed-off-by: Marek Olšák marek.ol...@amd.com>> > > > > diff --git a/include/uap

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

Missed 2 lines from the diff: +#define DRM_FORMAT_MOD_LINEAR_PITCH_ALIGN_128B fourcc_mod_code(NONE, 2) +#define DRM_FORMAT_MOD_LINEAR_PITCH_ALIGN_256B fourcc_mod_code(NONE, 3) Marek On Sun, Dec 15, 2024 at 3:53 PM Marek Olšák wrote: > The comment explains the problem w

[PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

The comment explains the problem with DRM_FORMAT_MOD_LINEAR. Signed-off-by: Marek Olšák diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 78abd819fd62e..8ec4163429014 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -484,9 +484,27

Re: [ANNOUNCE] mesa 24.2.7

https://github.com/marekolsak/marek-build/?tab=readme-ov-file#mareks-approach-to-building-amd-gpu-drivers-for-driver-development Marek On Tue, Nov 19, 2024 at 3:19 AM Heiko Nardmann wrote: > > Hi together, > > I would like to build mesa on my own on Ubuntu. After starting on this I > experience

Re: libdrm_amdgpu being forked and merged into Mesa

On Mon, Oct 28, 2024 at 6:51 AM Michel Dänzer wrote: > > On 2024-10-28 11:27, Christian König wrote: > > 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 >>> > wrot

Re: libdrm_amdgpu being forked and merged into Mesa

gt; >>> > >>> I don't think we need to share VA space. APIs usually share one or > >>> two buffers. That's almost nothing compared to the size of the > >>> occupied VA space. They also likely map them again for themselves - > >>> APIs don&#

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

Is there a way for drivers to change the semantics of memory mappings to make mremap work? Marek On Thu, Oct 24, 2024, 07:08 Derek Lesho wrote: > In my last mail I responded to this approach all the way at the bottom, > so it probably got lost: mremap on Linux as it exists now won't work as > i

Re: libdrm_amdgpu being forked and merged into Mesa

24, 2024, 08:12 Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > 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 the

Standard tiled modifiers

Hi, Here I make a case that standard tiled DRM format modifiers that multiple GPU vendors can support are feasible: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12054 Marek

libdrm_amdgpu being forked and merged into Mesa

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. libdrm_amdgpu will still be relevant for PAL, ROCm, and xf86-video-amdgpu. Marek

Re: r300: Regression in f424ef18010 breaks wayland on RS480M

Hi, Can you please file a gitlab issue and post a screenshot of the corruption? Thanks, Marek On Tue, Oct 8, 2024, 15:21 Valtteri Koskivuori wrote: > Hello all. > > I run Arch Linux on a 2006 Fujitsu S2110 laptop that has sentimental > value to me. Earlier in 2024, I observed a regression that

Re: Downsides of force_gl_names_reuse preventing adoption as default

The only error is that virgl fails with: ERROR - dEQP error: [ 135.132231] [drm:virtio_gpu_dequeue_ctrl_func] *ERROR* response 0x1200 (command 0x206) That's the only blocker. Marek On Thu, Oct 3, 2024, 14:03 Marek Olšák wrote: > > https://gitlab.freedesktop.org/mareko/me

Re: Downsides of force_gl_names_reuse preventing adoption as default

https://gitlab.freedesktop.org/mareko/mesa/-/commit/cdde6fcb7947514753c1a3feaee71c2212cffea6 If I remember correctly, it failed some tests. Marek On Thu, Oct 3, 2024 at 3:53 AM Rocco Tormenta wrote: > > Hi there, apologies if this has already been asked, I couldn't find > relevant information o

Re: Question about BITSET_WORD

All 32-bit operations are generally faster than 64-bit. If both happen to have the same performance per clock (that would have to be a deliberate hw design choice), 32-bit opcodes have likely lower power consumption, which allows a higher core frequency. That doesn't even scratch the surface. Expl

Re: ZINK support to use libvulkan on Virtio-GPU

virtio likely doesn't work with zink for the same reason that xf86-video-amdgpu doesn't work with zink: the DDX doesn't support modifiers. Marek On Mon, Jul 22, 2024 at 11:00 AM Mike Blumenkrantz wrote: > > Hi, > > If you aren't hitting the kopper init paths (e.g., kopper_init_screen), > you're

Re: time for amber2 branch?

i915? tegra isn't really a driver. It just calls the gallium interface like trace, but without the tracing. crocus is in the same boat as r600. Marek On Wed, Jun 19, 2024, 10:34 Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > In looking at the gallium tree, I'm wondering if it isn

Re: Does gbm_bo_map() implicitly synchronise?

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. Marek On Sat, Jun 15, 2024 at 4:29 AM Pierre Ossman wrote: > > On 15/06/2024 07:54, Marek Olšák wrote: > > gbm_bo_map synchroniz

Re: Does gbm_bo_map() implicitly synchronise?

gbm_bo_map synchronizes if it needs to move memory to make the buffer readable by the CPU or if the buffer is being used/written by the GPU. Marek On Sat, Jun 15, 2024 at 1:12 AM Pierre Ossman wrote: > > I'm experimenting with DRI3 and its use of GBM to share buffers. It > mostly works fine, but

Re: Lavapipe license

You should only see the MIT license for all Mesa contributions that don't import external source code. Marek On Tue, Feb 13, 2024 at 5:23 AM George Karpathios wrote: > > Hi everyone, > > I'd like to bundle Lavapipe's binary that I've built (also contains LLVM > thanks to static linking) with a

Re: Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")

Gallium looks like it was just a copy of DX10, and likely many things were known from DX10 in advance before anything started. Vulkanium doesn't have anything to draw inspiration from. It's a completely unexplored idea. AMD's PAL is the same idea as Gallium. It's used to implement Vulkan, DX, Mant

Re: MesaGL development on Fedora

Hi, All Mesa libraries must come from the same build so as not to be rejected at runtime. Marek On Mon, Dec 25, 2023 at 7:15 AM Mischa Baars wrote: > > Hello, > > I was going over MesaGL Blending when I discovered an issue that needs > fixing. The problem is that when I compile and install a c

Better lost context robustness for window systems

There is a possibility to have robust contexts for all apps within a window system when apps themselves are not robust. If an app is robust, losing a context skips all following API calls. The app must recreate its context and resources and continue. When an app is not robust, losing a context re

Re: X Crashes after Installing Mesa Driver

Please follow https://github.com/marekolsak/marek-build/ Marek On Wed, Jul 12, 2023 at 11:55 AM Chen, Jinyi (Joey) wrote: > > [AMD Official Use Only - General] > > > Hi, > > > I have built and install mesa driver. I install it to system so xorg boots up > with it. But I am encountering black sc

Re: Benefits of cryptographic hash functions for uniquely identifing Vulkan shaders.

If there is a hash collision, it will cause a GPU hang. A cryptographic hash function reduces that chance to practically zero. Marek On Thu, Jun 29, 2023, 07:04 mikolajlubiak1337 wrote: > Hi, > I have recently read Phoronix article[1] about you switching to BLAKE3 > instead of SHA1. > If BLAKE3

Re: Need support to add NV12 format in mesa code

I don't think u_format.csv can describe it. It only describes formats of pixels in a single plane. All formats that have multiple planes where a single pixel stores only a subset of its bits in each plane are handled as special cases. Drivers also don't support such formats directly. For example, d

Re: Zink MR signoff tags

That's a good idea. Marek On Wed, Oct 5, 2022, 11:22 Erik Faye-Lund wrote: > On Wed, 2022-10-05 at 08:20 -0400, Alyssa Rosenzweig wrote: > > + for not requiring rb/ab tags ... > > I think it's time to think about making this change all over Mesa as > well. We're deeply in bed with GitLab by now

Re: Moving amber into separate repo?

Removing mainline drivers from the build system of Amber is a good idea. Marek On Fri, Sep 23, 2022, 06:33 Filip Gawin wrote: > Hi, recently I've seen case of user been using Amber when hardware was > supported by mainline mesa. This gave me a couple of thoughts. > > 1) Users don't correlate "A

Re: Moving amber into separate repo?

Git stores all commits. Removing files at the top of main doesn't make the repository smaller. It actually makes it bigger. Forking the repository would also double the size on the server. Marek On Fri, Sep 23, 2022, 06:33 Filip Gawin wrote: > Hi, recently I've seen case of user been using Ambe

Re: Gitlab filters in Gmail

ts and issues? > > Timur > > On Thu, 2022-07-14 at 05:28 -0400, Marek Olšák wrote: > > Hi, > > > > Gitlab emails are difficult to filter because issues and MRs are not > > easy to distinguish. I know that Matt has a script which does this, > > but since tha

Gitlab filters in Gmail

Hi, Gitlab emails are difficult to filter because issues and MRs are not easy to distinguish. I know that Matt has a script which does this, but since that was kind of difficult for me to set up, I resorted to these filters instead and they work pretty well. Matches: from:gitlab ("created a merge

Re: Xbox Series S/X UWP

> I'd love to see Mesa used to bring Vulkan to consoles! Ever heard of Steam Deck? ;) Marek On Mon, Jun 6, 2022 at 12:59 PM Jason Ekstrand wrote: > On Mon, Jun 6, 2022 at 11:38 AM Jesse Natalie > wrote: > >> (Hopefully this goes through and not to spam like last time I tried to >> respond…) >

Re: Replacing NIR with SPIR-V?

> - Does it make sense to move to SPIR-V? No, it doesn't make any sense whatsoever. Marek On Wed, Jan 19, 2022 at 8:17 PM Abel Bernabeu < abel.berna...@esperantotech.com> wrote: > Hi, > > My name Abel Bernabeu and I currently chair the Graphics and ML Special > Interest Group within RISC-V. > >

NIR: is_used_once breaks multi-pass rendering

Hi, "is_used_once" within an inexact transformation in nir_opt_algebraic can lead to geometry differences with multi-pass rendering, causing incorrect output. Here's an example to proof this: Let's assume there is a pass that writes out some intermediate value from the position calculation as a v

Re: git and Marge troubles this week

The ac_surface_meta_address_test timeout occurs rarely and it's because the test is computationally demanding. It's also possible the machine got slower for some reason. Marek On Fri, Jan 7, 2022 at 12:32 PM Emma Anholt wrote: > On Fri, Jan 7, 2022 at 6:18 AM Connor Abbott wrote: > > > > Unfor

Re: revenge of CALLOC_STRUCT

I remember that it wasn't unusual on Windows to define malloc, calloc, strdup, and free macros to redirect those calls to custom wrappers. That would eliminate the need to have non-standard names like MALLOC. There is also the pipe_reference debug code. Is anybody using that? Marek On Sun., Dec.

Re: Moving code around, post classic

While the current directory structure is confusing, the new suggested directory structure might not be helpful because GL is more spread out anyway. mapi is libglapi, so it seems to be its own thing, not a gallium thing glx is libgl, same thing. egl is libegl, same thing. ... unless we want to mer

Re: Moving code around, post classic

Hi, 1. If this happens, let's call it src/gallium/frontends/gl. 3. The src directory already has too much stuff. Marek On Mon, Dec 6, 2021 at 6:51 PM Dylan Baker wrote: > Classic is gone, and the cleanups have begun, obviously. There is > another cleanup that I had in mind, which is moving sr

Re: [Mesa-dev] glvnd: a lot of CPU overhead, lower performance

https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/222 On Fri, Oct 15, 2021 at 3:27 PM Marek Olšák wrote: > Hi, > > I just enabled glvnd and noticed the performance is much lower. > > glxgears: 14% perf drop > glvnd off: ~28000 FPS > glvnd on: ~24000 FPS > > vi

[Mesa-dev] glvnd: a lot of CPU overhead, lower performance

Hi, I just enabled glvnd and noticed the performance is much lower. glxgears: 14% perf drop glvnd off: ~28000 FPS glvnd on: ~24000 FPS viewperf13 (some subtest): 11% perf drop glvnd off: 201 FPS glvnd on: 179 FPS glvnd spends a lot of time in libGL.so and some in libGLdispatch.so. The "off" re

Re: [Mesa-dev] Workflow Proposal

I'd like gitlab macros :rb: and :ab: that put the tags into the comment. Marek On Tue, Oct 12, 2021 at 5:01 PM Jason Ekstrand wrote: > On Tue, Oct 12, 2021 at 3:56 PM apinheiro wrote: > > > > > > On 12/10/21 13:55, Alyssa Rosenzweig wrote: > > > > I would love to see this be the process across

Re: [Mesa-dev] Workflow Proposal

Despite all the time it takes to add the tags and force-push, I have no objection to doing that. It captures per-commit reviews well. Marek On Thu, Oct 7, 2021 at 1:17 PM Eero Tamminen wrote: > Hi, > > On 7.10.2021 19.51, Daniel Stone wrote: > > On Thu, 7 Oct 2021 at 09:38, Eero Tamminen > wro

Re: [Mesa-dev] Let's enable _GLIBCXX_ASSERTIONS=1 on mesa debug builds

Yes, this would be useful. Marek On Fri, Sep 10, 2021 at 1:20 PM Timur Kristóf wrote: > Hi, > > We've been recently working on tracking down some "mysterious" crashes > that some users experienced on distro builds of mesa but we couldn't > reproduce locally, until we found out about _GLIBCXX_A

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

against such behavior because it will receive them too. I don't know if that would work with dma_fence. Marek On Thu, Jun 17, 2021 at 3:04 PM Daniel Vetter wrote: > On Thu, Jun 17, 2021 at 02:28:06PM -0400, Marek Olšák wrote: > > The kernel will know who should touch the implicit-

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

gt; As long as we can figure out who touched to a certain sync object last > that > > would indeed work, yes. > > Don't you need to know who will touch it next, i.e. who is holding up your > fence? Or maybe I'm just again totally confused. > -Daniel > > > >

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

d that. > > If the hardware says that seq - 1 was written fine, but seq is missing > then the kernel blames whoever was supposed to write seq. > > Just pieping the write through a privileged instance should be fine to > make sure that we don't run into issues. > > Chri

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

Hi Daniel, We just talked about this whole topic internally and we came up to the conclusion that the hardware needs to understand sync object handles and have high-level wait and signal operations in the command stream. Sync objects will be backed by memory, but they won't be readable or writable

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

On Thu., Jun. 3, 2021, 15:18 Daniel Vetter, wrote: > On Thu, Jun 3, 2021 at 7:53 PM Marek Olšák wrote: > > > > Daniel, I think what you are suggesting is that we need to enable user > queues with the drm scheduler and dma_fence first, and once that works, we > can investi

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

r the hw does it. It's the same code, just in a different place. Thanks, Marek On Thu, Jun 3, 2021 at 7:22 AM Daniel Vetter wrote: > On Thu, Jun 3, 2021 at 12:55 PM Marek Olšák wrote: > > > > On Thu., Jun. 3, 2021, 06:03 Daniel Vetter, wrote: > >> > >> On T

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

On Thu., Jun. 3, 2021, 06:03 Daniel Vetter, wrote: > On Thu, Jun 03, 2021 at 04:20:18AM -0400, Marek Olšák wrote: > > On Thu, Jun 3, 2021 at 3:47 AM Daniel Vetter wrote: > > > > > On Wed, Jun 02, 2021 at 11:16:39PM -0400, Marek Olšák wrote: > > > > On Wed,

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

On Thu, Jun 3, 2021 at 3:47 AM Daniel Vetter wrote: > On Wed, Jun 02, 2021 at 11:16:39PM -0400, Marek Olšák wrote: > > On Wed, Jun 2, 2021 at 2:48 PM Daniel Vetter wrote: > > > > > On Wed, Jun 02, 2021 at 05:38:51AM -0400, Marek Olšák wrote: > > > > On Wed

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

On Wed, Jun 2, 2021 at 2:48 PM Daniel Vetter wrote: > 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 > &

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

On Wed, Jun 2, 2021 at 5:44 AM Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > 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 thi

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

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 gather more > knowledge and then make better decisions. > > The idea we a

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

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 gather more knowledge and then make better decisions. The idea we are considering is that we'll expose memory-based sync objects to userspace for read only, and the

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

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

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

e, but it's not possible to know which process is guilty (all processes holding the buffer handle would be suspects). Marek On Fri, May 28, 2021 at 6:25 PM Marek Olšák wrote: > If both implicit and explicit synchronization are handled the same, then > the kernel won't be able to iden

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

iggest problem are the sync_files for Android, since they are really > not easy to support at all. If Android wants to support user queues we > would probably have to do some changes there. > > Regards, > Christian. > > Am 27.05.21 um 23:51 schrieb Marek Olšák: > > Hi

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

Hi, Since Christian believes that we can't deadlock the kernel with some changes there, we just need to make everything nice for userspace too. Instead of explaining how it will work, I will explain the cases where future hardware (and its kernel driver) will break existing userspace in order to p

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

I see some mentions of XNACK and recoverable page faults. Note that all gaming AMD hw that has userspace queues doesn't have XNACK, so there is no overhead in compute units. My understanding is that recoverable page faults are still supported without XNACK, but instead of the compute unit replaying

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

but in the kernel without concurrency/preemption. Is this now safe enough for dma_fence? Marek On Mon, May 3, 2021 at 4:36 PM Marek Olšák wrote: > What about direct submit from the kernel where the process still has write > access to the GPU ring buffer but doesn't use it? I

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

hink where that leaves us is that there is no safe place to > create a dma_fence except for inside the ioctl which submits the work > and only after any necessary memory has been allocated. That's a > pretty stiff requirement. We may still be able to interact with > userspace a bit

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

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 nee

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

On Wed., Apr. 28, 2021, 00:01 Jason Ekstrand, wrote: > On Tue, Apr 27, 2021 at 4:59 PM Marek Olšák wrote: > > > > Jason, both memory-based signalling as well as interrupt-based > signalling to the CPU would be supported by amdgpu. External devices don't > need to

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

to keep the kernel out of the picture. Marek On Tue, Apr 27, 2021 at 3:41 PM Jason Ekstrand wrote: > Trying to figure out which e-mail in this mess is the right one to reply > to > > On Tue, Apr 27, 2021 at 12:31 PM Lucas Stach > wrote: > > > > Hi, > > >

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

Supporting interop with any device is always possible. It depends on which drivers we need to interoperate with and update them. We've already found the path forward for amdgpu. We just need to find out how many other drivers need to be updated and evaluate the cost/benefit aspect. Marek On Tue,

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

have the same problem in the kernel. > > The good news is I think we can relatively easily convert i915 and older > amdgpu device to something which is compatible with user fences. > > So yes, getting that fixed case by case should work. > > Christian > > Am 27.04.21 um

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

e "external -> amd" dependency too? Marek On Tue., Apr. 27, 2021, 08:15 Daniel Vetter, wrote: > On Tue, Apr 27, 2021 at 2:11 PM Marek Olšák wrote: > > Ok. I'll interpret this as "yes, it will work, let's do it". > > It works if all you care ab

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

gt; > 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, but also a well known approach. > > Christian. > > Am 27.04.21

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

, 2021, 04:02 Daniel Vetter, wrote: > On Mon, Apr 26, 2021 at 04:59:28PM -0400, Marek Olšák wrote: > > Thanks everybody. The initial proposal is dead. Here are some thoughts on > > how to do it differently. > > > > I think we can have direct command submission from users

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

Thanks everybody. The initial proposal is dead. Here are some thoughts on how to do it differently. I think we can have direct command submission from userspace via memory-mapped queues ("user queues") without changing window systems. The memory management doesn't have to use GPU page faults like

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

On Tue, Apr 20, 2021 at 2:39 PM Daniel Vetter wrote: > On Tue, Apr 20, 2021 at 6:25 PM Marek Olšák wrote: > > > > Daniel, imagine hardware that can only do what Windows does: future > fences signalled by userspace whenever userspace wants, and no kernel > queues like we ha

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

Daniel, imagine hardware that can only do what Windows does: future fences signalled by userspace whenever userspace wants, and no kernel queues like we have today. The only reason why current AMD GPUs work is because they have a ring buffer per queue with pointers to userspace command buffers fol

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

rand: > > > 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 m

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

ne fences would work across processes and how resilient they would be to segfaults. Marek On Mon, Apr 19, 2021 at 11:48 AM Jason Ekstrand wrote: > Not going to comment on everything on the first pass... > > On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote: > > > > Hi,

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

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 can coexist with what we have now. *1. Introduction* (skip this if you are already sold on explicit fences) The curren

Re: [Mesa-dev] [RFC] Concrete proposal to split classic

; "lts" branch/tree/whatever? Some of the "fixes" will require large-ish > changes to the driver... > > Cheers, > > -ilia > > On Mon, Mar 29, 2021 at 6:48 PM Marek Olšák wrote: > > > > Alright that's r300 and swr that are going

Re: [Mesa-dev] [RFC] Concrete proposal to split classic

Alright that's r300 and swr that are going to find a new home in the lts branch. Do any other gallium drivers want to join them? Marek On Mon., Mar. 29, 2021, 13:51 Zielinski, Jan, wrote: > On Thursday, March 25, 2021 8:47 Marek Olšák wrote: > > Same thinking could be applied to

Re: [Mesa-dev] [RFC] Concrete proposal to split classic

On Thu., Mar. 25, 2021, 12:14 Dylan Baker, wrote: > By delete I mean "remove -Dgallium-drivers and -Dvulkan-drivers" from > Meson. Maybe it makes sense to keep gallium for r300? But how many r300 > breakages have we had in recent memory? > We don't have any recent information on the status of r3

Re: [Mesa-dev] [RFC] Concrete proposal to split classic

+1 We still have some CPU overhead performance targets we haven't reached. One of them is to decrease CPU overhead for one benchmark 4 times compared to everything we already have in master. I don't know how we are going to do that, but we'll try. Marek On Mon, Mar 22, 2021 at 6:15 PM Dylan Bake

Re: [Mesa-dev] llvmpipe MSAA (Was: Fwd: [Mesa-users] Issues with removal of classic OSMesa)

and > corresponding sample pattern) > > None of this would be throwaway work: the SampleMaskIn are correct and could > be used for full MSAA support in the future too, and the conservative > rasterization could be a feature on its own right too eventually. > > Jose > >

[Mesa-dev] Applying fixes to stable branches

Hi, How do you apply the fixes? Is it possible to pick a random commit in master and apply all fixes that are newer than that commit? Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/

Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

Hi, llvmpipe could implement line and polygon smoothing by rasterizing in MSAA and passing the coverage to SampleMaskIn in the fragment shader, but doing Z/S tests and color writes and everything else single-sampled. Then, FragColor.a *= bitcount(SampleMaskIn) / (float)num_samples. It's roughly wh

Re: [Mesa-dev] Mesa 20.2.x and GL_RG8_SNORM/GL_NONE

If CPU overhead is a problem, mesa_glthread=true is likely to give you a large performance boost and it should be conformant. Marek Marek On Fri., Oct. 16, 2020, 00:28 Jason Ekstrand, wrote: > Generally, you need to be careful with forcing no_error. Some apps > rely on gl errors to check for

Re: [Mesa-dev] Rust drivers in Mesa

I think it's just going to get more messy and complicated for people who don't want to learn or use another language. Mesa already requires people to know C, Python, and now newly Gitlab CI scripts just to get stuff done and merged. Another language would only exacerbate the issue and steepen the l

Re: [Mesa-dev] issue about context reference

Hi, Does the issue happen with mesa/master? Marek On Mon, Sep 28, 2020 at 3:11 AM Zhu Yijun wrote: > hi all, > > I use qemu/kvm to boot some android guests with virgl and run apks, > the host kernel invokes oom after several hours. > > 1. From /proc/meminfo, I see the 'SUnreclaim' is the larg

Re: [Mesa-dev] [PATCH v3 2/4] gallium/auxiliary: Add helper support for bptc format compress/decompress

ll check. >> >> On Sun, May 10, 2020 at 10:26 AM Dave Airlie wrote: >> >>> On Wed, 27 Jun 2018 at 06:36, Denis Pauk wrote: >>> > >>> > Reuse code shared with mesa/main/texcompress_bptc. >>> > >>> > v2: Use block decompress

[Mesa-dev] Gallium interface rename proposals

Hi, I don't know if you have been following gitlab, but there are a few cleanups that I have been considering doing. Rename PIPE_TRANSFER flags to PIPE_MAP, and pipe_transfer_usage to pipe_map_flags: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5749 Other proposed renames: transfer

  1   2   3   4   5   6   7   8   9   10   >