[Mesa-dev] [ANNOUNCE] mesa 21.2.2
Hi list, I'd like to announce Mesa 21.2.2, which is now available for consumption. This release is a bit late, and very large. We've got a ton of work going into panfrost, getting it closer to being conformant (it is conformant on 21.3!), as well as fixes for ir3, croccus, nir, utils, llvmpipe, gallivm, zink, glsl, v3d, vc4, intel, mesa, aco, iris, radv, and even osmesa. We'll hopefully be back on schedule after this. Cheers, Dylan shortlog Adrian Bunk (1): util/format: NEON is not available with the soft-float ABI Alyssa Rosenzweig (24): panfrost: Handle non-dithered clear colours panfrost: Disable shader-assisted indirect draws pan/bi: Don't set td in blend shaders pan/bi: Correct the sr_count on +ST_TILE pan/bi: Extract load_sample_id to a helper pan/bi: Set the sample ID for blend shader LD_TILE pan/bi: Use CLPER_V6 on Mali G31 panfrost: Remove unneeded quirks from T760 panfrost: Use blendable check for tib read check pan/mdg: Insert moves before writeout when needed panfrost: Zero initialize blend_shaders panfrost: Fix NULL dereference in allowlist code panfrost: Protect the variants array with a lock panfrost: Don't use ralloc for resources panfrost: Move bo->label assignment into the lock panfrost: Switch resources from an array to a set panfrost: Cache number of users of a resource panfrost: Maintain a bitmap of active batches panfrost: Add foreach_batch iterator panfrost: Prefer batch->resources to rsrc->users panfrost: Remove rsrc->track.users panfrost: Remove writer = NULL assignments panfrost: Replace writers pointer with hash table panfrost: Raise maximum texture size Bas Nieuwenhuizen (2): util/fossilize_db: Don't corrupt keys during entry read. nir: Avoid visiting instructions multiple times in nir_instr_free_and_dce. Boris Brezillon (2): panfrost: Add explicit padding to pan_blend_shader_key panfrost: v7 does not support RGB32_UNORM textures Connor Abbott (4): ir3/ra: Fix available bitset for live-through collect srcs ir3/ra: Handle huge merge sets ir3/lower_pcopy: Use right flags for src const/immed ir3/lower_pcopy: Set entry->done in the swap loop Corentin Noël (1): glx: Prevent crashes when an extension isn't found Daniel Schürmann (1): aco: fix p_insert lowering with 16bit sources Danylo Piliaiev (1): turnip: re-emit vertex params after they are invalidated Dave Airlie (5): vulkan/wsi/sw: wait for image fence before submitting to queue crocus: copy views before adjusting crocus: add missing line smooth bits. crocus: add missing fs dirty on reduced prim change. crocus/gen7: add missing IVB/GT2 geom shader workaround. Dylan Baker (13): docs: add SHA256 sum for mesa 21.2.1 .pick_status.json: Update to 35c3f5f08b7b11f3896412fb5778f127be329615 .pick_status.json: Update to 8e5e70bb3de7f75ab1b039e2cec2975ba59e4af7 .pick_status.json: Update to 572ed2249465acd4c5f8a229d504a48cbddf95a5 .pick_status.json: Update to 71e748ad2443c373bb090fa1da2626da367b1d20 .pick_status.json: Update to 9bc61108d73db4e614dda2a27750ff80165eedbb .pick_status.json: Update to a6a89aaa2f2943532d99d9bc7b80106a1740f237 .pick_status.json: Update to f4b61e90617f19ca1b8a3cfe046bac5801081057 .pick_status.json: Update to 076c8f041a63c74c31d9f541684860628a8b9979 .pick_status.json: Update to b58d6eaf1174aab296c4230e3895c65cba4bd9e3 .pick_status.json: Update to 7244aa19806cec5265e1e219cac1a99b0d3c62c6 docs: add release notes for 21.2.2 VERSION: bump for 21.2.2 release Ed Martin (1): winsys/radeonsi: Set vce_encode = true when VCE found Emma Anholt (2): llvmpipe: Free CS shader images on context destroy. llvmpipe: Fix leak of CS local memory with 0 threads. Erik Faye-Lund (4): gallivm: fix texture-mapping with 16-bit result gallium/nir/tgsi: fixup indentation gallium/nir/tgsi: initialize file_max for inputs lavapipe: fix reported subpixel precision for lines Filip Gawin (2): nir: fix shadowed variable in nir_lower_bit_size.c nir: fix ifind_msb_rev by using appropriate type Ian Romanick (3): util: Add and use functions to calculate min and max int for a size nir/lower_bit_size: Support add_sat and sub_sat nir/lower_gs_intrinsics: Return progress if append_set_vertex_and_primitive_count makes progress Icecream95 (1): pan/bi: Extend bi_add_nop_for_atest for tilebuffer loads Ilia Mirkin (3): mesa: don't return errors for gl_* GetFragData* queries glsl: fix explicit-location ifc matching in presence of array types freedreno: use OUT_WFI for emit_marker Jason Ekstrand (1): anv: Set CONTEXT_PARAM_RECOVERABLE to false Jordan Justen (1): intel/isl: Enable MOCS 61 for external
Re: [Mesa-dev] Merge blocked
I see. Got it: just use marge-bot then. Jose From: Rob Clark Sent: Tuesday, September 21, 2021 16:13 To: Jose Fonseca Cc: Gert Wollny ; ML mesa-dev Subject: Re: [Mesa-dev] Merge blocked Please don't merge or push directly, that will interfere with marge-bot when it's trying to merge someone else's MR BR, -R On Tue, Sep 21, 2021 at 7:56 AM Jose Fonseca wrote: > > Hi Gert, > > > I can understand your frustration with the flaky tests, > > My frustration comes as much from the Gitlab config as from the flaky tests. > > But you have a point: if tests weren't flaky this certainly wouldn't be much > of a problem, and filing bugs is probably the best course of action to avoid > them. > > > but I'm sure you know that having a CI is place helps a lot to not break > > most of the code, so merging without having to go through the CI is not > > really an option, even if we are all sensible adults. > > I don't follow the logic. Anybody with commit access can push from git > command line bypassing any pipeline checks. We're already relying upon > folks' judgment to use it only when it makes sense (e.g, crossporing commits, > etc.) I don't see why having a UI button to automate makes a difference. > > Reassigning to marge-bot is easy enough, but IIUC that causes all pipeline > stages (even those which were successful) to be repeated. I feel that's > wasteful (not just money, but also energy.) Allowing one to Rebase + Merge > on one click (like GitHub allows) would be more efficient IMHO. > > Anyway, for good or worse, I don't commit to Mesa as much as I used to, so > this doesn't affect me nearly as much as others. Even though I believe > allowing to merge without pipeline object would be an improvement, if > everybody else is happy with the status quo, then don't mind me. > > Jose > > > From: Gert Wollny > Sent: Tuesday, September 21, 2021 15:32 > To: Jose Fonseca ; ML mesa-dev > > Subject: Re: [Mesa-dev] Merge blocked > > Hello Jose, > > On Tue, 2021-09-21 at 11:48 +, Jose Fonseca wrote: > > Why doesn't Gilab allow one to merge manually? > > > > See > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F12940data=04%7C01%7Cjfonseca%40vmware.com%7Cb6fbf5ac91d040c7c77208d97d11be2a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637678337431351753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=4OWuhOPqIIq3XVMR3yk5y1i78usNbQ6XdtEfecIERts%3Dreserved=0: > > > > * Marge-bot failed to merge the PR due to 2 flaky tests, completely > > unrelated to the commits in question. > > I can understand your frustration with the flaky tests, but I'm sure > you know that having a CI is place helps a lot to not break most of the > code, so merging without having to go through the CI is not really an > option, even if we are all sensible adults. > > Maybe we all should just file bugs when we see a flaky test, so that > those get flagged accordingly by the developers responsible for the > related drivers. > > > > > * I manually retried the failed tests, and they all passed, but > > still Gitlab refused to allow to merge: it said I needed to rebase. > This is, because Marge merged some other MR between the time you > rebased the last time. Since the pre-merge CI was added and before > Marge was introduced, this actually happened quite regularly: Press the > Merge-when-pipeline-succeeds button and fail, because some other merge > request was already in the pipeline and got merged before your pipeline > finished. > However, nowadays you don't need to rebase yourself, once you assign > the MR to Marge and she will do that for you when she starts to handle > your merge request. > > > * I rebased, but still Gitlab refused to merge: now it expects the > > pipelines to be runagain! > I'm really sorry for your frustration, but if you're sure that the > merge failed only because if flaky tests, then simply reassigning the > MR to Marge will do. > > > Is it really necessary to go to git command line to get a PR > > merged!? (I was forced to do so 2-3 times now, but it's a hassle.) > No, it is not necessary, because Marge will do that for you, once you > assign the MR to her. > > > Or run pipelines over and over until one eventually succeeds? > This is only a problem because of the flaky tests, and yes, we should > do something about this. > > > Sorry for the rant, but I didn't notice anybody else complain. Am I > > the only bothered here? Or is there a better way here I don't know > > of? > As you sure have understood at this point, the answer is "Assign to > Marge" ;) > > Best regards, > Gert > >
Re: [Mesa-dev] Merge blocked
Please don't merge or push directly, that will interfere with marge-bot when it's trying to merge someone else's MR BR, -R On Tue, Sep 21, 2021 at 7:56 AM Jose Fonseca wrote: > > Hi Gert, > > > I can understand your frustration with the flaky tests, > > My frustration comes as much from the Gitlab config as from the flaky tests. > > But you have a point: if tests weren't flaky this certainly wouldn't be much > of a problem, and filing bugs is probably the best course of action to avoid > them. > > > but I'm sure you know that having a CI is place helps a lot to not break > > most of the code, so merging without having to go through the CI is not > > really an option, even if we are all sensible adults. > > I don't follow the logic. Anybody with commit access can push from git > command line bypassing any pipeline checks. We're already relying upon > folks' judgment to use it only when it makes sense (e.g, crossporing commits, > etc.) I don't see why having a UI button to automate makes a difference. > > Reassigning to marge-bot is easy enough, but IIUC that causes all pipeline > stages (even those which were successful) to be repeated. I feel that's > wasteful (not just money, but also energy.) Allowing one to Rebase + Merge > on one click (like GitHub allows) would be more efficient IMHO. > > Anyway, for good or worse, I don't commit to Mesa as much as I used to, so > this doesn't affect me nearly as much as others. Even though I believe > allowing to merge without pipeline object would be an improvement, if > everybody else is happy with the status quo, then don't mind me. > > Jose > > > From: Gert Wollny > Sent: Tuesday, September 21, 2021 15:32 > To: Jose Fonseca ; ML mesa-dev > > Subject: Re: [Mesa-dev] Merge blocked > > Hello Jose, > > On Tue, 2021-09-21 at 11:48 +, Jose Fonseca wrote: > > Why doesn't Gilab allow one to merge manually? > > > > See > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F12940data=04%7C01%7Cjfonseca%40vmware.com%7C93aedc8ac8244272385008d97d0c9cfa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637678315394314865%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=pIjQSUjrU7cCePEsmpcZ7qbdCFFhxZn0y3S7qSS8s7s%3Dreserved=0: > > > > * Marge-bot failed to merge the PR due to 2 flaky tests, completely > > unrelated to the commits in question. > > I can understand your frustration with the flaky tests, but I'm sure > you know that having a CI is place helps a lot to not break most of the > code, so merging without having to go through the CI is not really an > option, even if we are all sensible adults. > > Maybe we all should just file bugs when we see a flaky test, so that > those get flagged accordingly by the developers responsible for the > related drivers. > > > > > * I manually retried the failed tests, and they all passed, but > > still Gitlab refused to allow to merge: it said I needed to rebase. > This is, because Marge merged some other MR between the time you > rebased the last time. Since the pre-merge CI was added and before > Marge was introduced, this actually happened quite regularly: Press the > Merge-when-pipeline-succeeds button and fail, because some other merge > request was already in the pipeline and got merged before your pipeline > finished. > However, nowadays you don't need to rebase yourself, once you assign > the MR to Marge and she will do that for you when she starts to handle > your merge request. > > > * I rebased, but still Gitlab refused to merge: now it expects the > > pipelines to be runagain! > I'm really sorry for your frustration, but if you're sure that the > merge failed only because if flaky tests, then simply reassigning the > MR to Marge will do. > > > Is it really necessary to go to git command line to get a PR > > merged!? (I was forced to do so 2-3 times now, but it's a hassle.) > No, it is not necessary, because Marge will do that for you, once you > assign the MR to her. > > > Or run pipelines over and over until one eventually succeeds? > This is only a problem because of the flaky tests, and yes, we should > do something about this. > > > Sorry for the rant, but I didn't notice anybody else complain. Am I > > the only bothered here? Or is there a better way here I don't know > > of? > As you sure have understood at this point, the answer is "Assign to > Marge" ;) > > Best regards, > Gert > >
Re: [Mesa-dev] Merge blocked
Hi Gert, > I can understand your frustration with the flaky tests, My frustration comes as much from the Gitlab config as from the flaky tests. But you have a point: if tests weren't flaky this certainly wouldn't be much of a problem, and filing bugs is probably the best course of action to avoid them. > but I'm sure you know that having a CI is place helps a lot to not break most > of the code, so merging without having to go through the CI is not really an > option, even if we are all sensible adults. I don't follow the logic. Anybody with commit access can push from git command line bypassing any pipeline checks. We're already relying upon folks' judgment to use it only when it makes sense (e.g, crossporing commits, etc.) I don't see why having a UI button to automate makes a difference. Reassigning to marge-bot is easy enough, but IIUC that causes all pipeline stages (even those which were successful) to be repeated. I feel that's wasteful (not just money, but also energy.) Allowing one to Rebase + Merge on one click (like GitHub allows) would be more efficient IMHO. Anyway, for good or worse, I don't commit to Mesa as much as I used to, so this doesn't affect me nearly as much as others. Even though I believe allowing to merge without pipeline object would be an improvement, if everybody else is happy with the status quo, then don't mind me. Jose From: Gert Wollny Sent: Tuesday, September 21, 2021 15:32 To: Jose Fonseca ; ML mesa-dev Subject: Re: [Mesa-dev] Merge blocked Hello Jose, On Tue, 2021-09-21 at 11:48 +, Jose Fonseca wrote: > Why doesn't Gilab allow one to merge manually? > > See > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F12940data=04%7C01%7Cjfonseca%40vmware.com%7C93aedc8ac8244272385008d97d0c9cfa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637678315394314865%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=pIjQSUjrU7cCePEsmpcZ7qbdCFFhxZn0y3S7qSS8s7s%3Dreserved=0: > > * Marge-bot failed to merge the PR due to 2 flaky tests, completely > unrelated to the commits in question. I can understand your frustration with the flaky tests, but I'm sure you know that having a CI is place helps a lot to not break most of the code, so merging without having to go through the CI is not really an option, even if we are all sensible adults. Maybe we all should just file bugs when we see a flaky test, so that those get flagged accordingly by the developers responsible for the related drivers. > > * I manually retried the failed tests, and they all passed, but > still Gitlab refused to allow to merge: it said I needed to rebase. This is, because Marge merged some other MR between the time you rebased the last time. Since the pre-merge CI was added and before Marge was introduced, this actually happened quite regularly: Press the Merge-when-pipeline-succeeds button and fail, because some other merge request was already in the pipeline and got merged before your pipeline finished. However, nowadays you don't need to rebase yourself, once you assign the MR to Marge and she will do that for you when she starts to handle your merge request. > * I rebased, but still Gitlab refused to merge: now it expects the > pipelines to be runagain! I'm really sorry for your frustration, but if you're sure that the merge failed only because if flaky tests, then simply reassigning the MR to Marge will do. > Is it really necessary to go to git command line to get a PR > merged!? (I was forced to do so 2-3 times now, but it's a hassle.) No, it is not necessary, because Marge will do that for you, once you assign the MR to her. > Or run pipelines over and over until one eventually succeeds? This is only a problem because of the flaky tests, and yes, we should do something about this. > Sorry for the rant, but I didn't notice anybody else complain. Am I > the only bothered here? Or is there a better way here I don't know > of? As you sure have understood at this point, the answer is "Assign to Marge" ;) Best regards, Gert
Re: [Mesa-dev] Merge blocked
Hello Jose, On Tue, 2021-09-21 at 11:48 +, Jose Fonseca wrote: > Why doesn't Gilab allow one to merge manually? > > See https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12940: > > * Marge-bot failed to merge the PR due to 2 flaky tests, completely > unrelated to the commits in question. I can understand your frustration with the flaky tests, but I'm sure you know that having a CI is place helps a lot to not break most of the code, so merging without having to go through the CI is not really an option, even if we are all sensible adults. Maybe we all should just file bugs when we see a flaky test, so that those get flagged accordingly by the developers responsible for the related drivers. > > * I manually retried the failed tests, and they all passed, but > still Gitlab refused to allow to merge: it said I needed to rebase. This is, because Marge merged some other MR between the time you rebased the last time. Since the pre-merge CI was added and before Marge was introduced, this actually happened quite regularly: Press the Merge-when-pipeline-succeeds button and fail, because some other merge request was already in the pipeline and got merged before your pipeline finished. However, nowadays you don't need to rebase yourself, once you assign the MR to Marge and she will do that for you when she starts to handle your merge request. > * I rebased, but still Gitlab refused to merge: now it expects the > pipelines to be runagain! I'm really sorry for your frustration, but if you're sure that the merge failed only because if flaky tests, then simply reassigning the MR to Marge will do. > Is it really necessary to go to git command line to get a PR > merged!? (I was forced to do so 2-3 times now, but it's a hassle.) No, it is not necessary, because Marge will do that for you, once you assign the MR to her. > Or run pipelines over and over until one eventually succeeds? This is only a problem because of the flaky tests, and yes, we should do something about this. > Sorry for the rant, but I didn't notice anybody else complain. Am I > the only bothered here? Or is there a better way here I don't know > of? As you sure have understood at this point, the answer is "Assign to Marge" ;) Best regards, Gert
[Mesa-dev] Merge blocked
Why doesn't Gilab allow one to merge manually? See https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12940: * Marge-bot failed to merge the PR due to 2 flaky tests, completely unrelated to the commits in question. * I manually retried the failed tests, and they all passed, but still Gitlab refused to allow to merge: it said I needed to rebase. * I rebased, but still Gitlab refused to merge: now it expects the pipelines to be run again! * I've reassigned to marge-bot. But who knows if history won't repeat. It seems a waste of developer time and computer resources. Can't Gitlab be configured to reflect the fact we are all sensible adults here, and allow one to manually merge through the UI? Is it really necessary to go to git command line to get a PR merged!? (I was forced to do so 2-3 times now, but it's a hassle.) Or run pipelines over and over until one eventually succeeds? Why is something as easy as merging a PR is made so hard and wasteful!? Sorry for the rant, but I didn't notice anybody else complain. Am I the only bothered here? Or is there a better way here I don't know of? Jose
