Re: libdrm_amdgpu being forked and merged into Mesa
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 >> <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.daen...@mailbox.org> >>> <mailto:michel.daen...@mailbox.org <mailto:michel.daen...@mailbox.org>>> >>> wrote: >>> > On 2024-10-25 12:18, Bas Nieuwenhuizen wrote: >>> > >>> > > (not to mention that it would mean that any users would need >>> to use libdrm_amdgpu. Given that the most likely combination of GBM with >>> shared fd/handle stuff is kernel modesetting and nobody uses libdrm_amdgpu >>> with that, having a shared libdrm_amdgpu would not help there) >>> > >>> > Not sure what you mean here, Wayland compositors use radeonsi >>> with KMS. >>> > >>> > That is what I mean, since they use KMS directly, anything that >>> radeonsi does wrt using or not using libdrm_amdgpu doesn't impact them. >>> >>> Still not following. Wayland compositors generally use the same DRM >>> file description for radeonsi (via the EGL GBM platform) and KMS. >>> >>> >>> And they will after this change, i.e. this is not a problem wrt this change. >> I'm not saying it is, it just seems to contradict the point you're making >> above. Maybe I'm being dense though, or maybe it just doesn't matter, feel >> free to drop it. > > Michel can you elaborate a bit more on how the EGL GBM platform and KMS play > together? How it generally works in Wayland compositors: The compositor opens /dev/dri/card* (or receives a corresponding fd e.g. from logind) and passes the resulting fd to gbm_create_device. It then passes the resulting struct gbm_device pointer as the native display handle when creating the EGL GBM platform display. The compositor then uses the same fd for KMS ioctls. radeonsi currently uses a duplicate of that fd internally by default, i.e. it uses the same DRM file description for allocating BOs etc. that the compositor uses for KMS. What I'm worrying about is that if Mesa stops using libdrm_amdgpu, and if it's possible for the same DRM file description to be used for another API context (Vulkan, OpenCL, ...) using another driver, the two contexts would certainly run into errors due to conflicting GPUVM ranges. It's looking like that might not actually be possible though. -- Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
Re: libdrm_amdgpu being forked and merged into Mesa
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.daen...@mailbox.org> > <mailto:michel.daen...@mailbox.org <mailto:michel.daen...@mailbox.org>>> > wrote: > > On 2024-10-25 12:18, Bas Nieuwenhuizen wrote: > > > > > (not to mention that it would mean that any users would need to > use libdrm_amdgpu. Given that the most likely combination of GBM with shared > fd/handle stuff is kernel modesetting and nobody uses libdrm_amdgpu with > that, having a shared libdrm_amdgpu would not help there) > > > > Not sure what you mean here, Wayland compositors use radeonsi with > KMS. > > > > That is what I mean, since they use KMS directly, anything that > radeonsi does wrt using or not using libdrm_amdgpu doesn't impact them. > > Still not following. Wayland compositors generally use the same DRM file > description for radeonsi (via the EGL GBM platform) and KMS. > > > And they will after this change, i.e. this is not a problem wrt this change. I'm not saying it is, it just seems to contradict the point you're making above. Maybe I'm being dense though, or maybe it just doesn't matter, feel free to drop it. -- Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
Re: Unable to create a project in gitlab.freedesktop.org
On 2024-10-25 16:12, Manuel Dun wrote: > Hello > > I want to do a merge request but I am unable to create any project, > The gitlab page gives me this message: "You cannot create projects in > your personal namespace. Contact your GitLab administrator." > > Also the fork button is not enabled (it is greyed out). > > Can you help me? See https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home#how-can-i-contribute-to-an-existing-project-or-create-a-new-one . -- Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
Re: libdrm_amdgpu being forked and merged into Mesa
On 2024-10-25 17:57, Bas Nieuwenhuizen wrote: > On Fri, Oct 25, 2024 at 4:36 PM Michel Dänzer <mailto:michel.daen...@mailbox.org>> wrote: > On 2024-10-25 12:18, Bas Nieuwenhuizen wrote: > > > (not to mention that it would mean that any users would need to use > libdrm_amdgpu. Given that the most likely combination of GBM with shared > fd/handle stuff is kernel modesetting and nobody uses libdrm_amdgpu with > that, having a shared libdrm_amdgpu would not help there) > > Not sure what you mean here, Wayland compositors use radeonsi with KMS. > > That is what I mean, since they use KMS directly, anything that radeonsi does > wrt using or not using libdrm_amdgpu doesn't impact them. Still not following. Wayland compositors generally use the same DRM file description for radeonsi (via the EGL GBM platform) and KMS. > (note that some compositors, like gamescope do the actual dmabuf dance AFAIK gamescope uses Vulkan, not GL. -- Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
Re: libdrm_amdgpu being forked and merged into Mesa
On 2024-10-25 12:18, Bas Nieuwenhuizen wrote: > On Fri, Oct 25, 2024 at 11:21 AM Michel Dänzer <mailto:michel.daen...@mailbox.org>> wrote: > > On 2024-10-24 17:08, Marek Olšák wrote: > > We don't need to share the same VMID between ROCm and Mesa. We don't > > need to share the same driver FD between ROCm and Mesa either. It will > > be like having 2 different processes, and that should always work. > > Per > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31756#note_2626236 > <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31756#note_2626236>, > does anything prevent the application from passing the same DRM file > description (doesn't need to be the same *descriptor*) to separate drivers? > (Not sure it can even pass a DRM fd to ROCm, surely can e.g. to radeonsi & > AMDVLK though) > > > In RADV the app has no way to pass in a drm fd, there is only a way to query > the major/minor from the fd > (https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap55.html#VK_EXT_physical_device_drm > > <https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap55.html#VK_EXT_physical_device_drm>). Hmm. So Wayland compositors which use Vulkan have to share BOs from Vulkan into their DRM file description for KMS via dma-buf? How about ROCm, no way to pass in / retrieve a DRM file descriptor there either? > (not to mention that it would mean that any users would need to use > libdrm_amdgpu. Given that the most likely combination of GBM with shared > fd/handle stuff is kernel modesetting and nobody uses libdrm_amdgpu with > that, having a shared libdrm_amdgpu would not help there) Not sure what you mean here, Wayland compositors use radeonsi with KMS. -- Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
Re: libdrm_amdgpu being forked and merged into Mesa
On 2024-10-24 17:08, Marek Olšák wrote: > We don't need to share the same VMID between ROCm and Mesa. We don't > need to share the same driver FD between ROCm and Mesa either. It will > be like having 2 different processes, and that should always work. Per https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31756#note_2626236, does anything prevent the application from passing the same DRM file description (doesn't need to be the same *descriptor*) to separate drivers? (Not sure it can even pass a DRM fd to ROCm, surely can e.g. to radeonsi & AMDVLK though) I guess one way to avoid this issue would be for Mesa to always use a different DRM file description internally, then it would have to share buffers with the DRM file description passed in by the application as needed though. -- Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications
On 2024-10-21 11:20, Derek Lesho wrote: > On 10/21/24 11:08, Michel Dänzer wrote: > >> On 2024-10-18 23:55, Derek Lesho wrote: >>> Hey everyone 👋, >>> >>> I'm Derek from the Wine project, and wanted to start a discussion with >>> y'all about potentially extending the Mesa OGL drivers to help us with a >>> functionality gap we're facing. >>> >>> Problem Space: >>> >>> In the last few years Wine's support for running 32-bit windows apps in a >>> 64-bit host environment (wow64) has almost reached feature completion, but >>> there remains a pain point with OpenGL applications: Namely that Wine can't >>> return a 64-bit GL implementation's buffer mappings to a 32 bit application >>> when the address is outside of the 32-bit range. >>> >>> Currently, we have a workaround that will copy any changes to the mapping >>> back to the host upon glBufferUnmap, but this of course is slow when the >>> implementation directly returns mapped memory, and doesn't work for >>> GL_PERSISTENT_BIT, where directly mapped memory is required. >>> >>> A few years ago we also faced this problem with Vulkan's, which was solved >>> through the VK_EXT_map_memory_placed extension Faith drafted, allowing us >>> to use our Wine-internal allocator to provide the pages the driver maps to. >>> I'm now wondering if an GL equivalent would also be seen as feasible >>> amongst the devs here. >>> >>> Proposed solution: >>> >>> As the GL backend handles host mapping in its own code, only giving >>> suballocations from its mappings back to the App, the problem is a little >>> bit less straight forward in comparison to our Vulkan solution: If we just >>> allowed the application to set its own placed mapping when calling >>> glMapBuffer, the driver might then have to handle moving buffers out of >>> already mapped ranges, and would lose control over its own memory >>> management schemes. >>> >>> Therefore, I propose a GL extension that allows the GL client to provide a >>> mapping and unmapping callback to the implementation, to be used whenever >>> the driver needs to perform such operations. This way the driver remains in >>> full control of its memory management affairs, and the amount of work for >>> an implementation as well as potential for bugs is kept minimal. I've >>> written a draft implementation in Zink using map_memory_placed [1] and a >>> corresponding Wine MR utilizing it [2], and would be curious to hear your >>> thoughts. I don't have experience in the Mesa codebase, so I apologize if >>> the branch is a tad messy. >>> >>> In theory, the only requirement from drivers from the extension would be >>> that glMapBuffer always return a pointer from within a page allocated >>> through the provided callbacks, so that it can be guaranteed to be >>> positioned within the required address space. Wine would then use it's >>> existing workaround for other types of buffers, but as Mesa seems to often >>> return directly mapped buffers in other cases as well, Wine could also >>> avoid the slowdown that comes with copying in these cases as well. >> Does this really require a callback, or could e.g. a "keep >> application-visible mappings within 32-bit range" context flag work? >> >> > Unfortunately that wouldn't be quite enough, as linux-mmap's MAP_32BIT flag > only uses the first 2 GBs of address space, and we need to allow for the use > of all 4GB of address space for apps which have activated the LAA (large > address-space aware) flag in their executable. And Wine's solution for this can't be implemented in Mesa? -- Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications
On 2024-10-18 23:55, Derek Lesho wrote: > Hey everyone 👋, > > I'm Derek from the Wine project, and wanted to start a discussion with y'all > about potentially extending the Mesa OGL drivers to help us with a > functionality gap we're facing. > > Problem Space: > > In the last few years Wine's support for running 32-bit windows apps in a > 64-bit host environment (wow64) has almost reached feature completion, but > there remains a pain point with OpenGL applications: Namely that Wine can't > return a 64-bit GL implementation's buffer mappings to a 32 bit application > when the address is outside of the 32-bit range. > > Currently, we have a workaround that will copy any changes to the mapping > back to the host upon glBufferUnmap, but this of course is slow when the > implementation directly returns mapped memory, and doesn't work for > GL_PERSISTENT_BIT, where directly mapped memory is required. > > A few years ago we also faced this problem with Vulkan's, which was solved > through the VK_EXT_map_memory_placed extension Faith drafted, allowing us to > use our Wine-internal allocator to provide the pages the driver maps to. I'm > now wondering if an GL equivalent would also be seen as feasible amongst the > devs here. > > Proposed solution: > > As the GL backend handles host mapping in its own code, only giving > suballocations from its mappings back to the App, the problem is a little bit > less straight forward in comparison to our Vulkan solution: If we just > allowed the application to set its own placed mapping when calling > glMapBuffer, the driver might then have to handle moving buffers out of > already mapped ranges, and would lose control over its own memory management > schemes. > > Therefore, I propose a GL extension that allows the GL client to provide a > mapping and unmapping callback to the implementation, to be used whenever the > driver needs to perform such operations. This way the driver remains in full > control of its memory management affairs, and the amount of work for an > implementation as well as potential for bugs is kept minimal. I've written a > draft implementation in Zink using map_memory_placed [1] and a corresponding > Wine MR utilizing it [2], and would be curious to hear your thoughts. I don't > have experience in the Mesa codebase, so I apologize if the branch is a tad > messy. > > In theory, the only requirement from drivers from the extension would be that > glMapBuffer always return a pointer from within a page allocated through the > provided callbacks, so that it can be guaranteed to be positioned within the > required address space. Wine would then use it's existing workaround for > other types of buffers, but as Mesa seems to often return directly mapped > buffers in other cases as well, Wine could also avoid the slowdown that comes > with copying in these cases as well. Does this really require a callback, or could e.g. a "keep application-visible mappings within 32-bit range" context flag work? -- Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
Re: Mesa is painful to bisect, I hope this can be improved
On 2024-10-18 01:36, Timur Kristóf wrote: > > It's not clear what your issue is exactly, it seems your problem may be > that you try to build the entirety of Mesa and replace the version in > your system that was shipped by your distro? Or that you bisect between > very old very new versions? I suspect the latter. To put it differently, the further back one needs to go for bisecting, the more likely one is to hit the issues Thomas described. I've certainly hit some of them myself. > My process is having a meson setup configured to build just the driver > I am interested in debugging and then I compile it and install to a > local prefix without replacing the Mesa version shipped by my system. > Then I run the application with that local Mesa version by pointing it > to the Vulkan ICD of that version or setting the relevant environment > variables for OpenGL. This works without affecting the rest of the > system. FWIW, you might not need to even install for this, "meson devenv" allows running apps using the Mesa binaries in a build directory. > Other than that, I think it's normal and expected that the drivers > evolve and some options change. Things that were experimental yesterday > might become default tomorrow; things that were default last week might > become obsolete or even removed. As Thomas points out though, such changes potentially cause pain for people who need to bisect across them. So such changes shouldn't be done lightly but only if the benefits clearly outweigh that pain. -- Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
Re: Does gbm_bo_map() implicitly synchronise?
On 2024-06-24 21:08, James Jones wrote: > FWIW, the NVIDIA binary driver's implementation of gbm_bo_map/unmap() > > 1) Don't do any synchronization against in-flight work. The assumption is > that if the content is going to be read, the API writing the data has > established that coherence. Likewise, if it's going to be written, the API > reading it afterwards does any invalidates or whatever are needed for > coherence. > > 2) We don't blit anything or format convert, because our GBM implementation > has no DMA engine access, and I'd like to keep it that way. Setting up a > DMA-capable driver instance is much more expensive as far as runtime > resources than setting up a simple allocator+mmap driver, at least in our > driver architecture. Our GBM map just does an mmap(), and if it's not linear, > you're not going to be able to interpret the data unless you've read up on > our tiling formats. I'm aware this is different from Mesa, and no one has > complained thus far. I've seen at least one webkitgtk issue report about gbm_bo_map not working as intended with nvidia. gbm_bo_map definitely has to handle tiling, that's one of its main purposes. It also really has to handle implicit synchronization, since there's no GBM API for explicit synchronization. Just doing a direct mmap for gbm_bo_map can be bad for other reasons as well. E.g. if the BO storage is in VRAM and the application does CPU reads, it'll fall down a performance cliff. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: Does gbm_bo_map() implicitly synchronise?
On 2024-06-17 19:18, Pierre Ossman wrote: > 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. Let me revise that statement: It shouldn't be needed, period. If llvmpipe needs it, it should happen as part of gbm_bo_map. (Not sure this is implemented at this time, I'd argue it's a Mesa bug if not though) > It does not (except the driver libgbm loads). We're trying to use this in > Xvnc, so it's all CPU. Mesa's GBM backend (built into libgbm) is essentially a frontend for Gallium drivers. It initializes a suitable driver for the DRM fd passed to gbm_create_device. This could be the GPU HW driver, which might explain why the contents from gnome-shell are displayed correctly (eventually). > We're just trying to make sure the applications can use the full power of the > GPU to render their stuff before handing it over to the X server. :) A note on architecture: Mutter supports running as a headless Wayland compositor, and supports remote desktop (including remote login as of GNOME 46) via gnome-remote-desktop and RDP. This allows both Wayland and X (via Xwayland) clients to run with full HW acceleration. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: Does gbm_bo_map() implicitly synchronise?
On 2024-06-17 17:27, Pierre Ossman wrote: > On 17/06/2024 16:50, Michel Dänzer wrote: >> 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: >>> >>> 1. gbm_bo_import(GBM_BO_USE_RENDERING) >>> 2. gbm_bo_get_fd() >>> 3. Wait for client to request displaying the buffer >>> 4. gbm_bo_map(GBM_BO_TRANSFER_READ) >>> 5. select(fd+1, &fds, NULL, NULL, NULL) >> >> *If* select() is needed, it needs to be before gbm_bo_map(), because the >> latter may perform a blit from the real BO to a staging one for CPU access. >> > > 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. > A recording of the issue is available here, in case the behaviour rings a > bell for anyone: > > http://www.cendio.com/~ossman/dri3/Screencast%20from%202024-06-17%2017-06-50.webm Interesting. Looks like the surroundings (drop shadow region?) of the window move along with it first, then the surroundings get fixed up in the next frame. As far as I know, mutter doesn't move window contents like that on the client side; it always redraws the damaged output region from scratch. So I wonder if the initial move together with surroundings is actually a blit on the X server side (possibly triggered by mutter moving the X window in its function as window manager). And then the surroundings fixing themselves up is the correct output from mutter via DRI3/Present. If so, the issue isn't synchronization, it's that the first blit happens at all. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: Does gbm_bo_map() implicitly synchronise?
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 adding those steps just in case, but unfortunately did not see
>>> an improvement. My order was:
>>>
>>> 1. gbm_bo_import(GBM_BO_USE_RENDERING)
>>> 2. gbm_bo_get_fd()
>>> 3. Wait for client to request displaying the buffer
>>> 4. gbm_bo_map(GBM_BO_TRANSFER_READ)
>>> 5. select(fd+1, &fds, NULL, NULL, NULL)
>> *If* select() is needed, it needs to be before gbm_bo_map(), because the
>> latter may perform a blit from the real BO to a staging one for CPU access.
>
> But don't you then need to wait for the blit to finish?
No, gbm_bo_map() must handle that internally. When it returns, the CPU must see
the correct contents.
>>> 6. ioctl(DMA_BUF_IOCTL_SYNC, &{ .flags = DMA_BUF_SYNC_START |
>>> DMA_BUF_SYNC_READ })
>> gbm_bo_map() should do this internally if needed.
>>
>>
>>> 7. pixman_blt()
>>> 8. gbm_bo_unmap()
>>
>
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
Re: Does gbm_bo_map() implicitly synchronise?
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:
>
> 1. gbm_bo_import(GBM_BO_USE_RENDERING)
> 2. gbm_bo_get_fd()
> 3. Wait for client to request displaying the buffer
> 4. gbm_bo_map(GBM_BO_TRANSFER_READ)
> 5. select(fd+1, &fds, NULL, NULL, NULL)
*If* select() is needed, it needs to be before gbm_bo_map(), because the latter
may perform a blit from the real BO to a staging one for CPU access.
> 6. ioctl(DMA_BUF_IOCTL_SYNC, &{ .flags = DMA_BUF_SYNC_START |
> DMA_BUF_SYNC_READ })
gbm_bo_map() should do this internally if needed.
> 7. pixman_blt()
> 8. gbm_bo_unmap()
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
Re: mesa/kmscube repo at fork limit?
On 7/25/23 00:39, Ralph Campbell wrote: > I tried to forkhttps://gitlab.freedesktop.org/mesa/kmscube.git > <https://gitlab.freedesktop.org/mesa/kmscube.git> > but it just shows a bubble saying "you have reached your project limit" > so I don't see how to submit a merge request. > I have a small change to add a connector_id command line option > to kmscube to select the connector. I could post a patch. > > How should I proceed? See https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home#warning-restrictions-due-to-spam-warning , you need to file a user verification issue. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: glxsync - explicit frame synchronization sample implementation
On 2021-12-30 06:20, Michael Clark wrote: > Dear Mesa Developers, > > I have been using GLFW for tiny cross-platform OpenGL demos for some time but > something that has really been bothering me are the visual artifacts when > resizing windows. Over the last year or so I have made multiple attempts at > solving this issue, digging progressively deeper each time, until spending > the last month researching compositor synchronization protocols, reading > compositor code, and writing this demo as a prelude to figuring out how one > might fix this issue in GLFW or even Chrome. > > I decided that first it might be a good idea to come up with the simplest > possible isolated example comprising of a near complete solution without the > unnecessary complexity of layering for all of the cross-platform > abstractions. It seems to me despite the ease this can be solved with Wayland > EGL, it is still useful, primarily for wider compatibility, to be able to > package X11 GLX applications, which is the window system that I typically use > when targeting Linux with GLFW. > > That brings me to _glxsync_ which is an attempt at creating a minimally > correct implementation of explicit frame synchronization using X11, GLX, > XSync and the latest compositor synchronization protocols [1,2], tested to > work with mutter and GNOME on Xorg or Xwayland. > > - https://github.com/michaeljclark/glxsync/ > > _glxsync_ is an X Windows OpenGL demo app using GLX and XSync extended frame > synchronization responding to synchronization requests from the compositor in > response to configuration changes for window resizes. The demo updates > extended synchronization counters before and after frames to signal to the > compositor that rendering is in progress so that buffers read by the > compositor are complete and matches the size in configuration change events. > It also has rudimentary congestion control. [...] > I have to say there were numerous subtle issues that I found while testing > this code on Ubuntu 21.10 XWayland with an Intel Mesa graphics stack and > Ubuntu 20.04 LTS Xorg with the NVIDIA proprietary graphics stack, so I have > no idea how it will fly with other drivers and am very interested in > feedback. There really is not much sample code that I could find that > addresses this issue. [...] > Is there a place in mesa-demos for a frame synchronization demo? I see > glsync. Is there a compositor sync example that I may have missed? I can > imagine with the addition of WM_MOVERESIZE it could be used for tests. This > is pretty much version 0.0.1. i.e. is clean enough to release. FWIW, GTK4 seems to do a pretty decent job of this (based on casual experimentation with GDK_BACKEND=x11 gtk4-demo i.e. not any kind of scientific investigation). -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
[Mesa-dev] Subject prefix disabled
I've disabled the [Mesa-dev] prefix getting added to the subject of list posts, since it was breaking DKIM signatures, which made it increasingly unlikely for list posts to be delivered normally to subscribers using major e-mail providers. Those who were relying on the prefix for filtering will need to switch e.g. to the List-Id: header (list:mesa-dev.lists.freedesktop.org in gmail). (I manually added the prefix to the subject of this mail, so that it'll match subject based filters) -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: [Mesa-dev] llvmpipe not supporting EGL_EXT_image_dma_buf_import ?
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 as a software renderer it has no kernel driver, so there is no > easy way to implement that. Even if there was, CPU reads from dma-bufs imported from a HW driver may be extremely slow, so they should be avoided other than for specific setups where they're known to be guaranteed to perform adequately. (This performance trap is why I think allowing mmap for dma-buf fds was a mistake) -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: [Mesa-dev] Question about display_gpu and render gpu in dri3_create_screen
On 2021-09-13 14:40, Luc Ma wrote:
> Hello,
>
> I recently tried multi-GPU support on the mesa gallium drivers(glx=dri). When
> I exported the env `DRI_PRIME=1`, I found that it didn't work with two
> different drivers loaded at the same time.
> because there are different driver names in my case. display_gpu driver name
> is "r600" while render_gpu driver name is "nouveau". It failed to create
> display gpu screen
>
> if (strcmp(driverName, driverNameDisplayGPU) == 0) {
> psc->driScreenDisplayGPU =
> psc->image_driver->createNewScreen2(screen,
> psc->fd_display_gpu,
> pdp->loader_extensions,
> extensions,
> &driver_configs, psc);
> }
>
> so I am wondering
>
> - is it possible to use two GPUs from different vendors on a system with
> gallium? one is for display, another for rendering
> - is it possible to use two GPUs driven by a shared driver(say both "r600")
> on a system?
Both should work.
Did you hit a problem other than psc->driScreenDisplayGPU related code being
skipped (as is expected ATM with different drivers)?
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
Re: [Mesa-dev] Linux Graphics Next: Userspace submission update
On 2021-06-01 12:49 p.m., Michel Dänzer wrote: > On 2021-06-01 12:21 p.m., Christian König wrote: > >> Another question is if that is sufficient as security for the display server >> or if we need further handling down the road? I mean essentially we are >> moving the reliability problem into the display server. > > Good question. This should generally protect the display server from freezing > due to client fences never signalling, but there might still be corner cases. E.g. a client might be able to sneak in a fence between when the compositor checks fences and when it submits its drawing to the kernel. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Linux Graphics Next: Userspace submission update
On 2021-06-01 3:18 p.m., Michel Dänzer wrote: > On 2021-06-01 2:10 p.m., 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) 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 >>>>>> solutions to timeouts: >>>>>> >>>>>> a) use a CPU wait with a small absolute timeout, and display the >>>>>> previous content on timeout >>>>>> b) use a GPU wait with a small absolute timeout, and conditional >>>>>> rendering will choose between the latest content (if signalled) and >>>>>> previous content (if timed out) >>>>>> >>>>>> The result would be that the desktop can run close to 60 fps even if an >>>>>> app runs at 1 fps. >>>>> FWIW, this is working with >>>>> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 , even with >>>>> implicit sync (on current Intel GPUs; amdgpu/radeonsi would need to >>>>> provide the same dma-buf poll semantics as other drivers and high >>>>> priority GFX contexts via EGL_IMG_context_priority which can preempt >>>>> lower priority ones). >>>> Yeah, that is really nice to have. >>>> >>>> One question is if you wait on the CPU or the GPU for the new surface to >>>> become available? >>> It's based on polling dma-buf fds, i.e. CPU. >>> >>>> The former is a bit bad for latency and power management. >>> There isn't a choice for Wayland compositors in general, since there can be >>> arbitrary other state which needs to be applied atomically together with >>> the new buffer. (Though in theory, a compositor might get fancy and >>> special-case surface commits which can be handled by waiting on the GPU) >>> >>> Latency is largely a matter of scheduling in the compositor. The latency >>> incurred by the compositor shouldn't have to be more than single-digit >>> milliseconds. (I've seen total latency from when the client starts >>> processing a (static) frame to when it starts being scanned out as low as >>> ~6 ms with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1620, >>> lower than typical with Xorg) >> >> Well let me describe it like this: >> >> We have an use cases for 144 Hz guaranteed refresh rate. That essentially >> means that the client application needs to be able to spit out one >> frame/window content every ~6.9ms. That's tough, but doable. >> >> When you now add 6ms latency in the compositor that means the client >> application has only .9ms left for it's frame which is basically impossible >> to do. > > You misunderstood me. 6 ms is the lowest possible end-to-end latency from > client to scanout, but the client can start as early as it wants/needs to. > It's a trade-off between latency and the risk of missing a scanout cycle. Note that what I wrote above is about the case where the compositor needs to draw its own frame sampling from the client buffer. If your concern is about a fullscreen application for which the compositor can directly use the application buffers for scanout, it should be possible in theory to get the latency incurred by the compositor down to ~1 ms. If that's too much[0], it could be improved further by adding atomic KMS API to replace a pending page flip with another one. Then the compositor could just directly submit a flip as soon as a new buffer becomes ready (or even as soon as the client submits it to the compositor, depending on how exactly the new KMS API works). Then the minimum latency should be mostly up to the kernel driver / HW. Another possibility would be for the application to use KMS directly, e.g. via a DRM lease. That might still require the same new API to get the flip submission latency significantly below 1 ms though. [0] Though I'm not sure how to reconcile that with "spitting out one frame every ~6.9ms is tough", as that means the theoretical minimum total client→scanout latency is ~7 ms (and missing a scanout cycle ~doubles the latency). -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Linux Graphics Next: Userspace submission update
On 2021-06-01 3:01 p.m., Marek Olšák wrote: > > > On Tue., Jun. 1, 2021, 08:51 Christian König, > mailto:ckoenig.leichtzumer...@gmail.com>> > wrote: > > Am 01.06.21 um 14:30 schrieb Daniel Vetter: > > On Tue, Jun 1, 2021 at 2:10 PM Christian König > > <mailto:ckoenig.leichtzumer...@gmail.com>> 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) 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 solutions > to timeouts: > >>>>>> > >>>>>> a) use a CPU wait with a small absolute timeout, and display the > previous content on timeout > >>>>>> b) use a GPU wait with a small absolute timeout, and conditional > rendering will choose between the latest content (if signalled) and previous > content (if timed out) > >>>>>> > >>>>>> The result would be that the desktop can run close to 60 fps even > if an app runs at 1 fps. > >>>>> FWIW, this is working with > >>>>> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 > <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880> , even with > implicit sync (on current Intel GPUs; amdgpu/radeonsi would need to provide > the same dma-buf poll semantics as other drivers and high priority GFX > contexts via EGL_IMG_context_priority which can preempt lower priority ones). > >>>> Yeah, that is really nice to have. > >>>> > >>>> One question is if you wait on the CPU or the GPU for the new > surface to become available? > >>> It's based on polling dma-buf fds, i.e. CPU. > >>> > >>>> The former is a bit bad for latency and power management. > >>> There isn't a choice for Wayland compositors in general, since there > can be arbitrary other state which needs to be applied atomically together > with the new buffer. (Though in theory, a compositor might get fancy and > special-case surface commits which can be handled by waiting on the GPU) > >>> > >>> Latency is largely a matter of scheduling in the compositor. The > latency incurred by the compositor shouldn't have to be more than > single-digit milliseconds. (I've seen total latency from when the client > starts processing a (static) frame to when it starts being scanned out as low > as ~6 ms with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1620 > <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1620>, lower than > typical with Xorg) > >> Well let me describe it like this: > >> > >> We have an use cases for 144 Hz guaranteed refresh rate. That > >> essentially means that the client application needs to be able to spit > >> out one frame/window content every ~6.9ms. That's tough, but doable. > >> > >> When you now add 6ms latency in the compositor that means the client > >> application has only .9ms left for it's frame which is basically > >> impossible to do. > >> > >> See for the user fences handling the display engine will learn to read > >> sequence numbers from memory and decide on it's own if the old frame or > >> the new one is scanned out. To get the latency there as low as > possible. > > This won't work with implicit sync at all. > > > > 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. > > Not sure we want to go there, but it's definitely a lot more feasible > > than trying to stuff eglstreams semantics into dma-buf implicit > > fencing support in a desperate attempt to not change compositors. EGLStreams are a red herring here. Wayland has atomic state transactions, similar to the atomic KMS API. These semantics could be achieved even with EGLStreams, at least via additional EGL extensions. Any fancy technique we're discussing here would have to be completely between the Wayland compositor and the kernel, transparent to anything else. > > I still think the most reasonable appro
Re: [Mesa-dev] Linux Graphics Next: Userspace submission update
On 2021-06-01 2:10 p.m., 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) 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 >>>>> solutions to timeouts: >>>>> >>>>> a) use a CPU wait with a small absolute timeout, and display the previous >>>>> content on timeout >>>>> b) use a GPU wait with a small absolute timeout, and conditional >>>>> rendering will choose between the latest content (if signalled) and >>>>> previous content (if timed out) >>>>> >>>>> The result would be that the desktop can run close to 60 fps even if an >>>>> app runs at 1 fps. >>>> FWIW, this is working with >>>> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 , even with >>>> implicit sync (on current Intel GPUs; amdgpu/radeonsi would need to >>>> provide the same dma-buf poll semantics as other drivers and high priority >>>> GFX contexts via EGL_IMG_context_priority which can preempt lower priority >>>> ones). >>> Yeah, that is really nice to have. >>> >>> One question is if you wait on the CPU or the GPU for the new surface to >>> become available? >> It's based on polling dma-buf fds, i.e. CPU. >> >>> The former is a bit bad for latency and power management. >> There isn't a choice for Wayland compositors in general, since there can be >> arbitrary other state which needs to be applied atomically together with the >> new buffer. (Though in theory, a compositor might get fancy and special-case >> surface commits which can be handled by waiting on the GPU) >> >> Latency is largely a matter of scheduling in the compositor. The latency >> incurred by the compositor shouldn't have to be more than single-digit >> milliseconds. (I've seen total latency from when the client starts >> processing a (static) frame to when it starts being scanned out as low as ~6 >> ms with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1620, lower >> than typical with Xorg) > > Well let me describe it like this: > > We have an use cases for 144 Hz guaranteed refresh rate. That essentially > means that the client application needs to be able to spit out one > frame/window content every ~6.9ms. That's tough, but doable. > > When you now add 6ms latency in the compositor that means the client > application has only .9ms left for it's frame which is basically impossible > to do. You misunderstood me. 6 ms is the lowest possible end-to-end latency from client to scanout, but the client can start as early as it wants/needs to. It's a trade-off between latency and the risk of missing a scanout cycle. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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't >>> trust imported/exported fences. They need a timeout recovery mechanism from >>> the beginning, and the following are some possible solutions to timeouts: >>> >>> a) use a CPU wait with a small absolute timeout, and display the previous >>> content on timeout >>> b) use a GPU wait with a small absolute timeout, and conditional rendering >>> will choose between the latest content (if signalled) and previous content >>> (if timed out) >>> >>> The result would be that the desktop can run close to 60 fps even if an app >>> runs at 1 fps. >> FWIW, this is working with >> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 , even with >> implicit sync (on current Intel GPUs; amdgpu/radeonsi would need to provide >> the same dma-buf poll semantics as other drivers and high priority GFX >> contexts via EGL_IMG_context_priority which can preempt lower priority ones). > > Yeah, that is really nice to have. > > One question is if you wait on the CPU or the GPU for the new surface to > become available? It's based on polling dma-buf fds, i.e. CPU. > The former is a bit bad for latency and power management. There isn't a choice for Wayland compositors in general, since there can be arbitrary other state which needs to be applied atomically together with the new buffer. (Though in theory, a compositor might get fancy and special-case surface commits which can be handled by waiting on the GPU) Latency is largely a matter of scheduling in the compositor. The latency incurred by the compositor shouldn't have to be more than single-digit milliseconds. (I've seen total latency from when the client starts processing a (static) frame to when it starts being scanned out as low as ~6 ms with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1620, lower than typical with Xorg) > Another question is if that is sufficient as security for the display server > or if we need further handling down the road? I mean essentially we are > moving the reliability problem into the display server. Good question. This should generally protect the display server from freezing due to client fences never signalling, but there might still be corner cases. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Linux Graphics Next: Userspace submission update
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 solutions to timeouts: > > a) use a CPU wait with a small absolute timeout, and display the previous > content on timeout > b) use a GPU wait with a small absolute timeout, and conditional rendering > will choose between the latest content (if signalled) and previous content > (if timed out) > > The result would be that the desktop can run close to 60 fps even if an app > runs at 1 fps. FWIW, this is working with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 , even with implicit sync (on current Intel GPUs; amdgpu/radeonsi would need to provide the same dma-buf poll semantics as other drivers and high priority GFX contexts via EGL_IMG_context_priority which can preempt lower priority ones). -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal
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 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, 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 synchronization between device with and >> without user queues any more. >> > >> > That could only be a problem for A+I Laptops. >> >> Since I think you mentioned you'd only be enabling this on newer >> chipsets, won't it be a problem for A+A where one A is a generation >> behind the other? >> > > Crap, that is a good point as well. > >> >> I'm not really liking where this is going btw, seems like a ill >> thought out concept, if AMD is really going down the road of designing >> hw that is currently Linux incompatible, you are going to have to >> accept a big part of the burden in bringing this support in to more >> than just amd drivers for upcoming generations of gpu. >> > > Well we don't really like that either, but we have no other option as far as > I can see. I don't really understand what "future hw may remove support for kernel queues" means exactly. While the per-context queues can be mapped to userspace directly, they don't *have* to be, do they? I.e. the kernel driver should be able to either intercept userspace access to the queues, or in the worst case do it all itself, and provide the existing synchronization semantics as needed? Surely there are resource limits for the per-context queues, so the kernel driver needs to do some kind of virtualization / multi-plexing anyway, or we'll get sad user faces when there's no queue available for . I'm probably missing something though, awaiting enlightenment. :) -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] libGL not build but opengl=true option is set
On 2021-03-12 7:46 p.m., Quentin SCHIBLER wrote: > GLVND depends on several X librairies. Even if you build libglvnd with -Dx11=disabled ? -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] libGL not build but opengl=true option is set
On 2021-03-11 12:14 a.m., Quentin SCHIBLER wrote: > I have built mesa with wayland platform, gbm and egl enabled, glx disabled, > gles1 disabled and gles2 enabled. > The build is successful, but I cannot find libGL.so. libGLES2.so is present, > and GL includes files are also present. libGL includes GLX APIs, so it cannot be built with -Dglx=false. If you want to avoid GLX, you can use GLVND's libOpenGL instead. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Perfetto CPU/GPU tracing
On 2021-02-13 3:15 a.m., Dylan Baker wrote: I can't speak for anyone else, but a giant pile of vendored code that you're expected to not update seems like a really bad idea to me. I agree. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
On 2021-02-02 5:55 p.m., Michel Dänzer wrote: On 2021-02-02 6:44 a.m., Dave Airlie wrote: On Mon, 1 Feb 2021 at 16:50, Dave Airlie wrote: On Thu, 7 Jan 2021 at 21:11, Andreas Fänger wrote: don’t know why the current softpipe/swrast implementation shouldn’t be conformant. Interesting I hadn't known we had a correct impl in mesa, the features.txt has said "softpipe and llvmpipe advertise 16x anisotropy but simply ignore the setting" so I never dug any deeper. I'll consider a port of this to llvmpipe at some point, making it efficient might be tricky. It seems that features.txt hasn't been updated regarding this functionality; softpipe has "real" anisotropy since 2011. I'll consider a port of this to llvmpipe at some point, making it efficient might be tricky. That would be great. As anisotropic filtering is often an option which can be set by a user, I guess most people turn it off to get higher framerates. But in our use case, high quality renderings are required, so we accept the longer render times to get the best quality; hopefully a llvmpipe port would be faster than the old swrast implementation (we are only using the fixed rendering pipeline/no shaders in conjunction with the OpenMP patch for speeding up GL_POLYGON_SMOOTH_HINT) Andreas https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804 Is my first pass at writing the code for this I've no idea if this is anyway correct, but I'm just letting everyone know I've started working on it, and mipmap_tunnel doesn't look immediately wrong. Olay the code in the MR above seems to work in most cases now and seems to operate like softpipe. However I'm seeing a trace failure https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/humus/Portals.trace/ The floor at the bottom left of the Actual image definitely looks odd, there's a hard line between the rock patterns. Not to mention the wall tiles having different sizes, with a hard line as well. Definitely looks like a bug to me, which wouldn't be noticeable with special test textures made up of different solid colours per mip level. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
On 2021-02-02 6:44 a.m., Dave Airlie wrote: On Mon, 1 Feb 2021 at 16:50, Dave Airlie wrote: On Thu, 7 Jan 2021 at 21:11, Andreas Fänger wrote: don’t know why the current softpipe/swrast implementation shouldn’t be conformant. Interesting I hadn't known we had a correct impl in mesa, the features.txt has said "softpipe and llvmpipe advertise 16x anisotropy but simply ignore the setting" so I never dug any deeper. I'll consider a port of this to llvmpipe at some point, making it efficient might be tricky. It seems that features.txt hasn't been updated regarding this functionality; softpipe has "real" anisotropy since 2011. I'll consider a port of this to llvmpipe at some point, making it efficient might be tricky. That would be great. As anisotropic filtering is often an option which can be set by a user, I guess most people turn it off to get higher framerates. But in our use case, high quality renderings are required, so we accept the longer render times to get the best quality; hopefully a llvmpipe port would be faster than the old swrast implementation (we are only using the fixed rendering pipeline/no shaders in conjunction with the OpenMP patch for speeding up GL_POLYGON_SMOOTH_HINT) Andreas https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804 Is my first pass at writing the code for this I've no idea if this is anyway correct, but I'm just letting everyone know I've started working on it, and mipmap_tunnel doesn't look immediately wrong. Olay the code in the MR above seems to work in most cases now and seems to operate like softpipe. However I'm seeing a trace failure https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/humus/Portals.trace/ The floor at the bottom left of the Actual image definitely looks odd, there's a hard line between the rock patterns. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Dmabuf based render buffers!?
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 gl with shaders, on the cpu. Iv’e been told that on the Raspberry Pi OpenGL is sharing the same memory as the cpu so I’m hoping it would be possible to do something like a dmabuf on the ‘way out’ too? Does anyone have any pointers in how this could work? I'd recommend using glGetTexImage or other similar GL APIs for getting the data out of the GL texture. While mmap of a dma-buf file descriptor works in theory, direct CPU reads from GPU accessible memory can be very slow on some platforms. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [BUG] Large slowdown with RADV / Warcraft with latest Mesa from Git.
On 2021-01-08 6:16 p.m., Michel Dänzer wrote: On 2021-01-08 5:54 p.m., Chris Rankin wrote: Hi, I've just noticed a large drop in FPS (from 60 down to 15) when playing World of Warcraft with the latest Mesa from Git. A quick git bisect has identified this commit: 4292fb2139282e6906d4ad2a8be2fd81ed7ca8af is the first bad commit commit 4292fb2139282e6906d4ad2a8be2fd81ed7ca8af Author: Michel Dänzer Date: Mon Dec 21 15:41:56 2020 +0100 wsi/x11: Use PresentOptionAsync for MAILBOX present mode with Xwayland This allows Xwayland to forward buffers to the Wayland compositor ASAP for fullscreen / undecorated windows, which in turn allows true mailbox behaviour in the Wayland compositor. Without this, Xwayland has to emulate the mailbox behaviour itself, which it cannot do as well as the Wayland compositor by design. Reviewed-by: Bas Nieuwenhuizen Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8197> src/vulkan/wsi/wsi_common_x11.c | 7 +++ 1 file changed, 7 insertions(+) I am playing WoW with this release of Wine: wine-6.0-0.4rc4.fc33.x86_64 And this version of DXVK: wine-dxvk-1.7.2-3.fc33.x86_64 Curiously, I am using Xorg rather than Wayland, and so don't understand why this commit should affect me. Does the attached patch fix it? Actually, that would only make a difference if your X server didn't support the RANDR extension, which seems unlikely. I found two more bugs: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8393 Still not sure how that could have caused a drop from 60 to 15 fps, but hopefully this will fix it. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [BUG] Large slowdown with RADV / Warcraft with latest Mesa from Git.
On 2021-01-08 5:54 p.m., Chris Rankin wrote:
Hi,
I've just noticed a large drop in FPS (from 60 down to 15) when playing World
of Warcraft with the latest Mesa from Git.
A quick git bisect has identified this commit:
4292fb2139282e6906d4ad2a8be2fd81ed7ca8af is the first bad commit
commit 4292fb2139282e6906d4ad2a8be2fd81ed7ca8af
Author: Michel Dänzer
Date: Mon Dec 21 15:41:56 2020 +0100
wsi/x11: Use PresentOptionAsync for MAILBOX present mode with Xwayland
This allows Xwayland to forward buffers to the Wayland compositor ASAP
for fullscreen / undecorated windows, which in turn allows true mailbox
behaviour in the Wayland compositor.
Without this, Xwayland has to emulate the mailbox behaviour itself,
which it cannot do as well as the Wayland compositor by design.
Reviewed-by: Bas Nieuwenhuizen
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8197>
src/vulkan/wsi/wsi_common_x11.c | 7 +++
1 file changed, 7 insertions(+)
I am playing WoW with this release of Wine:
wine-6.0-0.4rc4.fc33.x86_64
And this version of DXVK:
wine-dxvk-1.7.2-3.fc33.x86_64
Curiously, I am using Xorg rather than Wayland, and so don't understand why
this commit should affect me.
Does the attached patch fix it?
P.S. Mesa uses GitLab issues for bug tracking now:
https://gitlab.freedesktop.org/mesa/mesa/-/issues
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c
index dcad48ca612..f204e329338 100644
--- a/src/vulkan/wsi/wsi_common_x11.c
+++ b/src/vulkan/wsi/wsi_common_x11.c
@@ -236,9 +236,9 @@ wsi_x11_connection_create(struct wsi_device *wsi_dev,
#endif
if (randr_reply && randr_reply->present != 0)
- {
wsi_conn->is_xwayland = wsi_x11_detect_xwayland(conn);
- }
+ else
+ wsi_conn->is_xwayland = false;
wsi_conn->has_dri3_modifiers = has_dri3_v1_2 && has_present_v1_2;
wsi_conn->is_proprietary_x11 = false;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [AppVeyor] mesa staging/20.3 #20 failed
On 2020-11-26 12:41 p.m., Jose Fonseca wrote: Yes, master builds are currently failing but they won't stay like that for long. Several folks here are on PTO with due to Thanksgiving in US but we should get to it afterwards. As long as the MSVC build isn't tested in pre-merge CI, it'll keep breaking. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [AppVeyor] mesa staging/20.3 #20 failed
On 2020-11-25 8:00 p.m., Jose Fonseca wrote: FYI, I've just recently re-connected Appveyor, after noticing that AppVeyor integration got broken for 6 months, and that Mesa MSVC builds got broken for two months. The best way to prevent this from happening would be to get the MSVC build job working again in the GitLab CI pipeline. (It was disabled 3 months ago due to runner reliability issues, see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6495) At any rate, notifications are setup to notify only when build changes state (pass <-> fail) so hopefully it won't spam the list, even on branches (such as 20.3) where MSVC stays broken. If that doesn't work I can always drop mesa-dev from the list. Personally I find the failed master jobs on https://gitlab.freedesktop.org/mesa/mesa/pipelines more annoying. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rust drivers in Mesa
On 2020-10-04 11:00 p.m., Marek Olšák wrote: 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. I've been a Mesa developer for almost two decades, but I don't really know any Python. I'm really excited that people are starting to look into taking advantage of Rust in Mesa! -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rename "master" branch to "main"?
On 2020-08-03 6:15 p.m., Jason Ekstrand wrote: > On Mon, Aug 3, 2020 at 11:12 AM Kenneth Graunke wrote: >> >> Seems reasonable to me...in the old Subversion days, we called it >> 'trunk'...then 'master' with Git...but calling the main development >> branch 'main' is arguably the simplest and most descriptive term. >> >> One thing we'll have to coordinate: getting Gitlab CI / Marge and the >> Intel Mesa CI to switch over at the right time, so we don't end up >> breaking/interrupting those services. Should be easy, just requires >> a bit of coordination. > > Yup, I threw Daniel onto the CC of this e-mail explicitly for that > reason. We may also want to coordinate with the rest of fd.o so that > everyone chooses the same new mainline branch name. I just added > Michel to the CC as he's doing lots of CI stuff and might be a good > person to help coordinate there. AFAICT only the '$CI_COMMIT_REF_NAME == "master"' test in the .gitlab-ci.yml "pages" job definition needs to be extended / changed to cover the new branch name as well / instead. Other than that, no changes should be necessary for Marge or GitLab CI in general. (Failure to adapt the pages job means the public website wouldn't get updated to reflect changes in the tree) -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] postmortem: arm64_test job timeouts today
On 2020-07-18 2:11 a.m., Eric Anholt wrote: > > - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5669 would > give us twice the -j flags for our builds on fd.o's x86 runners (such > as for the arm64_test job) Landing this should be straightforward. > However, I have no solution for the general problem of "users can > merge code that causes failing container builds for others." Could we > make ci-templates not use registry-cached containers in marge-bot > pipelines, You mean something like https://gitlab.freedesktop.org/freedesktop/ci-templates/-/issues/14#note_571088 ? > and then replicate the image up to mesa/mesa somehow? This would require ci-templates enforcing that the image in the forked registry is up to date when merging. That was my original idea for the ci-templates issue above, but there was resistance. Maybe the benefit of not having to rebuild the image in the main project as well could change things though. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
On 2020-06-24 5:19 p.m., Keith Packard wrote: > Michel Dänzer writes: > >> I assume 2. refers to the case of a single late frame, where the >> next frame hitting the original absolute target would result in a >> second visible stutter. While writing >> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/22#note_548234 >> >> , it occurred to me that although a relative target time may avoid >> that second stutter, the audio stream needs to adapt to the >> visual delay, likely producing audible artifacts instead? It's >> not obvious to me that would be an overall win. (The only other >> way I can think of is to re-synchronize later frames to the audio >> stream, but it's not clear that this is possible without either >> producing visible stutter again, or de-synced audio/video for a >> noticeable period of time) > > I think the idea is that the application would interpolate time > values in the video stream to bring it back in sync with the > expected time over a couple of frames. I think we could easily > construct a demo which shows the difference and see what we think. Such a demo could be very helpful! > I think we could ignore the audio stream as a 16ms lag between > audio and video shouldn't be a big deal; we handle that in real > life quite easily as that's the lag you get at a distance of about > 5m. I suspect it may not be quite that simple, e.g. the brain may compensate for the distance determined from vision. :) Anyway, it's plausible that this can be ignored. >> P.S. Have you more formally proposed a Vulkan extension in the >> meantime? If so, could you provide a reference to that here? > > No. If I had, the IP restrictions with Khronos would prevent me > from discussing it here in any technical detail. Ah, didn't mean to put you in a difficult position. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
On 2020-02-02 7:51 a.m., Keith Packard wrote: > > I spent some time over the last week experimenting with a different > way of doing frame timing. > > Instead of specifying *when* a particular frame should be > displayed, how about we specify how *long* a particular frame > should be made visible to the user? > > This has a couple of advantages over the approach taken in > GOOGLE_display_timing: > > 1. It provides information to the backend about frame timing a > frame earlier. > > 2. Missing a frame can generate fewer artifacts. I assume 2. refers to the case of a single late frame, where the next frame hitting the original absolute target would result in a second visible stutter. While writing https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/22#note_548234 , it occurred to me that although a relative target time may avoid that second stutter, the audio stream needs to adapt to the visual delay, likely producing audible artifacts instead? It's not obvious to me that would be an overall win. (The only other way I can think of is to re-synchronize later frames to the audio stream, but it's not clear that this is possible without either producing visible stutter again, or de-synced audio/video for a noticeable period of time) P.S. Have you more formally proposed a Vulkan extension in the meantime? If so, could you provide a reference to that here? -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vulkan/wsi: Avoid waiting indefinitely for present completion in x11_manage_fifo_queues().
[ Resurrecting an old thread... ]
On 2017-10-24 8:24 p.m., Henri Verbeet wrote:
> On 24 October 2017 at 20:13, Fredrik Höglund wrote:
>> On Tuesday 24 October 2017, Henri Verbeet wrote:
>>> On 24 October 2017 at 16:11, Fredrik Höglund wrote:
>>>>> @@ -934,9 +938,18 @@ x11_manage_fifo_queues(void *state)
>>>>>
>>>>>while (chain->last_present_msc < target_msc) {
>>>>> xcb_generic_event_t *event =
>>>>> -xcb_wait_for_special_event(chain->conn,
>>>>> chain->special_event);
>>>>> - if (!event)
>>>>> -goto fail;
>>>>> +xcb_poll_for_special_event(chain->conn,
>>>>> chain->special_event);
>>>>> + if (!event) {
>>>>> +int ret = poll(&pfds, 1, 100);
>>>>
>>>> There is a race condition here where another thread can read the event
>>>> from the file descriptor in the time between the calls to
>>>> xcb_poll_for_special_event() and poll().
>>>>
>>> Is that a scenario we care about? Unless I'm misunderstanding
>>> something, the same kind of thing could happen between
>>> x11_present_to_x11() and xcb_wait_for_special_event().
>>
>> It cannot, because if another thread reads a special event, xcb will
>> insert it into the corresponding special event queue and wake the
>> waiting thread. That's the point of having special event queues.
>>
>> But the reason I know this to be a problem is that I have tried to fix
>> this bug in the same way, and I noticed that it resulted in frequent
>> random stutters in some apps because poll() was timing out.
>>
> Oh, I think I see what you mean. The event wouldn't get lost, but we'd
> have to wait for the poll to timeout to get to it because it's already
> read from the fd into the queue.
One way to address this is as in
src/loader/loader_dri3_helper.c:dri3_wait_for_event_locked: the first
thread to enter waits for and processes a special event, then wakes up
other threads which have entered in the meantime.
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5368 is my
proposed solution for the same issue in dri3_wait_for_event_locked. (In
contrast to this patch, it explicitly checks if the window still exists
and only bails early if it doesn't)
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa git and LLVM git (11) compilation trouble - LLVMFixedVectorTypeKind now undeclared
On 2020-05-19 4:19 a.m., Dieter Nützel wrote: > Hello Marek, Jan, Karol et al., > > I'm hunting a radeonsi (Polaris 20) Mesa git / LVVM 11 regression and > current LLVM git code can't compile SPIRV-LLVM-Translator any longer and > LLVM 11 without the former installed can't compile > src/amd/llvm/ac_nir_to_llvm.c any more... See https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5087 . -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] mesa 20.0.5
On 2020-04-24 6:14 p.m., Denys wrote: > > Aslo, @Mark, in your last reply I saw that you asked about "parsing" > merge-requests and comments/issues. If I understood the problem > correctly, you may try my approach. > > I am using Thunderbird, and created 2 filters for pattern "Subject > contains" (doesn't work directly in Gmail filters...) : > > 1. (# =>>> this one is parsing Issues and Comments > > 2. (! =>>> this one is parsing Merge requests only FWIW, e-mails from GitLab have a bunch of X-GitLab-* headers which can be useful for filtering. E.g. issues have X-GitLab-Issue-ID: and MRs have X-GitLab-MergeRequest-ID: -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] mesa 20.0.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2020-04-23 6:56 p.m., Dylan Baker wrote: > Quoting Michel Dänzer (2020-04-23 09:24:45) >> On 2020-04-23 6:19 p.m., Mark Janes wrote: >>> Michel Dänzer writes: >>>> On 2020-04-23 5:14 p.m., Mark Janes wrote: >>>>> >>>>> Does anyone have recommendations for how to use Gitlab to >>>>> verify that there are no identified-but-unfixed bugs in a >>>>> pending release? >>>> >>>> I'd say GitLab milestones could be used to address the issues >>>> you raised above: Create a milestone for each release, and >>>> only cut the release once all issues and MRs assigned to it >>>> have been dealt with. >>> >>> Milestones have been used to track progress toward recent >>> releases. It is non-trivial to audit all open bugs to >>> determine which ones must be assigned to a milestone. Bugs are >>> opened long before milestones are created. >> >> Of course there are more complicated cases, but the particular >> case which spawned this thread should have been pretty >> straightforward to handle with a 20.0.5 milestone. > > Indeed, I like the milestone approach and I've gone ahead and > created the milestone. And I set it as the milestone for Danylo's issue & MR. One gotcha is that both of these will show up as completed/closed/merged on the milestone once the MR is merged to master. At least in some cases it might be better to make a separate MR for the stable staging branch and set the milestone on that as well, to make sure they stay on the radar until the fix is on the stable branch. - -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer -BEGIN PGP SIGNATURE- iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXqKhIwAKCRBaga+Oatuy AJaSAKCsKxCMp+EXfnlTjFd9uwwBDga0FwCgstcb+B5OwOfGTheQArey5W8kH3s= =OLqq -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] mesa 20.0.5
On 2020-04-23 8:37 p.m., Mark Janes wrote: > > The majority of stable point releases will have zero issues in a > release milestone. Opening/closing empty milestones all the time is a > lot of busy work. If a few clicks & keystrokes is really "a lot of busy work", only creating a milestone when actually needed is fine. The important part is that the stable manager actually checks the milestone before cutting the release. > Milestones are helpful for *initial* releases of stable branches, not > point releases. Even for initial releases important use cases for > milestones are not supported by gitlab. As an example, we may be able > to verify that a specific test is regressed with an A/B test of the > previous release -- and perhaps identify the commit that regressed it. > How can we find if an issue exists for this test? You cannot: > > - search for issues mentioning a test name (unless it is in the title) https://gitlab.freedesktop.org/mesa/mesa/-/issues?scope=all&utf8=%E2%9C%93&state=opened&search=test lists issues without "test" in the title, so this doesn't seem quite as bad as you're making it. > - search for issues mentioning a commit https://gitlab.freedesktop.org/mesa/mesa/-/issues?scope=all&utf8=%E2%9C%93&state=opened&search=76dbcb1f5e48e10467b15a0e19232eccc3a57ae3 seems to work? > - subscribe to issue comments in a way that would let you search >offline On https://gitlab.freedesktop.org/mesa/mesa (or its parent page, for the whole Mesa group of projects) click the drop-down next to the notification bell, select "Custom" and check the "New note" box, then you get an e-mail for every comment on every issue & MR. (One gotcha is that an e-mail is only sent for the original comment, not for any edits. Therefore, it's better to only edit comments for minor fixups) -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] mesa 20.0.5
On 2020-04-23 6:19 p.m., Mark Janes wrote: > Michel Dänzer writes: >> On 2020-04-23 5:14 p.m., Mark Janes wrote: >>> >>> Does anyone have recommendations for how to use Gitlab to verify that >>> there are no identified-but-unfixed bugs in a pending release? >> >> I'd say GitLab milestones could be used to address the issues you raised >> above: Create a milestone for each release, and only cut the release >> once all issues and MRs assigned to it have been dealt with. > > Milestones have been used to track progress toward recent releases. It > is non-trivial to audit all open bugs to determine which ones must be > assigned to a milestone. Bugs are opened long before milestones are > created. Of course there are more complicated cases, but the particular case which spawned this thread should have been pretty straightforward to handle with a 20.0.5 milestone. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] mesa 20.0.5
On 2020-04-23 5:14 p.m., Mark Janes wrote: > Danylo Piliaiev writes: > > 3a) Bisected regressions tagged with Fixes or mesa-stable are > automatically applied to Mesa's release branch. > > This failure point has burned us many times, most recently with the 20.0 > regression fixed by 2120f106e0e. > > Mesa currently has no mechanism for blocking a release with a gitlab > issue. This current example is tagged with "bisected" and "regression", > but the important distinction is that the bisected commit ALSO has tags > which apply it to stable releases. > > Mesa's release process does not include a check of bugs that have been > written up in gitlab (https://www.mesa3d.org/releasing.html). My own > opinion is that gitlab's issues are unusable for this purpose, due to > its lack of search functionality. I have found no way to audit gitlab > issues leading up to a release. > > Gitlab's issues may work well for developing on master, but they are not > as good as Bugzilla for managing releases. > >> 4) I didn't know about this release and that this release was help up >> for the fix of 2758. >> 5) There were now window between announcing the scope of the release and >> release itself. Since I knew about regression >> I could have notified about it. Also there is no milestone for minor >> releases so it's problematic to link issue and release. >> >> It's a second release in a row with clear regression crept in. I believe >> that we can use this to improve the process and >> safeguard against such regressions in the future. > > Does anyone have recommendations for how to use Gitlab to verify that > there are no identified-but-unfixed bugs in a pending release? I'd say GitLab milestones could be used to address the issues you raised above: Create a milestone for each release, and only cut the release once all issues and MRs assigned to it have been dealt with. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Changes to how GitLab merge request CI pipelines work
I had https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 merged yesterday, so now the CI pipeline jobs only run by default if the pipeline was triggered by Marge Bot. Otherwise, they can be triggered manually, similarly to how non-MR pipelines have been working for some time already. This normally shouldn't change anything for merging an MR, since Marge generally needs to rebase the source branch first, in which case the pipeline is triggered by her and runs automatically as before. The motivation for this change was to cut down the resource usage for the CI pipeline and corresponding cost. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gitlab.fd.o financial situation and impact on services
On 2020-04-06 6:34 p.m., Rob Clark wrote: > > The ideal thing would be to be able to click any jobs that we want to > run, say "arm64_a630_gles31", and for gitlab to realize that it needs > to automatically trigger dependencies of that job (meson-arm64, and > arm_build+arm_test). But not sure if that is a thing gitlab can do. Not that I know of. The dependency handling is still pretty rudimentary in general. > Triggering just the first container jobs and having everything from > there run automatically would be ok if the current rules to filter out > unneeded jobs still apply, ie. a panfrost change isn't triggering > freedreno CI jobs and visa versa. But tbh I don't understand enough > of what that MR is doing to understand if that is what it does. (It > was suggested on IRC that this is probably what it does.) It is. Filtered jobs don't exist at all in the pipeline, so they can't be triggered by any means. :) -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On 2020-03-01 6:46 a.m., Marek Olšák wrote: > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > pre-merge CI. Thanks for the suggestion! I implemented something like this for Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Drop scons for 20.1?
On 2020-03-27 2:29 p.m., Jose Fonseca wrote: > > If SCons is such a time sink, then the best we can do is suggest to > take it off Marge-bot. That would be something like https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4352 then. > The onus of fixing SCons will go back to us, as it always did > throughout these the past twelve years. Not for the last year or so, when it's been part of the pre-merge CI pipeline? -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
On 2020-03-19 8:54 p.m., Marek Olšák wrote: > On Thu., Mar. 19, 2020, 06:51 Daniel Vetter, > wrote: >> >> Yeah, this is entirely about the programming model visible to >> userspace. There shouldn't be any impact on the driver's choice of >> a top vs. bottom of the gpu pipeline used for synchronization, >> that's entirely up to what you're hw/driver/scheduler can pull >> off. >> >> Doing a full gfx pipeline flush for shared buffers, when your hw >> can do be, sounds like an issue to me that's not related to this >> here at all. It might be intertwined with amdgpu's special >> interpretation of dma_resv fences though, no idea. We might need to >> revamp all that. But for a userspace client that does nothing fancy >> (no multiple render buffer targets in one bo, or vk style "I write >> to everything all the time, perhaps" stuff) there should be 0 perf >> difference between implicit sync through dma_resv and explicit sync >> through sync_file/syncobj/dma_fence directly. >> >> If there is I'd consider that a bit a driver bug. > > Last time I checked, there was no fence sync in gnome shell and > compiz after an app passes a buffer to it. They are not required (though encouraged) to do that. > So drivers have to invent hacks to work around it and decrease > performance. It's not a driver bug. > > Implicit sync really means that apps and compositors don't sync, so > the driver has to guess when it should sync. Making implicit sync work correctly is ultimately the kernel driver's responsibility. It sounds like radeonsi is having to work around the amdgpu/radeon kernel driver(s) not fully living up to this responsibility. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
On 2020-03-17 6:21 p.m., Lucas Stach wrote: > That's one of the issues with implicit sync that explicit may solve: > a single client taking way too much time to render something can > block the whole pipeline up until the display flip. With explicit > sync the compositor can just decide to use the last client buffer if > the latest buffer isn't ready by some deadline. FWIW, the compositor can do this with implicit sync as well, by polling a dma-buf fd for the buffer. (Currently, it has to poll for writable, because waiting for the exclusive fence only isn't enough with amdgpu) -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
On 2020-03-16 7:33 p.m., Marek Olšák wrote: > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer wrote: >> On 2020-03-16 4:50 a.m., Marek Olšák wrote: >>> The synchronization works because the Mesa driver waits for idle (drains >>> the GFX pipeline) at the end of command buffers and there is only 1 >>> graphics queue, so everything is ordered. >>> >>> The GFX pipeline runs asynchronously to the command buffer, meaning the >>> command buffer only starts draws and doesn't wait for completion. If the >>> Mesa driver didn't wait at the end of the command buffer, the command >>> buffer would finish and a different process could start execution of its >>> own command buffer while shaders of the previous process are still >> running. >>> >>> If the Mesa driver submits a command buffer internally (because it's >> full), >>> it doesn't wait, so the GFX pipeline doesn't notice that a command buffer >>> ended and a new one started. >>> >>> The waiting at the end of command buffers happens only when the flush is >>> external (Swap buffers, glFlush). >>> >>> It's a performance problem, because the GFX queue is blocked until the >> GFX >>> pipeline is drained at the end of every frame at least. >>> >>> So explicit fences for SwapBuffers would help. >> >> Not sure what difference it would make, since the same thing needs to be >> done for explicit fences as well, doesn't it? > > No. Explicit fences don't require userspace to wait for idle in the command > buffer. Fences are signalled when the last draw is complete and caches are > flushed. Before that happens, any command buffer that is not dependent on > the fence can start execution. There is never a need for the GPU to be idle > if there is enough independent work to do. I don't think explicit fences in the context of this discussion imply using that different fence signalling mechanism though. My understanding is that the API proposed by Jason allows implicit fences to be used as explicit ones and vice versa, so presumably they have to use the same signalling mechanism. Anyway, maybe the different fence signalling mechanism you describe could be used by the amdgpu kernel driver in general, then Mesa could drop the waits for idle and get the benefits with implicit sync as well? -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
On 2020-03-16 4:50 a.m., Marek Olšák wrote: > The synchronization works because the Mesa driver waits for idle (drains > the GFX pipeline) at the end of command buffers and there is only 1 > graphics queue, so everything is ordered. > > The GFX pipeline runs asynchronously to the command buffer, meaning the > command buffer only starts draws and doesn't wait for completion. If the > Mesa driver didn't wait at the end of the command buffer, the command > buffer would finish and a different process could start execution of its > own command buffer while shaders of the previous process are still running. > > If the Mesa driver submits a command buffer internally (because it's full), > it doesn't wait, so the GFX pipeline doesn't notice that a command buffer > ended and a new one started. > > The waiting at the end of command buffers happens only when the flush is > external (Swap buffers, glFlush). > > It's a performance problem, because the GFX queue is blocked until the GFX > pipeline is drained at the end of every frame at least. > > So explicit fences for SwapBuffers would help. Not sure what difference it would make, since the same thing needs to be done for explicit fences as well, doesn't it? -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On 2020-02-29 8:46 p.m., Nicolas Dufresne wrote: > Le samedi 29 février 2020 à 19:14 +0100, Timur Kristóf a écrit : >> >> 1. I think we should completely disable running the CI on MRs which are >> marked WIP. Speaking from personal experience, I usually make a lot of >> changes to my MRs before they are merged, so it is a waste of CI >> resources. Interesting idea, do you want to create an MR implementing it? > In the mean time, you can help by taking the habit to use: > > git push -o ci.skip That breaks Marge Bot. > Notably, we would like to get rid of the post merge CI, as in a rebase > flow like we have in GStreamer, it's a really minor risk. That should be pretty easy, see Mesa and https://docs.gitlab.com/ce/ci/variables/predefined_variables.html. Something like this should work: rules: - if: '$CI_PROJECT_NAMESPACE != "gstreamer"' when: never This is another interesting idea we could consider for Mesa as well. It would however require (mostly) banning direct pushes to the main repository. >> 2. Maybe we could take this one step further and only allow the CI to >> be only triggered manually instead of automatically on every push. That would again break Marge Bot. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On 2020-02-28 12:02 p.m., Erik Faye-Lund wrote: > On Fri, 2020-02-28 at 10:43 +, Daniel Stone wrote: >> On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund >> wrote: >>> On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote: >>>> Yeah, changes on vulkan drivers or backend compilers should be >>>> fairly >>>> sandboxed. >>>> >>>> We also have tools that only work for intel stuff, that should >>>> never >>>> trigger anything on other people's HW. >>>> >>>> Could something be worked out using the tags? >>> >>> I think so! We have the pre-defined environment variable >>> CI_MERGE_REQUEST_LABELS, and we can do variable conditions: >>> >>> https://docs.gitlab.com/ee/ci/yaml/#onlyvariablesexceptvariables >>> >>> That sounds like a pretty neat middle-ground to me. I just hope >>> that >>> new pipelines are triggered if new labels are added, because not >>> everyone is allowed to set labels, and sometimes people forget... >> >> There's also this which is somewhat more robust: >> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569 > > I'm not sure it's more robust, but yeah that a useful tool too. > > The reason I'm skeptical about the robustness is that we'll miss > testing if this misses a path. Surely missing a path will be less likely / often to happen compared to an MR missing a label. (Users which aren't members of the project can't even set labels for an MR) -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote: > > We could also do stuff like reducing the amount of tests we run on each > commit, and punt some testing to a per-weekend test-run or someting > like that. We don't *need* to know about every problem up front, just > the stuff that's about to be released, really. The other stuff is just > nice to have. If it's too expensive, I would say drop it. I don't agree that pre-merge testing is just nice to have. A problem which is only caught after it lands in mainline has a much bigger impact than one which is already caught earlier. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Drop scons for 20.1?
On 2020-02-26 4:56 a.m., Rob Clark wrote: > It looks like we have 4 scons build jobs in CI.. I'm not sure how much > that costs us, but I guess those cycles could be put to better use? > So even ignoring the developer-cycles issue (ie. someone making > changes that effects scons build, and has to setup a scons build env > to fix breakage of their MR) I guess there is at least an argument to > remove scons from CI. Whether it is worth keeping a dead build system > after it is removed from CI is an issue that I'm ambivalent about. As long as it's supported, it needs to be tested in CI. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2020-02-02 7:51 a.m., Keith Packard wrote:
>
> I spent some time over the last week experimenting with a different
> way of doing frame timing.
>
> Instead of specifying *when* a particular frame should be
> displayed, how about we specify how *long* a particular frame
> should be made visible to the user?
>
> This has a couple of advantages over the approach taken in
> GOOGLE_display_timing:
>
> 1. It provides information to the backend about frame timing a
> frame earlier.
>
> 2. Missing a frame can generate fewer artifacts.
>
> Here's what I'm thinking the extension would look like:
>
> An application uses VK_MESA_present_period by including a
> VkPresentPeriodMESA structure in the pNext chain in the
> VkPresentInfoKHR structure passed to the vkQueuePresentKHR call.
>
> typedef struct VkPresentPeriodMESA { VkStructureTypesType;
> const void*pNext; uint32_t swapchainCount; const
> int64_t* pPresentPeriods; } VkPresentPeriodMESA;
>
> The fields in this structure are:
>
> * sType. Set to VK_STRUCTURE_TYPE_PRESENT_PERIOD_MESA * pNext.
> Points to the next extension structure in the chain (if any). *
> swapchainCount. A copy of the swapchainCount field in the
> VkPresentInfoKHR structure. * pPresentPeriods. An array, length
> swapchainCount, of presentation periods for each image in the
> call.
>
> Positive presentation periods represent nanoseconds. Negative
> presentation periods represent frames. A zero value means the
> extension does not affect the associated presentation. Nanosecond
> values are rounded to the nearest upcoming frame so that a value of
> n * refresh_interval is the same as using a value of n frames.
>
> The presentation period causes *future* images to be delayed at
> least until the specified interval after this image has been
> presented. Specifying both a presentation period in a previous
> frame and using GOOGLE_display_timing is well defined -- the
> presentation will be delayed until the later of the two times.
Should this extension specify how it interacts with the various
VK_PRESENT_MODE_* modes?
For one example: With VK_PRESENT_MODE_MAILBOX_KHR, does the period
specified by this extension correspond to:
a) The time between when the image is placed in the the queue of
pending presentation requests and when the next image is placed in the
queue
b) The time between when the image is taken from the queue to be
actually presented and when the same thing happens for another image
(which happens to be in the queue at the time)
c) Yet something else?
If it's a), given the extension talks about rounding to the nearest
upcoming frame, does VK_PRESENT_MODE_MAILBOX_KHR effectively behave
the same as VK_PRESENT_MODE_FIFO(_RELAXED)_KHR with this extension?
If it's b), there can be any number of images entering and leaving the
queue during the period, so it's not clear what purpose the period
would serve?
- --
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
-BEGIN PGP SIGNATURE-
iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXkrQ9gAKCRBaga+Oatuy
AB2FAJ4glgpyMYSy1WPmbpzbI2O5Rvv0/QCfSeQBF7vsooAtjEBicmW76NfWWws=
=MzZO
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging experimental r600/nir code
On 2020-02-12 7:46 p.m., Marek Olšák wrote: > How do you enable LTO+PGO? Is it something we could enable by default for > release builds? Enabling LTO for Mesa, I get a lot of warnings about issues affecting it specifically, making me doubt that it's currently safe in general, in particular for the radeonsi/RADV drivers (due to issues in addrlib). It shouldn't be enabled by default before those issues are addressed (and ideally CI coverage in place to prevent them from creeping back in). -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Review Request (master branch)] svga: Use pipe_shader_state_from_tgsi to set shader state
On 2020-02-11 6:49 p.m., Charmaine Lee wrote: > > Those two patches are simple fixes to our svga driver and have been tested in > house for a while already. > So I thought it's ok to push the patches directly. > Thanks for reminding me of the MR practice, will keep that in mind for next > submits. Thanks. The CI pipeline does test building the svga driver (maybe the testing coverage can be increased in the future? :), so it's at least theoretically possible for an svga driver change to break the pipeline. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Review Request (master branch)] svga: Use pipe_shader_state_from_tgsi to set shader state
Hi Charmaine,
it looks like you pushed this patch and another one directly to the main
Mesa repository master branch.
Pushing directly to the main Mesa repository is no longer common
practice, and indeed discouraged, as it circumvents the pre-merge GitLab
CI pipeline and forfeits all other benefits of a merge request (MR).
The common practice is to create an MR (normally already for patch
review) and assign it to Marge Bot for merging. Marge will rebase as
needed and merge once the pre-merge CI pipeline has passed.
Thanks,
On 2020-01-29 5:14 p.m., Neha Bhende wrote:
> Use pipe_shader_state_from_tgsi() to set shader state for transformed
> shader so that we get all correct data for respective shader state.
>
> This fixes several regressed glretrace, piglit crashes found during merging
> upsteam mesa
>
> Fixes: bf12bc2dd7a2 (draw: add nir info gathering and building support)
>
> Reviewed-by: Charmaine Lee
> ---
> src/gallium/drivers/svga/svga_state_tgsi_transform.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/svga/svga_state_tgsi_transform.c
> b/src/gallium/drivers/svga/svga_state_tgsi_transform.c
> index b567aab6bc8..9d701b73772 100644
> --- a/src/gallium/drivers/svga/svga_state_tgsi_transform.c
> +++ b/src/gallium/drivers/svga/svga_state_tgsi_transform.c
> @@ -131,7 +131,7 @@ emulate_point_sprite(struct svga_context *svga,
> tgsi_dump(new_tokens, 0);
>}
>
> - templ.tokens = new_tokens;
> + pipe_shader_state_from_tgsi(&templ, new_tokens);
>templ.stream_output.num_outputs = 0;
>
>if (streamout) {
>
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2020-02-07 10:19 p.m., Keith Packard wrote: > Michel Dänzer writes: > >> With variable refresh rate, it could certainly be useful for the >> kernel to have this information as early as possible. It >> shouldn't make any difference with fixed refresh though, since >> the kernel should always be able to hit the next refresh in that >> case as long as the fences for the flip signal in time for >> vertical blank. > > Although, if the application is mixing present_period and > display_timing operations, things can still get mixed up -- a frame > with present_period followed by a frame with display_timing can > invalidate the computed next frame time. Applications doing that > may not get the best possible result... Right. Applications should normally stick to one or the other extension, not flip-flop between them. > Ok, it sounds like I should at least go clean up the implementation > and make it into something not quite so embarrassing to me. > > Going forward, how can we provide this to application developers > for experimentation? Would we consider including it in a release > once reviewed within the Mesa community? I think at least the following needs to happen first: * At least a prototype of plumbing through this information to the amdgpu kernel driver (or another one which may grow VRR support) and making use of it for adjusting the refresh periods to allow hitting the target as closely as possible. * At least a prototype of a game engine making use of it to control the variable refresh rate. This will allow confirming that this approach actually works and provides the sought benefit. - -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer -BEGIN PGP SIGNATURE- iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXkEoYwAKCRBaga+Oatuy AEHbAJ42gnXFAJ1j+znHDt68kS1k+BrrUwCgolxHui7Mqux37yjbfGZMmCUlFGo= =ZVoG -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
On 2020-02-04 8:12 p.m., Keith Packard wrote: > Michel Dänzer writes: > >> Hmm, I didn't fully realize this in my reading of the draft, thanks >> Matias for pointing it out! >> >> That the timing of frame N+1 has to be specified when submitting frame >> N for presentation is odd to me TBH. While I can imagine this might be >> suitable for some apps such as video players, I'm skeptical about game >> engines. They would need to calculate frame time budget and choose >> simulation time for frame N+1 before submitting frame N for >> presentation. Is that really how game engines (want to) work? > > It's not asking the application to figure this out much earlier -- the > application needs to know the target time for the next frame before > starting any of the frame computations, and that happens right after > submitting the previous frame. > > The goal here is to provide the display system the timing information as > soon as the application knows it, in case that helps the backend work > better. With variable refresh rate, it could certainly be useful for the kernel to have this information as early as possible. It shouldn't make any difference with fixed refresh though, since the kernel should always be able to hit the next refresh in that case as long as the fences for the flip signal in time for vertical blank. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2020-02-03 8:48 p.m., Keith Packard wrote: > Michel Dänzer writes: > >> Instead of rounding to the nearest upcoming frame, should it >> round to the earliest frame after the specified period has >> passed? As written, it seems to contradict the next paragraph >> below: > > Sorry for the poor wording; let me describe what I want informally > here. > > For nanosecond periods to be easy to use on fixed-refresh-rate > monitors, I want the näive computation to "just work". For a given > refresh period, 'r', I want to select a period of 'n' frames > using: > > computed_period = n * r > > Because of clock skew and rounding problems, it's quite possible > that the period could easily end up being just slightly smaller > than that: > > actual_period = n * r - ε Is that still an issue if the (minimal) length of a vertical blanking period is subtracted from the computed period? >> (I'm not ruling out that rounding to nearest might be better, but >> there should be a rationale for it, which also justifies being >> inconsistent with GOOGLE_display_timing) > > Yes, this is intentionally inconsistent with > GOOGLE_display_timing, which I believe is hard to use correctly. > > By specifying not before semantics, GOOGLE_display_timing requires > applications compute a fake time guaranteed to be not after the > actual target frame time. This really messes things up when you > might have variable refresh rate monitors. I see. Same question as above. FWIW, one thing making "not before" semantics attractive is that they're easy to achieve in the kernel: It can just make sure the page flip isn't programmed to hardware before the target time. > I just went and read the time-based stuff from the X Present > extension. That uses 'nearest' semantics too, when supported by > the driver. When not supported, the server gets to do whatever it > likes (oops!). PresentOptionUST has never been functional, so there can't be any clients relying on specific semantics (other than being a no-op :) for it. Therefore, we could still change its semantics before making it functional, FWIW. >> P.S. It would be good to create a WIP merge request for this in >> the main Mesa project, to have a central place for gathering >> feedback and tracking progress. > > Done, thanks for the suggestion. Thanks. For the record, that's https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3682 . - -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer -BEGIN PGP SIGNATURE- iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXjlKiwAKCRBaga+Oatuy ALsMAKCRxgfQa1zDXrLZ6iUnkl1+PtHqIQCgrFiNxQmRMye9B0t3RRXtr3dGjiY= =lLMw -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2020-02-03 9:16 p.m., Keith Packard wrote: > "Matias N. Goldberg" writes: > >> I read your article. > > Thanks! > >> What I feel are missing are just minor pesky details: > > Yes, it's definitely a rough draft at best. Figuring out the right > words to make it do precisely what we want is hard, and I'm hoping > we can first figure out what we want, then figure out how to say > that precisely. > >> 1. Written as is, the frame being submitted is rounded up to >> display timing, delaying *future* frames.But there is no way to >> delay the *currently displaying frame* (i.e. the 'previous' >> frame). > > Correct. The period provided controls how long the specified frame > will be shown to the user (at a minimum). Future frames will be > delayed by at least that long. > >> Right now if frame N was submitted without VkPresentTimeMESA but >> frame N+1 is, then frame N+1 will be presented to screen ASAP. > > Correct. > >> What I'm saying is that if frame N was submitted without >> VkPresentTimeMESA, then at frame N+1 I should be able to tell >> 'keep frame N displayed for at least P nanoseconds since it was >> displayed, and *then* present frame N+1, which is the frame I am >> now submitting' > > That's not what this extension does; if you wanted frame 'N' to be > displayed for 'P' nanoseconds, then you would specify 'P' when > queuing frame 'N'. Hmm, I didn't fully realize this in my reading of the draft, thanks Matias for pointing it out! That the timing of frame N+1 has to be specified when submitting frame N for presentation is odd to me TBH. While I can imagine this might be suitable for some apps such as video players, I'm skeptical about game engines. They would need to calculate frame time budget and choose simulation time for frame N+1 before submitting frame N for presentation. Is that really how game engines (want to) work? Instead, have you considered allowing the GOOGLE_display_timing desiredPresentTime to be specified as a relative time, measured from when the previous image of the swapchain was actually presented, instead of as an absolute time? Could something like that also address the motivation for VK_MESA_present_period? - -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer -BEGIN PGP SIGNATURE- iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXjlKBwAKCRBaga+Oatuy ADDxAJ49XUxG6tnAWuC/br12sORqQSBUyACgk7h1jf9fjjtMYvrkIfUnkcHwkqg= =m2sK -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
On 2020-02-02 7:51 a.m., Keith Packard wrote:
>
> I spent some time over the last week experimenting with a different way
> of doing frame timing.
>
> Instead of specifying *when* a particular frame should be displayed, how
> about we specify how *long* a particular frame should be made visible
> to the user?
>
> This has a couple of advantages over the approach taken in
> GOOGLE_display_timing:
>
> 1. It provides information to the backend about frame timing
> a frame earlier.
>
> 2. Missing a frame can generate fewer artifacts.
>
> Here's what I'm thinking the extension would look like:
>
> An application uses VK_MESA_present_period by including a
> VkPresentPeriodMESA structure in the pNext chain in the
> VkPresentInfoKHR structure passed to the vkQueuePresentKHR call.
>
> typedef struct VkPresentPeriodMESA {
> VkStructureTypesType;
> const void*pNext;
> uint32_t swapchainCount;
> const int64_t* pPresentPeriods;
> } VkPresentPeriodMESA;
>
> The fields in this structure are:
>
> * sType. Set to VK_STRUCTURE_TYPE_PRESENT_PERIOD_MESA
> * pNext. Points to the next extension structure in the chain (if any).
> * swapchainCount. A copy of the swapchainCount field in the
>VkPresentInfoKHR structure.
> * pPresentPeriods. An array, length swapchainCount, of presentation
>periods for each image in the call.
>
> Positive presentation periods represent nanoseconds. Negative
> presentation periods represent frames. A zero value means the
> extension does not affect the associated presentation.
> Nanosecond values are rounded to the nearest upcoming frame so that a
> value of n * refresh_interval is the same as using a value of n
> frames.
Instead of rounding to the nearest upcoming frame, should it round to
the earliest frame after the specified period has passed? As written, it
seems to contradict the next paragraph below:
(I'm not ruling out that rounding to nearest might be better, but there
should be a rationale for it, which also justifies being inconsistent
with GOOGLE_display_timing)
> The presentation period causes *future* images to be delayed at least
> until the specified interval after this image has been
> presented. Specifying both a presentation period in a previous frame
> and using GOOGLE_display_timing is well defined -- the presentation
> will be delayed until the later of the two times.
>
> I've got this kludged together to experiment with; I managed to make it
> work purely within Vulkan using the infrastructure built for
> GOOGLE_display_timing.
>
> https://gitlab.freedesktop.org/keithp/mesa/commits/present-period
>
> I wrote a longer article on my blog:
>
> https://keithp.com/blogs/present-period/
>
> I'm interested in hearing what people think about the general approach.
Repeating my comment on
https://gitlab.freedesktop.org/keithp/mesa/commit/c81c6ffe335032d7c88b68f83360597f7dfd5b60
(hadn't got to this post yet):
I like this extension in general.
However, I think allowing the period to be specified in frames might be
a mistake, because it won't work well with variable refresh rate. But
it'll be tempting for application / toolkit developers not to bother
with proper time calculations but to just use frames instead. (It would
be good to seek feedback on this from AMD DC developers and the larger
DRM kernel driver community as well)
P.S. It would be good to create a WIP merge request for this in the main
Mesa project, to have a central place for gathering feedback and
tracking progress.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 20.0 branchpoint planned for 2020/01/29, Milestone opened
On 2020-01-30 2:11 p.m., Dieter Nützel wrote: > Am 30.01.2020 07:51, schrieb Pierre Moreau: >> On 2020-01-30 — 07:23, Dieter Nützel wrote: >>> Ugh, LLVM git now at 11.0...missed that. >>> SPIRV-LLVM-Translator choke with 11.0 git (I think it was the same >>> with 10.0 >>> git), here. (See below.) >>> So I can't compile Mesa git (20.0) with '-Dopencl-spirv=true' since >>> November >>> (15.11.2019). >> >> The switch to 11.0 has not occurred yet: a pull request was opened a >> few days >> ago for it (see >> https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/419) >> but the build issues remain to be fixed. >> >> I will need to check for 10.0, but SPIRV-LLVM-Traslator’s master or >> llvm_release_100 branches should work against it. >> >> Pierre > > Oh, hello Pierre, forgotten to CC you in the first run, sorry! > > I'll recheck against LLVM 10.0-rc in the evening. > This shouldn't stop Mesa 20.0 then any longer?! > We have 1 month for fixing. Mesa 20.0 can't support LLVM 11 anyway. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/vcn: Handle crop parameters for encoder
On 2020-01-06 6:14 a.m., Sahu, Satyajit wrote: > Hi Michel, > > I tried with git push. It is failing with below error > > remote: You are not allowed to push code to this project. > fatal: unable to access 'https://gitlab.freedesktop.org/mesa/mesa.git/': > The requested URL returned error: 403 That's the main Mesa repository. You need to push to your forked repository[0] instead: https://gitlab.freedesktop.org//mesa.git [0] Make sure you did create a forked repository using the "Fork" button on https://gitlab.freedesktop.org/mesa/mesa before trying this, otherwise git push will create a non-forked project on the fly, which won't work for making MRs. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/vcn: Handle crop parameters for encoder
On 2020-01-03 10:06 a.m., Sahu, Satyajit wrote: > I do not find new merge request option in the merge request page. Do I > need to have some specific access to create new merge request. No, just being logged into your GitLab account should be enough. Note that it's probably easier to create an MR by clicking on the URL in the git push terminal output when pushing to the branch in your forked repository. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/vcn: enable rate control for hevc encoding
On 2019-12-13 11:01 p.m., Alex Deucher wrote: > > Merging a branch: > 1*) Check that all CI pipelines have succeeded. > 2) Rebase your local branch and force-push to your private branch. > 3) Wait for the CI to complete > 4) Push the merge button This is already obsolete again. :) In order to merge an MR, reassign it to "Marge Bot" (@marge-bot). Marge will take care of rebasing and merging the MR once the CI pipeline has passed. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merge bot ("Marge") enabled
On 2019-12-13 10:35 p.m., Eric Anholt wrote: > I finally got back around to experimenting with the gitlab merge bot, > and it turns out that the day I spent a few weeks back I had actually > given up 5 minutes before the finish line. > > Marge is now enabled for mesa/mesa, piglit, and parallel-deqp-runner. > How you interact with marge: > > - Collect your reviews > - Put reviewed-by tags in your commits > - When you would have clicked "Merge when pipeline succeeds" (or, > worse, rebase and then merge when pipeline succeeds), instead edit the > assignee of the MR (top right panel of the UI) and assign to Marge Bot > - Marge will eventually take your MR, rebase it and let the pipeline run. > - If the pipeline passes, Marge will merge it > - If the pipeline fails, Marge will note it in the logs and unassign > herself (so your next push with a "fix" won't get auto-merged until > you decide to again). > > In the commit logs of the commits that Marge rebased (they'll always > be rebased), you'll get: > > Part-of: > <https://gitlab.freedesktop.org/anholt/gitlab-experiments/merge_requests/3> > > In the final commit of that MR, you'll get: > > Tested-by: Marge Bot > <https://gitlab.freedesktop.org/anholt/gitlab-experiments/merge_requests/3> > > I feel like this is a major improvement to our workflow, in terms of > linking commits directly to their discussions without indirecting > through google. Thanks for setting this up! I think it'll make merging MRs a lot less painful, and as a bonus make the pipeline finish more quickly on average (by avoiding useless pipeline runs). > Note that one Marge instance will only process one MR at a time, so we > could end up backed up. There's a mode that will form merge trains, > but I don't understand that mode enough yet to trust it. I think for > Mesa at this point this is going to be fine, as we should still be > able to push tens of MRs through per day. Yeah, I think we're a pretty long way from that becoming an issue. Looking at https://gitlab.freedesktop.org/mesa/mesa/pipelines/charts , we've had a pretty constant rate of ~10-15 MRs being merged on average per day this year, and currently the pipeline takes ~20 minutes on average, allowing up to ~70 MRs to be merged per day. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is it time to stop using the mailing list for patch review?
On 2019-12-11 7:35 p.m., Marek Olšák wrote: > > Merging a branch: > 1*) Check that all CI pipelines have succeeded. > 2) Rebase your local branch and force-push to your private branch. > 3) Wait ~10 seconds. > 4) Push that branch to master (git push origin HEAD:master). Gitlab will > automatically mark the MR as "Merged". These steps 2-4 should only be used in exceptional cases, as they will bypass the CI pipeline. Normally, one should either wait for the CI pipeline to come back green before merging, or click "Merge automatically when pipeline succeeds". -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is it time to stop using the mailing list for patch review?
On 2019-12-11 5:47 p.m., Brian Paul wrote: > > I've had little time for Mesa work the past 18 months. That makes me sad, I hope you'll have more time again in the future. > 1. I don't think the mesa-dev list should be shut down nor purged from > the documentation. Yeah, I don't think anybody seriously suggested the list should be shut down, just that GitLab is now preferred for patch submission & review. > Someone mentioned hardly reading the mailing list anymore. I still > haven't gotten into the habit of monitoring the MRs page... Instead of monitoring a web page, I recommend setting up notifications via the bell icon on https://gitlab.freedesktop.org/mesa/mesa [0]. If you select "Custom", you can select in detail which events you want to get notification e-mails for. Check "New merge request" to get an e-mail for each new MR created. Then you can either enable notifications for other MR events here as well, or enable all notifications for MRs you're interested in using the "Notifications" switch in the right hand panel on each MR's page. GitLab notification e-mails contain X-Gitlab-* headers for easy filtering. [0] Or for the whole Mesa group, if you prefer. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Running the CI pipeline on personal Mesa branches
On 2019-12-07 12:56 a.m., Rob Clark wrote: > On Fri, Dec 6, 2019 at 3:46 PM Bas Nieuwenhuizen > wrote: >> >> On Fri, Dec 6, 2019 at 10:49 AM Michel Dänzer wrote: >>> >>> >>> I just merged >>> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2794 , which >>> affects people who want to run the CI pipeline on personal Mesa branches: >>> >>> Pushing changes to a personal branch now always creates a pipeline, but >>> none of the jobs in it run by default. (There are no longer any special >>> branch names affecting this, because creating MRs from such special >>> branches resulted in duplicate CI job runs) >>> >>> The container stage jobs can be triggered manually from the GitLab UI >>> (and maybe also via the GitLab API, for people who'd like to automate >>> this? I haven't looked into that). The build/test stage jobs run >>> automatically once all their dependencies have passed. >>> >>> As an example, in order to run one of the "piglit-*" test jobs, one has >>> to manually trigger the "x86_build" and "x86_test" jobs. >>> >>> The pipelines created for merge requests still run all jobs by default >>> as before. >>> >>> >>> The main motivation for these changes is to avoid wasting CI runner >>> resources. In that same spirit, please also cancel any unneeded >>> build/test jobs. This can be done already before those jobs start >>> running, e.g. while the container stage jobs run. >> >> No complaint about not running the pipelines by default in personal >> repositories, but expecting people to cancel automatically spawned CI >> jobs as normal part of their workflow seems incredibly fiddly and >> fragile to me. I'm not sure what you mean by fragile, but maybe my wording was too strong. It's not really "expected", I just want people to be aware that CI runner resources are finite, and wasting them affects others as well as oneself. >> Are we *that* constrained? We are a bit privileged here in Europe, as things are usually calm during our mornings. For people in North America, it tends to be pretty painful to merge an MR. (If we had a merge bot, that should mostly eliminate that pain tough) > It would be nice if there was some way to setup some conservative > filters to exclude groups of tests, ie. if only paths changed were > under src/freedreno or src/gallium/drivers/freedreno, then no need to > run panfrost CI, and visa versa. We probably shouldn't try to fine > tune that *too* much at this risk of skipping tests that should have > run, but seems like there should be same safe low hanging fruit to cut > down on CI runs in common cases. Lots of people suggest something like this, but most of them probably imagine it to be easier than it actually is. :) See https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569 . -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Running the CI pipeline on personal Mesa branches
I just merged https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2794 , which affects people who want to run the CI pipeline on personal Mesa branches: Pushing changes to a personal branch now always creates a pipeline, but none of the jobs in it run by default. (There are no longer any special branch names affecting this, because creating MRs from such special branches resulted in duplicate CI job runs) The container stage jobs can be triggered manually from the GitLab UI (and maybe also via the GitLab API, for people who'd like to automate this? I haven't looked into that). The build/test stage jobs run automatically once all their dependencies have passed. As an example, in order to run one of the "piglit-*" test jobs, one has to manually trigger the "x86_build" and "x86_test" jobs. The pipelines created for merge requests still run all jobs by default as before. The main motivation for these changes is to avoid wasting CI runner resources. In that same spirit, please also cancel any unneeded build/test jobs. This can be done already before those jobs start running, e.g. while the container stage jobs run. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] How to merge Mesa changes which require corresponding piglit changes
On 2019-12-02 3:15 p.m., Tapani Pälli wrote: > On 11/15/19 8:41 PM, Mark Janes wrote: >> Michel Dänzer writes: >> >>> On 2019-11-15 4:02 p.m., Mark Janes wrote: >>>> Michel Dänzer writes: >>>> >>>>> Now that the GitLab CI pipeline tests a snapshot of piglit with >>>>> llvmpipe >>>>> (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2468), the >>>>> question has come up how to deal with inter-dependent Mesa/piglit >>>>> changes (where merging only one or the other causes some piglit >>>>> regressions). >>>>> >>>>> >>>>> First of all, let it be clear that just merging the Mesa changes as-is >>>>> and breaking the GitLab CI pipeline is not acceptable. >>>>> >>>>> >>>>> From the Mesa POV, the easiest solution is: >>>>> >>>>> 1. Merge the piglit changes >>>>> 2. In the Mesa MR (merge request), add a commit which updates >>>>> piglit[0] >>>>> 3. If the CI pipeline is green, the MR can be merged >>>>> >>>>> >>>>> In case one wants to avoid alarms from external CI systems, another >>>>> possibility is: >>>> >>>> For the Intel CI, no alarm is generated if the piglit test is pushed >>>> first. Normal development process includes writing a piglit test to >>>> illustrate the bug that is being fixed. >>> >>> Cool, but what if the piglit changes affect the results of existing >>> tests? That was the situation yesterday which prompted this thread. >> >> We attribute the status change to piglit in the CI config, within a few >> hours. The test shows up as a failure in CI until it is triaged. > > I think we have a problem with current gitlab CI process. > > Right now if someone needs to update piglit commit used by CI, he also > ends up fixing and editing the .gitlab-ci/piglit/quick_gl.txt (and > glslparser+quick_shader.txt) as CI reports numerous failures because of > completely unrelated stuff as meanwhile people added other tests, > removed tests and modified them. This is at least somewhat intentional, as the results of any newly added tests should be carefully checked for plausibility. > I think we should turn such warnings on only when we have more > sophisticated algorithm to detect actual regression (not just 'state > change', like additional test or removed test). It's unclear what exactly you're proposing. In order to catch regressions (e.g. pass -> warn, pass -> fail, pass -> skip, pass -> crash), we need a list of all tests on at least one side of each transition. We're currently keeping the list of all warning/failing/skipped/crashing tests, but not passing tests (to keep the lists as small as possible). One possibility might be to remove the summary at the end of the lists. That would allow new passing tests to be silently added, but it would mean we could no longer catch pass -> notrun regressions. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] How to merge Mesa changes which require corresponding piglit changes
On 2019-11-15 4:02 p.m., Mark Janes wrote: > Michel Dänzer writes: > >> Now that the GitLab CI pipeline tests a snapshot of piglit with llvmpipe >> (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2468), the >> question has come up how to deal with inter-dependent Mesa/piglit >> changes (where merging only one or the other causes some piglit >> regressions). >> >> >> First of all, let it be clear that just merging the Mesa changes as-is >> and breaking the GitLab CI pipeline is not acceptable. >> >> >> From the Mesa POV, the easiest solution is: >> >> 1. Merge the piglit changes >> 2. In the Mesa MR (merge request), add a commit which updates piglit[0] >> 3. If the CI pipeline is green, the MR can be merged >> >> >> In case one wants to avoid alarms from external CI systems, another >> possibility is: > > For the Intel CI, no alarm is generated if the piglit test is pushed > first. Normal development process includes writing a piglit test to > illustrate the bug that is being fixed. Cool, but what if the piglit changes affect the results of existing tests? That was the situation yesterday which prompted this thread. >> 1. In the Mesa MR, add a commit which disables the piglit tests broken >> by the Mesa changes. >> 2. If the CI pipeline is green, the MR can be merged >> 3. Merge the piglit changes >> 4. Create another Mesa MR which updates piglit[0] and re-enables the >> tests disabled in step 1 >> >> I hope that covers it, don't hesitate to ask questions if something's >> still unclear. > > It might help developers if CI generated the patch to make their pipeline > pass. It does for the test result list, if that's what you mean. However, that patch shouldn't be applied mechanically, but only after confirming that all changes in test results are expected. Ideally, whenever there are any new tests, the corresponding CI jobs should be run several times to make sure the new results are stable, otherwise any flaky tests should be excluded. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] How to merge Mesa changes which require corresponding piglit changes
Now that the GitLab CI pipeline tests a snapshot of piglit with llvmpipe (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2468), the question has come up how to deal with inter-dependent Mesa/piglit changes (where merging only one or the other causes some piglit regressions). First of all, let it be clear that just merging the Mesa changes as-is and breaking the GitLab CI pipeline is not acceptable. From the Mesa POV, the easiest solution is: 1. Merge the piglit changes 2. In the Mesa MR (merge request), add a commit which updates piglit[0] 3. If the CI pipeline is green, the MR can be merged In case one wants to avoid alarms from external CI systems, another possibility is: 1. In the Mesa MR, add a commit which disables the piglit tests broken by the Mesa changes. 2. If the CI pipeline is green, the MR can be merged 3. Merge the piglit changes 4. Create another Mesa MR which updates piglit[0] and re-enables the tests disabled in step 1 I hope that covers it, don't hesitate to ask questions if something's still unclear. [0] How to update piglit in the CI pipeline: * Change the commit hash on the "git checkout" line in .gitlab-ci/debian-test-install.sh[1] to a later commit from the piglit master branch * Bump DEBIAN_TEST_TAG[1] in .gitlab-ci.yml to the current date * May also need to update .gitlab-ci/piglit/*.txt to match any expected changes in test results See https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2748 for an example. [1] Might soon be .gitlab-ci/container/x86_test.sh and DEBIAN_TAG in the x86_test job definition, respectively, once https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2722 is merged. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Release workflow with gitlab issues
On 2019-09-18 9:15 p.m., Adam Jackson wrote:
> On Wed, 2019-09-18 at 12:08 -0700, Mark Janes wrote:
>>
>>> We'll also need to replace the Bugzilla: tag with a tag that gitlab
>>> recognizes
>>> for closing issues. Since we already use "Fixes:" for something else, I'd
>>> like
>>> to propose "Closes:"
>>>
>>> so we'd replace:
>>> Buzilla: https://...
>>> with:
>>> Closes: !0
>>
>> A more exact replacement would be:
>> Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/{issue}
>>
>> Is there an advantage to the !{issue} format? Perhaps gitlab parses it
>> and closes the issue?
>
> gitlab can parse both the !nnn format and full URLs, and yes, it does
> close issues when a commit with such a Closes: line is merged.
Just for the record, the "!" prefix is for MRs, issues use "#".
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 2/2] dri: Pass a __DRIcontext to ->set_damage_region()
On 2019-08-30 7:00 p.m., Boris Brezillon wrote: > > So, next question is, do you think it's acceptable to pass a > DRIcontext here, and if not, do you have any idea how to solve this > problem? Hmm, not sure. Maybe it would be better to explicitly pass in the __DRIimage* to which the damage region applies? -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 2/2] dri: Pass a __DRIcontext to ->set_damage_region()
On 2019-08-30 6:52 p.m., Boris Brezillon wrote:
> On Fri, 30 Aug 2019 18:43:59 +0200
> Michel Dänzer wrote:
>
>>> diff --git a/include/GL/internal/dri_interface.h
>>> b/include/GL/internal/dri_interface.h
>>> index 4c60d349ddd5..e04bed689219 100644
>>> --- a/include/GL/internal/dri_interface.h
>>> +++ b/include/GL/internal/dri_interface.h
>>> @@ -527,12 +527,13 @@ struct __DRI2bufferDamageExtensionRec {
>>> *
>>> * Used to implement EGL_KHR_partial_update.
>>> *
>>> +* \param ctx context
>>> * \param drawable affected drawable
>>> * \param nrects number of rectangles provided
>>> * \param rectsthe array of rectangles, lower-left origin
>>> */
>>> - void (*set_damage_region)(__DRIdrawable *drawable, unsigned int nrects,
>>> - int *rects);
>>> + void (*set_damage_region)(__DRIcontext *_ctx, __DRIdrawable *drawable,
>>> + unsigned int nrects, int *rects);
>>> };
>>
>> This would break the DRI2_BufferDamage extension version 1 ABI. You'd
>> need to either add a new hook like set_damage_region2 and bump
>> __DRI2_BUFFER_DAMAGE_VERSION (and make sure that's handled correctly
>> everywhere), or add a new extension instead.
>
> I thought this change was only impacting the internal API, but maybe
> I'm missing something.
include/GL/internal/dri_interface.h defines the DRI driver ABI, which
must be kept backwards compatible.
> In any case, this extension has been merged recently (mesa-19.2.0-rc1),
> so maybe we can fix it before 19.2 is released to avoid creating
> ->set_damage_region2().
Ah, yes. I misinterpreted gitk's output, thinking it had already been
introduced in 19.1. Sorry for the false alarm.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 2/2] dri: Pass a __DRIcontext to ->set_damage_region()
On 2019-08-29 1:54 p.m., Boris Brezillon wrote:
> So we can call st_validate_state() from dri2_set_damage_region() in
> order to update the BACK_LEFT attachement before using it. If we don't
> do that, the resource passed to pipe_screen->set_damage_region() might
> be wrong.
>
> Signed-off-by: Boris Brezillon
> ---
> Hi,
>
> I honestly don't know if this is the right thing to do. Passing a
> context for somethings that we decided to bind to a surface (and
> the underlying resources attached to it) seems wrong, but at the same
> time I don't see any other option to sync the gallium drawable state
> with the EGL DRI surface one.
>
> Any ideas/suggestions?
>
> Regards,
>
> Boris
> ---
> include/GL/internal/dri_interface.h | 5 +++--
> src/egl/drivers/dri2/egl_dri2.c | 7 +--
> src/gallium/state_trackers/dri/dri2.c | 11 ++-
> 3 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/include/GL/internal/dri_interface.h
> b/include/GL/internal/dri_interface.h
> index 4c60d349ddd5..e04bed689219 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -527,12 +527,13 @@ struct __DRI2bufferDamageExtensionRec {
> *
> * Used to implement EGL_KHR_partial_update.
> *
> +* \param ctx context
> * \param drawable affected drawable
> * \param nrects number of rectangles provided
> * \param rectsthe array of rectangles, lower-left origin
> */
> - void (*set_damage_region)(__DRIdrawable *drawable, unsigned int nrects,
> - int *rects);
> + void (*set_damage_region)(__DRIcontext *_ctx, __DRIdrawable *drawable,
> + unsigned int nrects, int *rects);
> };
This would break the DRI2_BufferDamage extension version 1 ABI. You'd
need to either add a new hook like set_damage_region2 and bump
__DRI2_BUFFER_DAMAGE_VERSION (and make sure that's handled correctly
everywhere), or add a new extension instead.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] scons: Make GCC builds stricter.
On 2019-08-28 1:56 p.m., Jose Fonseca wrote: > Hi Michel, > >> Good to see you guys starting to take better advantage of the >> GitLab CI pipeline. > > Gitlab CI integration is complicated (very configurable), but I can > tell from my experience with my own personal Github projects that > having tests run during PRs are a god send. Yeah. >> With my last name spelled correctly Dänzer or Daenzer, > > Oops. I worried about getting the "ae" right and forgot the "n".. > m(_ _)m No worries, I appreciate your effort! :) -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Switching to Gitlab Issues instead of Bugzilla?
On 2019-08-29 9:36 p.m., Rob Clark wrote: > On Thu, Aug 29, 2019 at 12:02 PM Kenneth Graunke > wrote: >> >> - Moving bug reports between the kernel and Mesa would be harder. >> We would have to open a bug in the other system. (Then again, >> moving bugs between Mesa and X or Wayland would be easier...) > > If that was a concern, we could setup a kernel gitlab project that has > an empty git repository (at least until we are ready to move drm git > tree). Yeah, the obvious solution for this is to migrate everything that's left together (which is what I've been asking all along :). Given that, I'm in favour. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] scons: Make GCC builds stricter.
On 2019-08-27 12:57 p.m., Jose Fonseca wrote: > Uses some of the same -Werror options used by Meson, Cool stuff! Good to see you guys starting to take better advantage of the GitLab CI pipeline. > as suggested by Michel Daezer. With my last name spelled correctly Dänzer or Daenzer, Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration
On 2019-08-28 3:08 a.m., Eric Engestrom wrote: > On Tuesday, 2019-08-27 13:31:22 +, Jose Fonseca wrote: >> Appveyor seems to be building other MR 1781: >> >> https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/26989425 >> https://ci.appveyor.com/project/mesa3d/mesa-re1yd/history >> https://gitlab.freedesktop.org/eric/mesa/pipelines/59190 > > You shouldn't take my MRs as an example for this, as I've set up the > hook on my account, so my MRs always get picked up by appveyor :) Yeah, the external integration settings are per GitLab project, and pre-merge CI pipelines for MRs run in the source project context, so the appveyor integration would need to be set up in each forked project used for MRs. This is a bit unfortunate, as it means the CI pipeline which runs (in the main project context) after an MR is merged could fail at the appveyor step, even if the pre-merge pipeline passed. Not sure what can be done about this though, other than requiring forked projects used for MRs to set up the appveyor integration as well. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (update-reviewers-for-vmware): i965/clear: clear_value better precision
On 2019-08-02 6:12 p.m., Brian Paul wrote: > On 08/02/2019 09:56 AM, Eric Engestrom wrote: >> On Friday, 2019-08-02 17:50:17 +0200, Michel Dänzer wrote: >>> On 2019-08-02 5:37 p.m., Brian Paul wrote: >>>> Ugh, I didn't mean to do this. I'm trying to figure out how to make a >>>> merge request with gitlab. >>> >>> Just push to a branch in your personal repository, and the output of git >>> push contains an URL for creating an MR for it. >> >> Precisely, but just to be extra clear: your personal repo needs to be >> forked from the main mesa repo [1], not just "a repo containing the mesa >> git history". >> GitLab needs to know the two are linked and pressing that "fork" button >> is how you tell it. > > Yeah, I just figured that out a few minutes ago. After I figure out all > the detailed steps from scratch I'll add it to the documentation. > > I've really never done anything with gitlab, github, etc. and have been > busy with non-Mesa work for over a year now. I have a lot of catch-up > to do. It sounds like you're doing fine so far considering that! Don't hesitate to ask if you run into any other issues. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (update-reviewers-for-vmware): i965/clear: clear_value better precision
On 2019-08-02 5:37 p.m., Brian Paul wrote: > Ugh, I didn't mean to do this. I'm trying to figure out how to make a > merge request with gitlab. Just push to a branch in your personal repository, and the output of git push contains an URL for creating an MR for it. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gitlab-ci: remove software-properties-common
On 2019-08-01 6:51 p.m., Emil Velikov wrote: > On Thu, 1 Aug 2019 at 16:03, Emil Velikov wrote: >> >> On Thu, 1 Aug 2019 at 14:26, Michel Dänzer wrote: >>> On 2019-08-01 2:32 p.m., Emil Velikov wrote: >> >>>> Sure I'll do that in a moment. >>> >>> Why don't you just follow my suggestion above? >>> >> That's what I was planning to do :-) >> > Done and dusted. Thanks for the help and extensive how-to, I've > followed it literally. Thanks! Just a detail: None of the pipelines referenced on the MR page actually generated the docker image. Looking at https://gitlab.freedesktop.org/evelikov/mesa/pipelines , I guess the 2019-08-01 image already existed in your registry from when you pushed https://gitlab.freedesktop.org/evelikov/mesa/commit/ab218119ae865d0a3b11d8753e9eada828b8a9b8 , so either that shouldn't have been pushed, or the image removed again before creating the MR. Something to perfect next time. :) -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gitlab-ci: remove software-properties-common
On 2019-08-01 2:32 p.m., Emil Velikov wrote: > On Thu, 1 Aug 2019 at 09:35, Michel Dänzer wrote: >> >> On 2019-07-31 11:47 p.m., Eric Engestrom wrote: >>> On Wednesday, 2019-07-31 16:07:45 +0200, Michel Dänzer wrote: >>>> On 2019-07-31 3:26 p.m., Emil Velikov wrote: >>>>> On Wed, 31 Jul 2019 at 14:16, Michel Dänzer wrote: >>>>>> >>>>>> On 2019-07-31 3:04 p.m., Emil Velikov wrote: >>>>>>> From: Emil Velikov >>>>>>> >>>>>>> Currently we use the python package to manage repositories. At the same >>>>>>> time we also do that by hand - since it's a trivial echo to a file. >>>>>>> >>>>>>> Stay consistent, remove the package and manage things manually. >>>>>>> >>>>>>> Cc: Eric Engestrom >>>>>>> Signed-off-by: Emil Velikov >>>>>>> --- >>>>>>> .gitlab-ci/debian-install.sh | 11 +-- >>>>>>> 1 file changed, 5 insertions(+), 6 deletions(-) >>>>>>> >>>>>>> diff --git a/.gitlab-ci/debian-install.sh b/.gitlab-ci/debian-install.sh >>>>>>> index 578074ddb87..719d7830018 100644 >>>>>>> --- a/.gitlab-ci/debian-install.sh >>>>>>> +++ b/.gitlab-ci/debian-install.sh >>>>>>> @@ -16,12 +16,11 @@ apt-get install -y \ >>>>>>>curl \ >>>>>>>wget \ >>>>>>>unzip \ >>>>>>> - gnupg \ >>>>>>> - software-properties-common >>>>>>> + gnupg >>>>>>> >>>>>>> curl -fsSL https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add - >>>>>>> -add-apt-repository "deb https://apt.llvm.org/stretch/ >>>>>>> llvm-toolchain-stretch-7 main" >>>>>>> -add-apt-repository "deb https://apt.llvm.org/stretch/ >>>>>>> llvm-toolchain-stretch-8 main" >>>>>>> +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ >>>>>>> llvm-toolchain-stretch-7 main" >/etc/apt/sources.list.d/llvm7.list >>>>>>> +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ >>>>>>> llvm-toolchain-stretch-8 main" >/etc/apt/sources.list.d/llvm8.list >>>>>>> >>>>>>> sed -i -e 's/http:\/\/deb/https:\/\/deb/g' /etc/apt/sources.list >>>>>>> echo 'deb https://deb.debian.org/debian stretch-backports main' >>>>>>> >/etc/apt/sources.list.d/backports.list >>>>>>> @@ -46,8 +45,8 @@ apt-get install -y -t stretch-backports \ >>>>>>>clang-8 >>>>>>> >>>>>>> # Install remaining packages from Debian buster to get newer versions >>>>>>> -add-apt-repository "deb https://deb.debian.org/debian/ buster main" >>>>>>> -add-apt-repository "deb https://deb.debian.org/debian/ buster-updates >>>>>>> main" >>>>>>> +echo "deb https://deb.debian.org/debian/ buster main" >>>>>>> >/etc/apt/sources.list.d/buster.list >>>>>>> +echo "deb https://deb.debian.org/debian/ buster-updates main" >>>>>>> >/etc/apt/sources.list.d/buster-updates.list >>>>>>> apt-get update >>>>>>> apt-get install -y \ >>>>>>>bzip2 \ >>>>>>> >>>>>> >>>>>> This should be merged as part of an MR which requires the docker image >>>>>> to be re-generated for another reason, and thus bumps DEBIAN_TAG. >>>>>> >>>>> Since this is a non-functional change, I've explicitly omitted bumping >>>>> the DEBIAN_TAG. >>>>> Seemingly I forgot to mention it in the commit message though, oopsie. >>>>> >>>>> Since the image will contain practically the same artefacts, is it >>>>> worth carving out 30 minutes (or so) from the runners? >>>> >>>> No, I agree that would be wasteful for this change alone. >>>> >>>> However, merging this change without bumping the tag isn't good either, >>>> because then any issues with it would only be discovered the next time >&
Re: [Mesa-dev] [PATCH] gitlab-ci: remove software-properties-common
On 2019-07-31 11:47 p.m., Eric Engestrom wrote: > On Wednesday, 2019-07-31 16:07:45 +0200, Michel Dänzer wrote: >> On 2019-07-31 3:26 p.m., Emil Velikov wrote: >>> On Wed, 31 Jul 2019 at 14:16, Michel Dänzer wrote: >>>> >>>> On 2019-07-31 3:04 p.m., Emil Velikov wrote: >>>>> From: Emil Velikov >>>>> >>>>> Currently we use the python package to manage repositories. At the same >>>>> time we also do that by hand - since it's a trivial echo to a file. >>>>> >>>>> Stay consistent, remove the package and manage things manually. >>>>> >>>>> Cc: Eric Engestrom >>>>> Signed-off-by: Emil Velikov >>>>> --- >>>>> .gitlab-ci/debian-install.sh | 11 +-- >>>>> 1 file changed, 5 insertions(+), 6 deletions(-) >>>>> >>>>> diff --git a/.gitlab-ci/debian-install.sh b/.gitlab-ci/debian-install.sh >>>>> index 578074ddb87..719d7830018 100644 >>>>> --- a/.gitlab-ci/debian-install.sh >>>>> +++ b/.gitlab-ci/debian-install.sh >>>>> @@ -16,12 +16,11 @@ apt-get install -y \ >>>>>curl \ >>>>>wget \ >>>>>unzip \ >>>>> - gnupg \ >>>>> - software-properties-common >>>>> + gnupg >>>>> >>>>> curl -fsSL https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add - >>>>> -add-apt-repository "deb https://apt.llvm.org/stretch/ >>>>> llvm-toolchain-stretch-7 main" >>>>> -add-apt-repository "deb https://apt.llvm.org/stretch/ >>>>> llvm-toolchain-stretch-8 main" >>>>> +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ >>>>> llvm-toolchain-stretch-7 main" >/etc/apt/sources.list.d/llvm7.list >>>>> +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ >>>>> llvm-toolchain-stretch-8 main" >/etc/apt/sources.list.d/llvm8.list >>>>> >>>>> sed -i -e 's/http:\/\/deb/https:\/\/deb/g' /etc/apt/sources.list >>>>> echo 'deb https://deb.debian.org/debian stretch-backports main' >>>>> >/etc/apt/sources.list.d/backports.list >>>>> @@ -46,8 +45,8 @@ apt-get install -y -t stretch-backports \ >>>>>clang-8 >>>>> >>>>> # Install remaining packages from Debian buster to get newer versions >>>>> -add-apt-repository "deb https://deb.debian.org/debian/ buster main" >>>>> -add-apt-repository "deb https://deb.debian.org/debian/ buster-updates >>>>> main" >>>>> +echo "deb https://deb.debian.org/debian/ buster main" >>>>> >/etc/apt/sources.list.d/buster.list >>>>> +echo "deb https://deb.debian.org/debian/ buster-updates main" >>>>> >/etc/apt/sources.list.d/buster-updates.list >>>>> apt-get update >>>>> apt-get install -y \ >>>>>bzip2 \ >>>>> >>>> >>>> This should be merged as part of an MR which requires the docker image >>>> to be re-generated for another reason, and thus bumps DEBIAN_TAG. >>>> >>> Since this is a non-functional change, I've explicitly omitted bumping >>> the DEBIAN_TAG. >>> Seemingly I forgot to mention it in the commit message though, oopsie. >>> >>> Since the image will contain practically the same artefacts, is it >>> worth carving out 30 minutes (or so) from the runners? >> >> No, I agree that would be wasteful for this change alone. >> >> However, merging this change without bumping the tag isn't good either, >> because then any issues with it would only be discovered the next time >> it does get bumped. Hence my request above. > > I agree with Michel here, it's better to waste a re-gen now and notice > any issue right away. That's not exactly what I'm saying though. :) If you don't want to merge this together with other changes which bump the tag, how about: * Create an MR with an additional commit which bumps the tag * Wait for the CI pipeline to come back green * Force-push to the source branch without the additional commit, and merge the MR * Remove the ephemeral docker image from https://gitlab.freedesktop.org/evelikov/mesa/container_registry The CI pipeline information including the log of the job which generated the ephemeral docker image will remain accessible. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gitlab-ci: remove software-properties-common
On 2019-07-31 3:26 p.m., Emil Velikov wrote: > On Wed, 31 Jul 2019 at 14:16, Michel Dänzer wrote: >> >> On 2019-07-31 3:04 p.m., Emil Velikov wrote: >>> From: Emil Velikov >>> >>> Currently we use the python package to manage repositories. At the same >>> time we also do that by hand - since it's a trivial echo to a file. >>> >>> Stay consistent, remove the package and manage things manually. >>> >>> Cc: Eric Engestrom >>> Signed-off-by: Emil Velikov >>> --- >>> .gitlab-ci/debian-install.sh | 11 +-- >>> 1 file changed, 5 insertions(+), 6 deletions(-) >>> >>> diff --git a/.gitlab-ci/debian-install.sh b/.gitlab-ci/debian-install.sh >>> index 578074ddb87..719d7830018 100644 >>> --- a/.gitlab-ci/debian-install.sh >>> +++ b/.gitlab-ci/debian-install.sh >>> @@ -16,12 +16,11 @@ apt-get install -y \ >>>curl \ >>>wget \ >>>unzip \ >>> - gnupg \ >>> - software-properties-common >>> + gnupg >>> >>> curl -fsSL https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add - >>> -add-apt-repository "deb https://apt.llvm.org/stretch/ >>> llvm-toolchain-stretch-7 main" >>> -add-apt-repository "deb https://apt.llvm.org/stretch/ >>> llvm-toolchain-stretch-8 main" >>> +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ >>> llvm-toolchain-stretch-7 main" >/etc/apt/sources.list.d/llvm7.list >>> +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ >>> llvm-toolchain-stretch-8 main" >/etc/apt/sources.list.d/llvm8.list >>> >>> sed -i -e 's/http:\/\/deb/https:\/\/deb/g' /etc/apt/sources.list >>> echo 'deb https://deb.debian.org/debian stretch-backports main' >>> >/etc/apt/sources.list.d/backports.list >>> @@ -46,8 +45,8 @@ apt-get install -y -t stretch-backports \ >>>clang-8 >>> >>> # Install remaining packages from Debian buster to get newer versions >>> -add-apt-repository "deb https://deb.debian.org/debian/ buster main" >>> -add-apt-repository "deb https://deb.debian.org/debian/ buster-updates main" >>> +echo "deb https://deb.debian.org/debian/ buster main" >>> >/etc/apt/sources.list.d/buster.list >>> +echo "deb https://deb.debian.org/debian/ buster-updates main" >>> >/etc/apt/sources.list.d/buster-updates.list >>> apt-get update >>> apt-get install -y \ >>>bzip2 \ >>> >> >> This should be merged as part of an MR which requires the docker image >> to be re-generated for another reason, and thus bumps DEBIAN_TAG. >> > Since this is a non-functional change, I've explicitly omitted bumping > the DEBIAN_TAG. > Seemingly I forgot to mention it in the commit message though, oopsie. > > Since the image will contain practically the same artefacts, is it > worth carving out 30 minutes (or so) from the runners? No, I agree that would be wasteful for this change alone. However, merging this change without bumping the tag isn't good either, because then any issues with it would only be discovered the next time it does get bumped. Hence my request above. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gitlab-ci: remove software-properties-common
On 2019-07-31 3:04 p.m., Emil Velikov wrote: > From: Emil Velikov > > Currently we use the python package to manage repositories. At the same > time we also do that by hand - since it's a trivial echo to a file. > > Stay consistent, remove the package and manage things manually. > > Cc: Eric Engestrom > Signed-off-by: Emil Velikov > --- > .gitlab-ci/debian-install.sh | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) > > diff --git a/.gitlab-ci/debian-install.sh b/.gitlab-ci/debian-install.sh > index 578074ddb87..719d7830018 100644 > --- a/.gitlab-ci/debian-install.sh > +++ b/.gitlab-ci/debian-install.sh > @@ -16,12 +16,11 @@ apt-get install -y \ >curl \ >wget \ >unzip \ > - gnupg \ > - software-properties-common > + gnupg > > curl -fsSL https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add - > -add-apt-repository "deb https://apt.llvm.org/stretch/ > llvm-toolchain-stretch-7 main" > -add-apt-repository "deb https://apt.llvm.org/stretch/ > llvm-toolchain-stretch-8 main" > +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ > llvm-toolchain-stretch-7 main" >/etc/apt/sources.list.d/llvm7.list > +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ > llvm-toolchain-stretch-8 main" >/etc/apt/sources.list.d/llvm8.list > > sed -i -e 's/http:\/\/deb/https:\/\/deb/g' /etc/apt/sources.list > echo 'deb https://deb.debian.org/debian stretch-backports main' > >/etc/apt/sources.list.d/backports.list > @@ -46,8 +45,8 @@ apt-get install -y -t stretch-backports \ >clang-8 > > # Install remaining packages from Debian buster to get newer versions > -add-apt-repository "deb https://deb.debian.org/debian/ buster main" > -add-apt-repository "deb https://deb.debian.org/debian/ buster-updates main" > +echo "deb https://deb.debian.org/debian/ buster main" > >/etc/apt/sources.list.d/buster.list > +echo "deb https://deb.debian.org/debian/ buster-updates main" > >/etc/apt/sources.list.d/buster-updates.list > apt-get update > apt-get install -y \ >bzip2 \ > This should be merged as part of an MR which requires the docker image to be re-generated for another reason, and thus bumps DEBIAN_TAG. Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [AppVeyor] mesa master #11902 failed
On 2019-07-19 1:47 a.m., Rob Clark wrote: > On Thu, Jul 18, 2019 at 4:34 PM Roland Scheidegger wrote: >> >> Am 16.07.19 um 20:55 schrieb AppVeyor: >>> >>> Build mesa 11902 failed >>> Commit 856e84083e by Rob Clark <mailto:robdcl...@chromium.org> on >>> 7/15/2019 4:05 PM: >>> mesa/st: add sampler uniforms\n\nAdd sampler uniforms for the UV >>> plane(s), so driver can count the\nuniforms and get the correct sampler >>> count.\n\nFixes lowered YUV on a6xx which actually wants to know # of >>> samplers.\n\nSigned-off-by: Rob Clark >>> \nReviewed-by: Kristian H. Kristensen >>> \nReviewed-by: Eric Anholt >>> >> >> Apparently this commit broke windows builds... >> > > Hmm, really no asprintf() on windows? > > Is there some place we can add an asprintf() in mesa for windows builds? Looks like the CI pipeline scons-win64 job needs to be tightened up: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/425745 Maybe just make implicit function declarations errors in general? AFAICT that's already the case with meson. (At least this would need to be fixed first with scons: src/gallium/winsys/svga/drm/vmw_screen.c: In function 'vmw_dev_compare': src/gallium/winsys/svga/drm/vmw_screen.c:48:12: warning: implicit declaration of function 'major' [-Wimplicit-function-declaration] return (major(*(dev_t *)key1) == major(*(dev_t *)key2) && ^ src/gallium/winsys/svga/drm/vmw_screen.c:49:12: warning: implicit declaration of function 'minor'; did you mean 'mknod'? [-Wimplicit-function-declaration] minor(*(dev_t *)key1) == minor(*(dev_t *)key2)) ? 0 : 1; ^ mknod ) -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] pipe-loader: use radeonsi for MM if amdgpu dri is used
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. :) -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] pipe-loader: use radeonsi for MM if amdgpu dri is used
On 2019-07-15 3:58 p.m., Jeremy Newton wrote:
> Thanks Marek and Michel, see the updated patch below:
FYI, this kind of commentary should be after the --- line, or it will be
included as part of the Git commit log by tools like "git am".
> The amdgpu dri is used for the closed source AMD driver. Since this driver
> does not implement multimedia, we fall back to radeonsi in mesa to do
> multimedia. This corrects the Gallium driver name for when it is set to
> amdgpu.
>
> This will allow dropping the amdgpu-pro specific GBM implementation in
> favour of Mesa's libgbm.
>
> Signed-off-by: Jeremy Newton
> Signed-off-by: Marek Olšák
> Reviewed-by: Michel Dänzer
> ---
> src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
> b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
> index 960d63b2c31..6e889539c92 100644
> --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
> +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
> @@ -194,6 +194,11 @@ pipe_loader_drm_probe_fd_nodup(struct pipe_loader_device
> **dev, int fd)
> if (!ddev->base.driver_name)
>goto fail;
>
> + if (strcmp(ddev->base.driver_name, "amdgpu") == 0) {
> + FREE(ddev->base.driver_name);
> + ddev->base.driver_name = strdup("radeonsi");
> + }
> +
> struct util_dl_library **plib = NULL;
> #ifndef GALLIUM_STATIC_TARGETS
> plib = &ddev->lib;
>
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] pipe-loader: use radeonsi for MM if amdgpu dri is used
On 2019-07-11 8:08 p.m., Marek Olšák wrote: > From: Jeremy Newton > > The amdgpu dri is used for the closed source AMD driver. Since this driver > does not implement multimedia, we fall back to radeonsi in mesa to do > multimedia. This corrects the dri driver name for when it is set to amdgpu. "Gallium driver name" instead of "dri driver name" might make it slightly clearer why this is done. Also, might be worth adding something to the commit log that this will allow dropping the amdgpu-pro specific GBM implementation in favour of Mesa's. Either way, Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
