From dylan at pnwbakers.com Fri Nov 8 17:49:20 2024 From: dylan at pnwbakers.com (Dylan Baker) Date: Fri, 08 Nov 2024 09:49:20 -0800 Subject: [ANNOUNCE] mesa 24.3.0-rc1 Message-ID: <173108816005.571291.17917262083184246502@localhost> Hi list, After a brief delay (and some issues getting by build environment right for the release scripts), I give mesa 24.3.0-rc1. This is the first RC of our final release of 2024! Cheers, Dylan git tag: mesa-24.3.0-rc1 https://mesa.freedesktop.org/archive/mesa-24.3.0-rc1.tar.xz SHA256: 5a09bfabb143f3c6a74e5456118ae41c891424a43c4d7c9df82645fe74c8c9a4 mesa-24.3.0-rc1.tar.xz SHA512: 0e4f31df8d74009dff8dc71f374b626b72a07e2c2f5c683ddcbca226459e4e72764dd036cd700925f2f8dd2a666d2abf847fe693def14318839a7c3dd08e155b mesa-24.3.0-rc1.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-24.3.0-rc1.tar.xz.sig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: signature URL: From dev at illwieckz.net Tue Nov 12 16:38:48 2024 From: dev at illwieckz.net (=?UTF-8?B?VGhvbWFzIOKAnGlsbHdpZWNreuKAnSBEZWJlc3Nl?=) Date: Tue, 12 Nov 2024 17:38:48 +0100 Subject: Mesa is painful to bisect, I hope this can be improved In-Reply-To: <20e07340-d61e-4650-9f8d-7dad7b85172b@mailbox.org> References: <3a65a0c8b27cab328d6014394314d6ac4dbefa76.camel@gmail.com> <20e07340-d61e-4650-9f8d-7dad7b85172b@mailbox.org> Message-ID: <15f710e5-8fbe-4622-8eb2-0a79b4201ab5@illwieckz.net> Le 18/10/2024 ? 10:47, Michel D?nzer a ?crit : > On 2024-10-18 01:36, Timur Krist?f wrote: >> Or that you bisect between >> very old very new versions? > > I suspect the latter. Yes, it happens that almost every time I have to bisect Mesa, both boundaries of my bisect are ?very old? and ?very new? enough (it's usually only within a timespan in months) >> Other than that, I think it's normal and expected that the drivers >> evolve and some options change. > > 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. It's totally normal and expected things change, now there can be ways to make those changes having less impact on bisecting. Here are some examples I think about, from the most annoying one to the most pleasant one to use. 1. One way to reduce the painful mismatch may also be done by milestoning some of them, but this also have some drawbacks as it requires a pending branch for the sum of the breaking meson changes. 2. For the true/enabled Meson problem, maybe Meson itself can be made more backward-compatible. I noticed some of the pain comes from Meson itself, the same Mesa commit may rebuild with the exact same build options if the build directory is pruned first, without changing any Mesa build option. Having a build directory not rebuildable without pruning it first is a problem I almost never face with CMake so I guess Meson can be improved on that purpose. 3. A third way to make bisecting easier is to do bibisects, basically ?binary bisects?. This would solve most of those uses cases. You can see what The Documentation Foundation does for LibreOffice: https://wiki.documentfoundation.org/QA/Bibisect One idea of bibisect implementation is that every now and then a complete build of Mesa would be done and stored in a tarball somewhere, it would be built against an old-enough libc to maximize the cross-distribution compatibility. Then a git repository would commit at the same time some reference of the tarball. That being done, a bibisect tool would just run git bisect over those commits, and a special script would fetch and unpack the binary tarball (that would replace the build step in the bisect process) and provide a way to run any arbitrary command in some environment. This would make bisecting very straightforward for most uses cases. Once one gets the before/after boundaries of the bibisect, one can finish the bisect by building the few remaining commits from source. For example the binary tarballs would be done once a week, so the source bisect would only span over a single week of changes. With a single week of changes, chance that Meson options change on every commit is very low. I myself do a bit of that by keeping some copies of my builds (alongside copies of old build scripts) to make it simpler to check for regressions. Eero Tamminen also talked about bibisect here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12024#note_2611196 > Something that has helped me was having machinery that builds Mesa (among other things) regularly (e.g. daily or weekly), and keeping those builds (+ their date & commit info) around for a year or two. Build script is in Git, and documents the necessary build options for given time period. > One can then do quick bisect using LD_LIBRARY_PATH to prebuilt binaries. Git bisect is then needed only for getting the exact commit between the final 2 binary builds, and unlikely to need build option changes. Something that will be annoying to deal with in setting-up a bibisect infrastructure is that it may be needed to build and ship the related LLVM components as well (llvmpipe, radeonsi, r600 clover?). Maybe there are other ways I didn't think of that can help to make bisecting easier without preventing Mesa contributors to actually change Mesa as soon as they like. The best solutions are the one that both make bisecting easier and doesn't slow down the merge of breaking changes. -- Thomas ?illwieckz? Debesse From eric at engestrom.ch Wed Nov 13 16:06:06 2024 From: eric at engestrom.ch (Eric Engestrom) Date: Wed, 13 Nov 2024 17:06:06 +0100 Subject: [ANNOUNCE] mesa 24.2.7 Message-ID: <5okw33nbppuxzbaq6dnc4q6o52mdsftmsyp5mwuk5cz6vaicrg@4nduupj5eohd> Hello everyone, The bugfix release 24.2.7 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 November 27th. Cheers, Eric --- Benjamin Herrenschmidt (1): dril: Fixup order of pixel formats in drilConfigs Christian Gmeiner (1): etnaviv: Fix incorrect pipe_nn creation Connor Abbott (1): ir3: Fix detection of nontrivial continues David Rosca (1): radeonsi/vcn: Enable VCN4 AV1 encode WA Eric Engestrom (11): docs: add sha sum for 24.2.6 .pick_status.json: Update to ab1479ae6a845d2c7beeb0fed6e2153cc2b16c5e .pick_status.json: Update to fe50011ddb35077c0d4cc2b31d56f8dd1376d5a2 meson: add dependencies needed by wsi_common_x11.c even on non-drm platforms .pick_status.json: Update to 4d09cd7fa590cbd52d8772d5a251fab8b0874ab7 .pick_status.json: Mark 5cd054ebe5512aeac80e08528d8363335d0aeeb8 as denominated .pick_status.json: Update to b32d0d4b4588bf207a9b85b03f2f1c7bb9e72d57 ci: raise priority of release manager pipelines lima/ci: marking two failures as known to make the ci useful again docs: add release notes for 24.2.7 VERSION: bump for 24.2.7 Ian Romanick (2): brw/copy: Don't copy propagate through smaller entry dest size brw/cse: Don't eliminate instructions that write flags Job Noorman (1): ir3/ra: prevent moving source intervals for shared collects Jose Maria Casanova Crespo (1): v3d: Enable Early-Z with discards when depth updates are disabled Karmjit Mahil (3): tu: Fix push_set host memory leak on command buffer reset tu: Fix potential alloc of 0 size nir: Fix `no_lower_set` leak on early return Karol Herbst (2): nv/codegen: Do not use a zero immediate for tex instructions nvc0: return NULL instead of asserting in nvc0_resource_from_user_memory Lionel Landwerlin (5): anv: avoid L3 fabric flush in pipeline barriers vulkan/runtime: fix allocation failure handling anv: fix even set/reset on blitter engine anv: add texture cache inval after binding pool update anv: update shader descriptor resource limits Lucas Fryzek (1): lp: Only close udmabuf handle if its valid M Henning (2): nvk/cmd_buffer: Pass count to set_root_array nvk: Fix invalidation of NVK_CBUF_TYPE_DYNAMIC_UBO Marek Ol??k (2): radeonsi/gfx11: fix Z corruption for Blender radeonsi/gfx12: fix AMD_DEBUG=nodcc not working Matt Turner (1): anv: Align anv_descriptor_pool::host_mem Mike Blumenkrantz (1): zink: stop leaking precompiled generated tcs Patrick Lerda (1): r600: fix sfn_nir_legalize_image_load_store cubearray behavior Paulo Zanoni (1): brw: add a NOP in between WHILE instructions on LNL Rhys Perry (1): aco: don't byte align global VMEM loads if it might be unsafe Rob Clark (3): util/primconvert: Avoid OoB with improbable draws freedreno: Fix tile-per-pipe debug overrides freedreno/a6xx: Stop exposing MSAA image load/store harder Samuel Pitoiset (2): radv: add missing L2 non-coherent image case for mipmaps with DCC/HTILE on GFX11 radv: cleanup tools related resources when destroying logical device Timur Krist?f (1): radv: Flush L2 cache for non-L2-coherent images in EndCommandBuffer. Tomeu Vizoso (1): etnaviv/ml: Fix includes itycodes (1): intel: Fix a typo in intel_device_info.c:has_get_tiling git tag: mesa-24.2.7 https://mesa.freedesktop.org/archive/mesa-24.2.7.tar.xz SHA256: a0ce37228679647268a83b3652d859dcf23d6f6430d751489d4464f6de6459fd mesa-24.2.7.tar.xz SHA512: 8776b45abe5e845c587c0fa9feb22d89f07457265ff63175fb42681ce56dff97b0e163d9e9ac80555ee04decb78754e7331e1015d95c5f84ca3c2549663291dd mesa-24.2.7.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-24.2.7.tar.xz.sig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From dylan at pnwbakers.com Wed Nov 13 19:09:37 2024 From: dylan at pnwbakers.com (Dylan Baker) Date: Wed, 13 Nov 2024 11:09:37 -0800 Subject: [ANNOUNCE] mesa 24.3.0-rc2 Message-ID: <173152497784.1235126.7407341998994934216@localhost> Hi list, We have a fairly small RC2 today, with a bit of work across the board. We currently only have 2 open blocking issues, and given that we delayed the branchpoint by 3 weeks, I wouldn't object to pulling in the RC period by 1 week and have rc3 rather than rc4 be the final release, if we can get all of the issues closed in time. Cheers, Dylan Changes since rc1 ================= Alyssa Rosenzweig (1): asahi: fix a2c with sample shading, harder Chia-I Wu (1): panvk: ensure res table is restored after meta Deborah Brouwer (1): ci/b2c: update RESULTS_DIR for .b2c-test jobs Dylan Baker (4): .pick_status.json: Update to ced2404cb433deaa84cf6cf9edce212733117c0b .pick_status.json: Update to 5e0b81413de588803c9a0736acd8decd40d19ab6 .pick_status.json: Update to b0c9789bc1ed808d29f642e9445599dc85896444 VERSION: bump for 24.3.0-rc2 release Eric Engestrom (4): meson: bump spirv-tools version needed to v2022.1 ci: move error handling functions at the end ci: use quiet alias for commands ci: raise priority of release manager pipelines Hans-Kristian Arntzen (1): vulkan/wsi/wayland: Use X11-style image count strategy when using FIFO. Ian Romanick (3): brw/emit: Add correct 3-source instruction assertions for each platform brw/copy: Don't copy propagate through smaller entry dest size brw/cse: Don't eliminate instructions that write flags Iv?n Briano (1): intel/rt: fix ray_query stack address calculation Job Noorman (1): ir3/ra: prevent moving source intervals for shared collects Jose Maria Casanova Crespo (1): v3d: Enable Early-Z with discards when depth updates are disabled Karmjit Mahil (3): tu: Fix push_set host memory leak on command buffer reset tu: Fix potential alloc of 0 size nir: Fix `no_lower_set` leak on early return Karol Herbst (2): nv/codegen: Do not use a zero immediate for tex instructions nvc0: return NULL instead of asserting in nvc0_resource_from_user_memory Lionel Landwerlin (2): anv: fix extent computation in image->image host copies anv: update shader descriptor resource limits M Henning (2): nvk/cmd_buffer: Pass count to set_root_array nvk: Fix invalidation of NVK_CBUF_TYPE_DYNAMIC_UBO Matt Turner (1): anv: Align anv_descriptor_pool::host_mem Russell Greene (1): perfetto: fix macos compile Tomeu Vizoso (2): etnaviv/ml: Fix includes etnaviv/nn: Fix use of etna_core_info git tag: mesa-24.3.0-rc2 https://mesa.freedesktop.org/archive/mesa-24.3.0-rc2.tar.xz SHA256: 3bcc1be0ae71eabb18d51c0bd9c84374e6dc4594a1b3261cd24901263c971e35 mesa-24.3.0-rc2.tar.xz SHA512: 6f47ad5a7d0d5d3cfb933275e566531c176078edffc582c638678ee5fab6cbece9e66ae92c099e8c494a79883b6728cb7deca9297c8d9b6095b7089401d64f1f mesa-24.3.0-rc2.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-24.3.0-rc2.tar.xz.sig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: signature URL: From hrgbrge at gmail.com Wed Nov 13 21:02:14 2024 From: hrgbrge at gmail.com (Hrgbrg E Ev H4) Date: Thu, 14 Nov 2024 00:02:14 +0300 Subject: Turnip Adreno 710 Message-ID: Hello, can you make an Adreno 710 turnip driver or is it in the works. I appreciate the team of Mesa, you did so much to us but if you have a chance please make Adreno 710 a driver or if you can't, can you help me how to do that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hrgbrge at gmail.com Wed Nov 13 21:07:07 2024 From: hrgbrge at gmail.com (Hrgbrg E Ev H4) Date: Thu, 14 Nov 2024 00:07:07 +0300 Subject: Turnip Adreno 710 In-Reply-To: References: Message-ID: Thank you all for everything by the way 14 Kas 2024 Per 00:02 tarihinde Hrgbrg E Ev H4 ?unu yazd?: > Hello, can you make an Adreno 710 turnip driver or is it in the works. I > appreciate the team of Mesa, you did so much to us but if you have a chance > please make Adreno 710 a driver or if you can't, can you help me how to do > that? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From AnddyRen at glenfly.com Thu Nov 14 03:31:50 2024 From: AnddyRen at glenfly.com (Anddy Ren(WH-RD)) Date: Thu, 14 Nov 2024 03:31:50 +0000 Subject: aapoint issue Message-ID: Hi, I'm experiencing a crash while verifying aapoint functionality, and after debugging, I found that there may be a problem with the following statement. In nir_draw_helpers.c, static void nir_lower_aapoint_impl(nir_function_impl *impl, lower_aapoint *state, nir_alu_type bool_type) { ............ switch (bool_type) { case nir_type_bool1: sel = nir_b32csel(b, nir_fge(b, k, dist), coverage, chan_val_one); break; case nir_type_bool32: sel = nir_b32csel(b, nir_fge32(b, k, dist), coverage, chan_val_one); break; ............ The bool_type passed to this function is nir_type_bool1, when I change nir_b32csel to nir_bcsel, the test passes. Is it a bug? Can you help confirm if it's okay to change it this way? Best Regards, Anddy Ren ????? ????????????????????????????????????????????????????? CONFIDENTIAL NOTE: This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.faye-lund at collabora.com Thu Nov 14 08:57:24 2024 From: erik.faye-lund at collabora.com (Erik Faye-Lund) Date: Thu, 14 Nov 2024 09:57:24 +0100 Subject: aapoint issue In-Reply-To: References: Message-ID: <4a742796bb1569bc72a19432277980a437cac703.camel@collabora.com> Yeah, that looks like a mistake, indeed. Do you mind submitting a patch on GitLab for it? The problem seems to originate from this commit (CCed ian): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20869/diffs?commit_id=d3a95f0f713ff3a0216f0dfa634798a1db55ef27 On Thu, 2024-11-14 at 03:31 +0000, Anddy Ren(WH-RD) wrote: > > > > Hi, > ? > I'm experiencing a crash while verifying aapoint functionality, and > after debugging, I found that there may be a problem with the > following statement. > ? > In nir_draw_helpers.c, > ? > static void > nir_lower_aapoint_impl(nir_function_impl *impl, lower_aapoint *state, > ?????????????????????? nir_alu_type bool_type) > { > ???? > ?? switch (bool_type) { > ?? case nir_type_bool1: > ????? sel =nir_b32csel(b, nir_fge(b, k, dist), coverage, > chan_val_one); > ????? break; > ?? case nir_type_bool32: > ????? sel = nir_b32csel(b, nir_fge32(b, k, dist), coverage, > chan_val_one); > ????? break; > ?? ???? > ? > The bool_type passed to this function is nir_type_bool1, when I > change nir_b32csel to nir_bcsel, the test passes. Is it a bug? Can > you help confirm if it's okay to change it this way? > ? > Best Regards, > Anddy Ren > ? > > > ????? > ????????????????????????????????????????????????????? > > CONFIDENTIAL NOTE: > > This email contains confidential or legally privileged information > and is for the sole use of its intended recipient. Any unauthorized > review, use, copying or forwarding of this email or the content of > this email is strictly prohibited. From david at ixit.cz Mon Nov 18 22:01:44 2024 From: david at ixit.cz (David Heidelberg) Date: Mon, 18 Nov 2024 17:01:44 -0500 Subject: Mesa is painful to bisect, I hope this can be improved In-Reply-To: <15f710e5-8fbe-4622-8eb2-0a79b4201ab5@illwieckz.net> References: <3a65a0c8b27cab328d6014394314d6ac4dbefa76.camel@gmail.com> <20e07340-d61e-4650-9f8d-7dad7b85172b@mailbox.org> <15f710e5-8fbe-4622-8eb2-0a79b4201ab5@illwieckz.net> Message-ID: On 12/11/2024 11:38, Thomas ?illwieckz? Debesse wrote: > > Le 18/10/2024 ? 10:47, Michel D?nzer a ?crit : >> On 2024-10-18 01:36, Timur Krist?f wrote: >>> Or that you bisect between >>> very old very new versions? >> >> I suspect the latter. > > Yes, it happens that almost every time I have to bisect Mesa, both > boundaries of my bisect are ?very old? and ?very new? enough (it's > usually only within a timespan in months) > >>> Other than that, I think it's normal and expected that the drivers >>> evolve and some options change. >> >> 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. > > It's totally normal and expected things change, now there can be ways to > make those changes having less impact on bisecting. Here are some > examples I think about, from the most annoying one to the most pleasant > one to use. > > 1. One way to reduce the painful mismatch may also be done by > milestoning some of them, but this also have some drawbacks as it > requires a pending branch for the sum of the breaking meson changes. > > 2. For the true/enabled Meson problem, maybe Meson itself can be made > more backward-compatible. I noticed some of the pain comes from Meson > itself, the same Mesa commit may rebuild with the exact same build > options if the build directory is pruned first, without changing any > Mesa build option. Having a build directory not rebuildable without > pruning it first is a problem I almost never face with CMake so I guess > Meson can be improved on that purpose. > > 3. A third way to make bisecting easier is to do bibisects, basically > ?binary bisects?. This would solve most of those uses cases. > > You can see what The Documentation Foundation does for LibreOffice: > https://wiki.documentfoundation.org/QA/Bibisect > > One idea of bibisect implementation is that every now and then a > complete build of Mesa would be done and stored in a tarball somewhere, > it would be built against an old-enough libc to maximize the cross- > distribution compatibility. Then a git repository would commit at the > same time some reference of the tarball. That being done, a bibisect > tool would just run git bisect over those commits, and a special script > would fetch and unpack the binary tarball (that would replace the build > step in the bisect process) and provide a way to run any arbitrary > command in some environment. > For Debian users, I wanted to mention the Mesa3D nightly repository, which I built with bisection in mind. It's build everyday (except when build starts failing, usually due to buildsystem changes and I'm currently only one who maintains it) and you can replace the "trixie" (the latest) with hash of previous days (see the "History" button) to download older packages. https://gitlab.freedesktop.org/gfx-ci/ci-deb-repo/-/tree/trixie?ref_type=heads I believe bibisect is definitely more universal solution, but as someone may benefit from this repo, wanted to mention it. David > This would make bisecting very straightforward for most uses cases. Once > one gets the before/after boundaries of the bibisect, one can finish the > bisect by building the few remaining commits from source. > > For example the binary tarballs would be done once a week, so the source > bisect would only span over a single week of changes. With a single week > of changes, chance that Meson options change on every commit is very low. > > I myself do a bit of that by keeping some copies of my builds (alongside > copies of old build scripts) to make it simpler to check for regressions. > > Eero Tamminen also talked about bibisect here: > https://gitlab.freedesktop.org/mesa/mesa/-/issues/12024#note_2611196 > >> Something that has helped me was having machinery that builds Mesa >> (among other things) regularly (e.g. daily or weekly), and keeping >> those builds (+ their date & commit info) around for a year or two. >> Build script is in Git, and documents the necessary build options for >> given time period. >> One can then do quick bisect using LD_LIBRARY_PATH to prebuilt >> binaries. Git bisect is then needed only for getting the exact commit >> between the final 2 binary builds, and unlikely to need build option >> changes. > > Something that will be annoying to deal with in setting-up a bibisect > infrastructure is that it may be needed to build and ship the related > LLVM components as well (llvmpipe, radeonsi, r600 clover?). > > Maybe there are other ways I didn't think of that can help to make > bisecting easier without preventing Mesa contributors to actually change > Mesa as soon as they like. The best solutions are the one that both make > bisecting easier and doesn't slow down the merge of breaking changes. > From heiko.nardmann at stryker.com Tue Nov 19 05:46:48 2024 From: heiko.nardmann at stryker.com (Heiko Nardmann) Date: Tue, 19 Nov 2024 06:46:48 +0100 Subject: [ANNOUNCE] mesa 24.2.7 In-Reply-To: <5okw33nbppuxzbaq6dnc4q6o52mdsftmsyp5mwuk5cz6vaicrg@4nduupj5eohd> References: <5okw33nbppuxzbaq6dnc4q6o52mdsftmsyp5mwuk5cz6vaicrg@4nduupj5eohd> Message-ID: <2cd5b440-5b7e-4f68-9672-d6564fd44fbf@stryker.com> Hi together, I would like to build mesa on my own on Ubuntu. After starting on this I experienced that a lot of dependencies are needed; so I wondered whether there are already Dockerfiles available for this. At least I did not see any inside the repository? Thanks in advance! Kind regards, Heiko Follow this link to read our Privacy Statement -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernstp at gmail.com Tue Nov 19 08:38:36 2024 From: ernstp at gmail.com (Ernst Persson) Date: Tue, 19 Nov 2024 09:38:36 +0100 Subject: [ANNOUNCE] mesa 24.2.7 In-Reply-To: <2cd5b440-5b7e-4f68-9672-d6564fd44fbf@stryker.com> References: <5okw33nbppuxzbaq6dnc4q6o52mdsftmsyp5mwuk5cz6vaicrg@4nduupj5eohd> <2cd5b440-5b7e-4f68-9672-d6564fd44fbf@stryker.com> Message-ID: If you have source code repositories enabled, you can do sudo apt build-dep mesa which gives you all the dependencies that the current version of Mesa in Ubuntu has, which is a good starting point. Then you probably want to disable everything you don't use to make it easier & faster. Regards //Ernst Den tis 19 nov. 2024 kl 09:19 skrev Heiko Nardmann < heiko.nardmann at stryker.com>: > Hi together, > > I would like to build mesa on my own on Ubuntu. After starting on this I > experienced that a lot of dependencies are needed; so I wondered whether > there are already Dockerfiles available for this. At least I did not see > any inside the repository? > > Thanks in advance! > > > *Kind regards,* > > Heiko > Follow this link to read our Privacy Statement > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maraeo at gmail.com Tue Nov 19 13:46:17 2024 From: maraeo at gmail.com (=?UTF-8?B?TWFyZWsgT2zFocOhaw==?=) Date: Tue, 19 Nov 2024 08:46:17 -0500 Subject: [ANNOUNCE] mesa 24.2.7 In-Reply-To: <2cd5b440-5b7e-4f68-9672-d6564fd44fbf@stryker.com> References: <5okw33nbppuxzbaq6dnc4q6o52mdsftmsyp5mwuk5cz6vaicrg@4nduupj5eohd> <2cd5b440-5b7e-4f68-9672-d6564fd44fbf@stryker.com> Message-ID: https://github.com/marekolsak/marek-build/?tab=readme-ov-file#mareks-approach-to-building-amd-gpu-drivers-for-driver-development Marek On Tue, Nov 19, 2024 at 3:19?AM Heiko Nardmann wrote: > > Hi together, > > I would like to build mesa on my own on Ubuntu. After starting on this I experienced that a lot of dependencies are needed; so I wondered whether there are already Dockerfiles available for this. At least I did not see any inside the repository? > > Thanks in advance! > > > Kind regards, > > Heiko > > Follow this link to read our Privacy Statement From dylan at pnwbakers.com Thu Nov 21 16:59:43 2024 From: dylan at pnwbakers.com (Dylan Baker) Date: Thu, 21 Nov 2024 08:59:43 -0800 Subject: [ANNOUNCE] mesa 24.3.0 Message-ID: <173220838379.44033.2328749639427648360@localhost> Hi list, As I'd hoped we were able to pull in the Mesa 24.3 release cycle by one week! Thanks to everyone who helped close or dismiss blocking issues! This is great, as it means we'll leap frog both the US Thanksgiving and Christmas holidays. This does mean that we will have a release due on New Years day, I will release that either the Thursday or Friday if there anything worth releasing (that two weeks is generally quite slow), otherwise we'll plan to just skip that resume on January 15th. This release has seen the continuing trend of OpenGL work slowing down and Vulkan work speeding up. Anv, Radv, Nvk, and v3dv dominate the list of new features, with v3dv gaining Vulkan 1.3 conformance. Until next time, Dylan git tag: mesa-24.3.0 https://mesa.freedesktop.org/archive/mesa-24.3.0.tar.xz SHA256: 97813fe65028ef21b4d4e54164563059e8408d8fee3489a2323468d198bf2efc mesa-24.3.0.tar.xz SHA512: 20168ae4c278776a60d5febf53b3367cf08bffffb40ef2054821e68d7a8c37a07871d097ab17555f41a4fe716f0de7df95ad7d452b1ed57db6527838eb839ba4 mesa-24.3.0.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-24.3.0.tar.xz.sig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: signature URL: From idr at paranormal-entertainment.com Sat Nov 23 00:26:24 2024 From: idr at paranormal-entertainment.com (Ian Romanick) Date: Fri, 22 Nov 2024 16:26:24 -0800 Subject: aapoint issue In-Reply-To: <4a742796bb1569bc72a19432277980a437cac703.camel@collabora.com> References: <4a742796bb1569bc72a19432277980a437cac703.camel@collabora.com> Message-ID: Can you test https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32313 ? On 11/14/24 12:57 AM, Erik Faye-Lund wrote: > Yeah, that looks like a mistake, indeed. Do you mind submitting a patch > on GitLab for it? > > The problem seems to originate from this commit (CCed ian): > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20869/diffs?commit_id=d3a95f0f713ff3a0216f0dfa634798a1db55ef27 > > On Thu, 2024-11-14 at 03:31 +0000, Anddy Ren(WH-RD) wrote: >> >> >> >> Hi, >> >> I'm experiencing a crash while verifying aapoint functionality, and >> after debugging, I found that there may be a problem with the >> following statement. >> >> In nir_draw_helpers.c, >> >> static void >> nir_lower_aapoint_impl(nir_function_impl *impl, lower_aapoint *state, >> ?????????????????????? nir_alu_type bool_type) >> { >> ???? >> ?? switch (bool_type) { >> ?? case nir_type_bool1: >> ????? sel =nir_b32csel(b, nir_fge(b, k, dist), coverage, >> chan_val_one); >> ????? break; >> ?? case nir_type_bool32: >> ????? sel = nir_b32csel(b, nir_fge32(b, k, dist), coverage, >> chan_val_one); >> ????? break; >> ?? ???? >> >> The bool_type passed to this function is nir_type_bool1, when I >> change nir_b32csel to nir_bcsel, the test passes. Is it a bug? Can >> you help confirm if it's okay to change it this way? >> >> Best Regards, >> Anddy Ren >> >> >> >> ????? >> ????????????????????????????????????????????????????? >> >> CONFIDENTIAL NOTE: >> >> This email contains confidential or legally privileged information >> and is for the sole use of its intended recipient. Any unauthorized >> review, use, copying or forwarding of this email or the content of >> this email is strictly prohibited. > From eric at engestrom.ch Thu Nov 28 00:19:55 2024 From: eric at engestrom.ch (Eric Engestrom) Date: Thu, 28 Nov 2024 01:19:55 +0100 Subject: [ANNOUNCE] mesa 24.2.8 Message-ID: Hello everyone, The bugfix release 24.2.8 is now available. This is the last release of the 24.2 series. Users are encouraged to switch to the 24.3 series to continue receiving bugfixes. Cheers, Eric --- Boris Brezillon (1): panfrost: Increase AFBC body alignment requirement on v6+ Daniel Sch?rmann (2): aco/ra: set Pseudo_instruction::scratch_sgpr to SCC if it doesn't need to be preserved aco/ra: use bitset for sgpr_operands_alias_defs Danylo Piliaiev (1): nir/nir_opt_offsets: Do not fold load/store with const offset > max Dave Airlie (2): venus: handle device probing properly. v3dv: report correct error on failure to probe David Rosca (7): radv/video: Fix H264 slice control radv/video: Fix HEVC slice control radv/video: Report correct encodeInputPictureGranularity radv/video: Avoid selecting rc layer over maximum gallium/vl: Don't support planar RGB as video format frontends/va: Create surfaces with correct fourcc for RT format frontends/va: Use compositor blit with different number of planes Eric Engestrom (14): docs: add sha sum for 24.2.7 .pick_status.json: Update to 4ed8ef74b4dc111425d6596eb3341d91d563bf00 .pick_status.json: Mark ae85e6920c18c6f850c22e183f2f740c45b69ad3 as denominated .pick_status.json: Mark a78c2bf2a41252045f7bb695d02d75fcd73a3957 as denominated .pick_status.json: Mark ca947e1295a8aedd4b7f09ca89ab285156b1309e as denominated .pick_status.json: Mark 962b996d4c569835e0c453a60bb4680d432d30f1 as denominated .pick_status.json: Mark d21f7f75ff38ed26769235daf98af4a18b02f0ab as denominated .pick_status.json: Mark 1368ee5e1aee9a760b445b7dd24d8b77be1b0800 as denominated .pick_status.json: Update to e1a8fd80d411a5ff8fa19ffcf09516ac5099a25c zink+nvk/ci: fix deqp binary used for gles tests zink+radv/ci: fix deqp binary used for gles tests .pick_status.json: Mark 44de5f1c46ceca4f8dd2c594b93ad3e29f2622bc as denominated docs: add release notes for 24.2.8 VERSION: bump for 24.2.8 Erik Faye-Lund (4): panfrost: use 64-bits for layout calculations panvk: set correct max extents for images panvk: support binding swapchain memory panvk: wire up swapchain image creation Francisco Jerez (1): intel/fs/xe2: Fix up subdword integer region restriction with strided byte src and packed byte dst. Friedrich Vock (1): vulkan/rmv: Correctly set heap size Georg Lehmann (6): nir/move_discards_to_top: don't move across is_helper_invocation nir/opt_intrinsic: rework sample mask opt with vector alu nir/opt_intrinsic: fix sample mask opt with demote nir: replace nir_opt_remove_phis_block with a single source version nir: make nir_instr_clone usable with load_const and undef nir/opt_remove_phis: rematerialize constants Hans-Kristian Arntzen (1): radv: Fix missing gang barriers for task shaders. Ian Romanick (1): Fix copy-and-paste bug in nir_lower_aapoint_impl Jesse Natalie (1): wgl: Add missing idep_mesautilformat Juan A. Suarez Romero (1): vc4: handle nir_op_ult32 intrinsic Juston Li (1): util/cache_test: Fix racey Cache.List test Karmjit Mahil (1): tu: Fix memory leaks on VK_PIPELINE_COMPILE_REQUIRED Karol Herbst (1): vtn: handle struct kernel arguments passed by value Kenneth Graunke (1): brw: Fix try_rebuild_source's ult32/ushr handling to use unsigned types Lionel Landwerlin (3): brw: allocate physical register sizes for spilling anv: fix missing push constant reallocation anv: prevent access to destroyed vk_sync objects post submission Marek Ol??k (1): radeonsi: fix gl_FrontFace elimination when one side is culled Mary Guillemard (1): panvk: Call vk_free on queue array instead of vk_object_free Matt Turner (2): vulkan: Avoid pointer aliasing nir: Get correct number of components Patrick Lerda (4): r600: fix the evergreen sampler when the minification and the magnification are not identical r600: restructure r600_create_vertex_fetch_shader() to remove memcpy() r600: ensure that the last vertex is always processed on evergreen r600: evergreen stencil/depth mipmap blit workaround Rhys Perry (5): nir/algebraic: fix iabs(ishr(iabs(a), b)) optimization nir/algebraic: check bit sizes in lowered unpack(pack()) optimization nir/lcssa: fix premature exit of loop after rematerializing derefs nir/opt_move_discards_to_top: use nir_tex_instr_has_implicit_derivative nir: fix return value of nir_instr_move for some cases Robert Mader (1): v3d: Support SAND128 base modifier Sam Lantinga (1): util: Fixed crash in HEVC encoding on 32-bit systems Samuel Pitoiset (3): radv: fix ignoring src stage mask when dst stage mask is BOTTOM_OF_PIPE radv: add a new drirc option to disable DCC for mips and enable it for RDR2 radv: fix skipping on-disk shaders cache when not useful Tapani P?lli (1): anv/android: always create 2 graphics and compute capable queues Vldly (1): freedreno: Fix resource tracking on repeated map with discard liuqiang (1): lavapipe: Resolved write to pointer after free git tag: mesa-24.2.8 https://mesa.freedesktop.org/archive/mesa-24.2.8.tar.xz SHA256: 999d0a854f43864fc098266aaf25600ce7961318a1e2e358bff94a7f53580e30 mesa-24.2.8.tar.xz SHA512: 3aa1051a72e1428e42f9537d8f6a26f2ebddc78894e0f71d2cdcc9ed555ea4d6489ad8e74d4c59b8cdf7ea1c629fa725ac2fe1e385db5d3a582d8fe8186392d6 mesa-24.2.8.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-24.2.8.tar.xz.sig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: