Re: time for amber2 branch?
On Thu, Jun 20, 2024 at 12:02 AM Mike Blumenkrantz wrote: > * lima We do maintain this, with reliable coverage in CI, and I haven't seen feedback of it particularly causing big pain for tree wide changes before. So I'd rather keep it in the main tree. At least for this round and as long as we keep other ARM GLES2 class of drivers in the main tree as well for which we need to keep pretty much the same set of common code. Erico
Re: time for amber2 branch?
i915? tegra isn't really a driver. It just calls the gallium interface like trace, but without the tracing. crocus is in the same boat as r600. Marek On Wed, Jun 19, 2024, 10:34 Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > In looking at the gallium tree, I'm wondering if it isn't time for a > second amber branch to prune some of the drivers that cause pain when doing > big tree updates: > > * nv30 > * r300 > * r600 > * lima > * virgl > * tegra > * ??? > > There's nothing stopping these drivers from continuing to develop in an > amber branch, but the risk of them being broken by other tree refactorings > is lowered, and then we are able to delete lots of legacy code in the main > branch. > > Thoughts? > > > Mike >
Re: time for amber2 branch?
On Wed, 2024-06-19 at 10:33 -0400, Mike Blumenkrantz wrote: > In looking at the gallium tree, I'm wondering if it isn't time for a > second amber branch to prune some of the drivers that cause pain when > doing big tree updates: virgl is actively maintained and covered by the CI. Apart from the burden of NTT and, hence TGSI code, I don't think that it carries that much baggage the we shouldn't be able to address problems that may arise from tree-wide changes. As for r600, I'm in principle not against moving it to an amber2 branch, because I got burned by changes gallium one time to many to really defend keeping it in the main tree. I see that Triang3l wouldn't be too happy about it, because this would mean that Terakan would either have to target this amber2 branch, improvements to the common Vulkan code would not be picked up and would need back-porting, or we would have to duplicate the maintenance of the r600 shader compiler code in amber2 and main. rusticl would be a similar thing, but ATM I don't have anything to say about how this may go forward for r600 anyway. If someone were to add a pre-merge CI for r600 hardware then I would be strongly in favor of keeping r600 in main - possibly dropping support for pre-Evergreen cards there and keeping that only in amber2, but without a CI I only see more pain coming up if we keep r600 in main. I don't have an opinion regarding the other drivers. Best, Gert
Re: time for amber2 branch?
On Wed, Jun 19, 2024 at 4:34 PM Mike Blumenkrantz wrote: > > In looking at the gallium tree, I'm wondering if it isn't time for a second > amber branch to prune some of the drivers that cause pain when doing big tree > updates: > > * nv30 ack for nv30 > * r300 > * r600 > * lima > * virgl > * tegra Personally I still think that removing the tegra driver completely is probably the best approach. I personally don't support it anymore and I doubt anybody else actually does, given it's broken on quite a few setups. So might as well just amber2 it for those who care enough. > * ??? > > There's nothing stopping these drivers from continuing to develop in an amber > branch, but the risk of them being broken by other tree refactorings is > lowered, and then we are able to delete lots of legacy code in the main > branch. > > Thoughts? > > > Mike
Re: time for amber2 branch?
On Wed, Jun 19, 2024 at 5:32 PM Thomas Debesse wrote: > > Le mer. 19 juin 2024 à 16:33, Mike Blumenkrantz > a écrit : > > In looking at the gallium tree, I'm wondering if it isn't time for a second > > amber branch to prune some of the drivers that cause pain when doing big > > tree updates > > It's probably fine for nv30 and r300 that are very unlikely to receive > new features being implemented anyway (if I'm right all they do is > OpenGL 2.1). > > For r600 it may be more annoying to split the tree for someone wanting > to continue the rusticl implementation in order to drop clover, as > this would split rusticl as well. > Maybe the work-in-progress “Terakan” vulkan driver for r600 cards > won't be affected because vulkan is not a gallium thing. > yeah not sure. r600 is in an odd place where supporting OpenCL at all is quite a painful process. I think it's fair to continue using clover for that one unless somebody really cares and really makes it all work and fixes edge cases. > I don't use any of the others so I have no thought about them. > > -- > Thomas “illwieckz” Debesse >
Re: time for amber2 branch?
On Wed, Jun 19, 2024 at 1:22 PM Triang3l wrote: > The shader compiler in R600g is actively developed (and I think OpenGL 4.6 > support is among the main goals), I don't see why it needs to be moved to a > low-priority branch or to stop getting new NIR infrastructure updates > with the > current amount of maintenance it receives. > Nothing stopping those developments from continuing in an amber branch, and the odds of any NIR changes being required for hardware this old are slim. > > On 19/06/2024 18:26, Thomas Debesse wrote: > > Maybe the work-in-progress “Terakan” vulkan driver for r600 cards > > won't be affected because vulkan is not a gallium thing. > > Terakan uses R600g files heavily, specifically the register structures, > as well > as the shader compiler (with additional intrinsics implemented and plans > to move > some SFN parts, primarily those interacting with bindings, such as storage > images/buffers, to NIR lowerings in R600g too for more straightforward code > sharing) and other shader-related parts. > > Moreover, there likely will be backporting of some parts of Terakan to > R600g > (architectural-scale bugfixes primarily) in the somewhat distant future > (when > they're fully implemented and well-tested in Terakan), specifically: > • GL_ARB_shader_draw_parameters. > • New vertex fetch subroutine generation, correctly dividing by the > instance > divisor, and co-issuing instructions where possible. > • 2048 vertex stride fetch subroutine workaround on pre-Cayman GPUs > (which have > bits only for up to 2047). > • Color attachment index compaction in fragment shaders to allow gaps > to be > filled with storage resources. > • Handling different alignment of pitch calculated by texture fetching > hardware > for 1D-thin-tiled mips of depth and stencil surface aspects that > can't be > respected on the depth/stencil attachment side where the pitch > register is > shared (likely will be using an intermediate overaligned surface). > • True indirect compute dispatch via a different packet sequence on the > existing kernel versions, and later, when the involved command > parsing is > fixed in the kernel, using actual INDIRECT_DISPATCH type-3 packets. > > — Triang3l > Terakan is not a Mesa driver, and Mesa has no obligation to cater to out-of-tree projects which use its internal API. For everything else, see above. Mike
Re: time for amber2 branch?
The shader compiler in R600g is actively developed (and I think OpenGL 4.6 support is among the main goals), I don't see why it needs to be moved to a low-priority branch or to stop getting new NIR infrastructure updates with the current amount of maintenance it receives. On 19/06/2024 18:26, Thomas Debesse wrote: > Maybe the work-in-progress “Terakan” vulkan driver for r600 cards > won't be affected because vulkan is not a gallium thing. Terakan uses R600g files heavily, specifically the register structures, as well as the shader compiler (with additional intrinsics implemented and plans to move some SFN parts, primarily those interacting with bindings, such as storage images/buffers, to NIR lowerings in R600g too for more straightforward code sharing) and other shader-related parts. Moreover, there likely will be backporting of some parts of Terakan to R600g (architectural-scale bugfixes primarily) in the somewhat distant future (when they're fully implemented and well-tested in Terakan), specifically: • GL_ARB_shader_draw_parameters. • New vertex fetch subroutine generation, correctly dividing by the instance divisor, and co-issuing instructions where possible. • 2048 vertex stride fetch subroutine workaround on pre-Cayman GPUs (which have bits only for up to 2047). • Color attachment index compaction in fragment shaders to allow gaps to be filled with storage resources. • Handling different alignment of pitch calculated by texture fetching hardware for 1D-thin-tiled mips of depth and stencil surface aspects that can't be respected on the depth/stencil attachment side where the pitch register is shared (likely will be using an intermediate overaligned surface). • True indirect compute dispatch via a different packet sequence on the existing kernel versions, and later, when the involved command parsing is fixed in the kernel, using actual INDIRECT_DISPATCH type-3 packets. — Triang3l
[ANNOUNCE] mesa 24.1.2
Hello everyone, The bugfix release 24.1.2 is now available. If you find any issues, please report them here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/new The next bugfix release is due in two weeks, on July 3rd. Cheers, Eric --- Amol Surati (1): nine: avoid using post-compacted indices with state expecting pre-compacted ones Boris Brezillon (2): pan/bi: Fix dynamic indexing of push constants panvk: Fix Cube/2DArray/3D img -> buf copies Caio Oliveira (1): intel/brw: Fix typo in DPAS emission code Daniel Schürmann (1): aco/assembler: fix MTBUF opcode encoding on GFX11 Danylo Piliaiev (1): freedreno: Make fd_pps_driver.h usable without including other FD sources Dave Airlie (4): nvk: Only enable WSI modifiers if the extension is supported. draw/texture: handle mip_offset[0] being != 0 for layered textures. nouveau/nvc0: increase overallocation on shader bo to 2K radv/video: fix layered decode h264/5 tests. David Heidelberg (1): rusticl: add -cl-std only when it's not defined David Rosca (2): radeonsi: Fix si_compute_clear_render_target with 422 subsampled formats radv/video: Add missing VCN 3.0.2 to decoder init switch Eric Engestrom (17): docs: add sha256sum for 24.1.1 .pick_status.json: Update to 50e5067be77bf8f34de6616e8edca2af2cf8d310 v3dv: add missing bounds check in VK_EXT__formats .pick_status.json: Update to cc82f7f8ace50f68b06c53ad347e36d411ae9dab radv/ci: fix manual rules .pick_status.json: Update to 41dd1c52b1d091b36f8931c4a57d3b6dc361bc84 v3d/drm-shim: emulate a rpi4 instead of a rpi3 .pick_status.json: Update to a80a1c983844bca646d5f07d65c695a84f964bfe egl: fix teardown when using xcb .pick_status.json: Mark f017beb29ce6e3469da33caff2c9a493799faca6 as denominated .pick_status.json: Update to 7dcba7e873c6b753930e2fdc8c714bb4da1a22dd glx: fix build -D glx-direct=false .pick_status.json: Update to 10d21d410068f2ca32fe898f6b4b690993d90daa .pick_status.json: Mark a9fff07c2e2b1e52b00b30dc16781209f7761c04 as denominated .pick_status.json: Update to 887f0e0af664b11c081b4140931e7213240c7b41 docs: add release notes for 24.1.2 VERSION: bump for 24.1.2 Erik Faye-Lund (3): mesa/main: remove stale prototype mesa/main: do not allow RGBA_INTEGER et al in gles3 panvk: move macro-definition to header Faith Ekstrand (5): nak: Only convert the written portion of the buffer in NirInstrPrinter nak: BMov is always variable-latency nak: Only copy-prop neg into iadd2/3 if no carry is written nak/legalize: Fold immediate sources before instructions nouveau: Fix a race in nouveau_ws_bo_destroy() Friedrich Vock (2): radv/rt: Fix memory leak when compiling libraries aco/spill: Don't spill phis with all-undef operands Georg Lehmann (1): radeonsi: set COMPUTE_STATIC_THREAD_MGMT_SE2-3 correctly on gfx10-11 Iago Toral Quiroga (1): broadcom/compiler: initialize payload_conflict for all initial nodes Iván Briano (1): vulkan/runtime: pColorAttachmentInputIndices is allowed to be NULL Job Noorman (14): ir3: fix crash in try_evict_regs with src reg ir3: fix handling of early clobbers in calc_min_limit_pressure ir3: set offset on splits created while spilling ir3: correctly set wrmask for reload.macro ir3: don't remove intervals for non-killed tex prefetch sources ir3: don't remove collects early while spilling ir3: expose instruction indexing helper for merge sets ir3: make indexing instructions optional in ir3_merge_regs ir3: index instructions before fixing up merge sets after spilling ir3: move liveness recalculation inside ir3_ra_shared ir3: restore interval_offset after liveness recalculation in shared RA ir3: add ir3_cursor/ir3_builder helpers ir3: refactor ir3_spill.c to use the ir3_cursor/ir3_builder API ir3: only add live-in phis for top-level intervals while spilling Karol Herbst (2): rusticl/spirv: do not pass a NULL pointer to slice::from_raw_parts rusticl/memory: copies might overlap for host ptrs Konstantin Seurer (2): ac/llvm: Fix DENORM_FLUSH_TO_ZERO with exact instructions ac/llvm: Enable helper invocations for vote_all/any Lionel Landwerlin (4): anv: fix pipeline flag fields anv: limit aux invalidations to primary command buffers anv: ensure completion of surface state copies before secondaries intel/fs: fix lower_simd_width for MOV_INDIRECT Lucas Fryzek (1): llvmpipe: query winsys support for dmabuf mapping Marek Olšák (1): Revert "radeonsi: fix initialization of occlusion query buffers for disabled RBs" Mary Guillemard (2): panvk: Add missing null check in DestroyCommandPool panvk: Check for maxBufferSize in panvk_CreateBuffer Mike Blumenkrantz (2): lavapi
Re: time for amber2 branch?
Le mer. 19 juin 2024 à 16:33, Mike Blumenkrantz a écrit : > In looking at the gallium tree, I'm wondering if it isn't time for a second > amber branch to prune some of the drivers that cause pain when doing big tree > updates It's probably fine for nv30 and r300 that are very unlikely to receive new features being implemented anyway (if I'm right all they do is OpenGL 2.1). For r600 it may be more annoying to split the tree for someone wanting to continue the rusticl implementation in order to drop clover, as this would split rusticl as well. Maybe the work-in-progress “Terakan” vulkan driver for r600 cards won't be affected because vulkan is not a gallium thing. I don't use any of the others so I have no thought about them. -- Thomas “illwieckz” Debesse
time for amber2 branch?
In looking at the gallium tree, I'm wondering if it isn't time for a second amber branch to prune some of the drivers that cause pain when doing big tree updates: * nv30 * r300 * r600 * lima * virgl * tegra * ??? There's nothing stopping these drivers from continuing to develop in an amber branch, but the risk of them being broken by other tree refactorings is lowered, and then we are able to delete lots of legacy code in the main branch. Thoughts? Mike
Re: SIGBUS with gbm_bo_map() and Intel ARC
On 19/06/2024 11:36, Pierre Ossman wrote: Hi, More gbm_bo_map() issues from me that could use some expert insight. When I mix GPU access in my GBM adventures, one combination results in a SIGBUS when reading the memory given from gbm_bo_map(). I'm unsure if this is a bug in the driver, or in my access? Happens with a discrete Nvidia GPU (with proprietary driver) as well, so unlikely a bug in a specific driver. :/ Regards -- Pierre Ossman Software Development Cendio AB https://cendio.com Teknikringen 8 https://twitter.com/ThinLinc 583 30 Linköpinghttps://facebook.com/ThinLinc Phone: +46-13-214600 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
SIGBUS with gbm_bo_map() and Intel ARC
Hi, More gbm_bo_map() issues from me that could use some expert insight. When I mix GPU access in my GBM adventures, one combination results in a SIGBUS when reading the memory given from gbm_bo_map(). I'm unsure if this is a bug in the driver, or in my access? What I do is: 1. X server does gbm_create_device() on the integrated Radeon GPU 2. I start vkcube, pointing it at the discrete Intel ARC GPU 3. I assume Vulkan does DRI3PixmapFromBuffer, with a buffer from the Intel GPU 4. X server does: gbm_bo_import(, GBM_BO_IMPORT_FD, , GBM_BO_USE_RENDERING | GBM_BO_USE_LINEAR) 5. Vulkan does PresentPixmap 6. X server does gbm_bo_map() and then tries to read the pixels 7. SIGBUS! Oddly enough, it works fine if I mix the GPUs the other way around. Is there something special I need to pay attention to when doing cross GPU stuff? I would have assumed that gbm_bo_import() would have complained if this was an incompatible setup. Regards -- Pierre Ossman Software Development Cendio AB https://cendio.com Teknikringen 8 https://twitter.com/ThinLinc 583 30 Linköpinghttps://facebook.com/ThinLinc Phone: +46-13-214600 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
