Re: [BUG][AMD][VDPAU] RX6600 GPU locks up when decoding HEVC
Hi, Please use the issue tracker on the Mesa Gitlab for discussing bug reports. I recommend to include all information that you can in there, we don't use this mailing list for bug reports. Thanks & best regards, Timur On Thu, 2024-02-15 at 17:23 +, Chris Rankin wrote: > Thanks, I have discovered that my PC needs for VLC to use hardware > decoding when playing 4K HEVC streams, but that VLC won't support > VA-API again until VLC 4 is released. > > As an aside, one of these 4K HEVC streams correctly uses VDPAU if I > use: > > $ mpv --vo=gpu --hwdec=vdpau --hwdec-image-format=yuv420p > > but uses software decoding if I remove the > '--hwdec-image-format=yuv420p' parameter because: > > [vd] Opening decoder hevc > [vd] Looking at hwdec hevc-vdpau... > [vd] Trying hardware decoding via hevc-vdpau. > [vd] Selected codec: hevc (HEVC (High Efficiency Video Coding)) > [vd] Pixel formats supported by decoder: vaapi vdpau cuda yuv420p10le > [vd] Codec profile: Main 10 (0x2) > [ffmpeg] AVHWFramesContext: Unsupported sw format: yuv420p10le > Failed to allocate hw frames. > [vd] Requesting pixfmt 'yuv420p10le' from decoder. > [vd] Attempting next decoding method after failure of hevc-vdpau. > [vd] Skipping previously attempted hwdec: hevc-vdpau > [vd] Using software decoding. > > Does this look like another Mesa / VDPAU bug (i.e. should I raise a > new issue for it?), or is it actually a problem with mpv? > > Cheers, > Chris > > On Thu, 15 Feb 2024 at 16:01, Liu, Leo wrote: > > > > [AMD Official Use Only - General] > > > > This is being looked. > > > > > -Original Message- > > > From: mesa-dev On Behalf > > > Of > > > Chris Rankin > > > Sent: Thursday, February 15, 2024 10:38 AM > > > To: mesa-dev@lists.freedesktop.org > > > Subject: [BUG][AMD][VDPAU] RX6600 GPU locks up when decoding HEVC > > > > > > I have discovered that my RX6600 cannot use VDPAU to decode HEVC, > > > although > > > VA-API works OK. Unfortunately, VLC 3.x only supports VDPAU these > > > days for > > > hardware decoding. > > > > > > I have raised this issue: > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/10599 > > > > > > Mesa 23.3.5 just used to fail, but both Mesa 24.0.1 and 24.1.0- > > > devel actually > > > lock up the GPU and force me to reboot my PC. > > > > > > According to vdpauinfo: > > > > > > name level macbs width height > > > > > > ... > > > HEVC_MAIN 186 139264 8192 4352 > > > HEVC_MAIN_10 186 139264 8192 4352 > > > HEVC_MAIN_STILL --- not supported --- > > > HEVC_MAIN_12 --- not supported --- > > > HEVC_MAIN_444 --- not supported --- > > > HEVC_MAIN_444_10 --- not supported --- > > > HEVC_MAIN_444_12 --- not supported --- > > > ... > > > > > > Cheers, > > > Chris
Re: Issue with Radeon graphics on PopOS using mesa
Hi, Please open an issue here: https://gitlab.freedesktop.org/mesa/mesa/-/issues (This mailing list is not for discussing bugs.) Thanks & best regards, Timur On Thu, 2024-01-04 at 12:05 +0100, Joe LePaul wrote: > Dear Mesa developers, > > are you aware of this issue and know of a solution? > https://github.com/pop-os/mesa/issues/26 > > Cheers, > Joe
Re: [radeonsi] RUSTICL and AMD_DEBUG=useaco SIGFAULT / SIGABRT
Hello Dieter, Please note that RadeonSI + ACO combination is very experimental at the moment, so it is expected that some things will break. For this concrete issue, take a look at this MR to see if it helps: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24112 It is of course very possible that there will be other issues after this which will need to be investigated further. In the future, I recommend opening an issue on Mesa GitLab: https://gitlab.freedesktop.org/mesa/mesa/-/issues Best regards, Timur On Tue, 2023-07-11 at 15:09 +0200, Dieter Nützel wrote: > Hello List, > > running clinfo under RUSTICL on my Polaris 20, RX580 explode with ACO > compiler. > > AMD_DEBUG=useaco > > RUSTICL_ENABLE=radeonsi > RUSTICL_FEATURES=fp64 > > > Greetings, > Dieter > > > (gdb) r > Starting program: /usr/bin/clinfo > Downloading separate debug info for system-supplied DSO at > 0x77fc7000 > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Downloading separate debug info for > /usr/local/lib64/libRusticlOpenCL.so.1 > [New Thread 0x7fffebfff6c0 (LWP 2435)] > [New Thread 0x7fffeb6bd6c0 (LWP 2436)] > [New Thread 0x7fffeaebc6c0 (LWP 2437)] > [New Thread 0x7fffea6bb6c0 (LWP 2438)] > Number of platforms 1 > Platform Name rusticl > Platform Vendor Mesa/X.org > Platform Version OpenCL 3.0 > Platform Profile FULL_PROFILE > Platform Extensions > cl_khr_byte_addressable_store cl_khr_create_command_queue > cl_khr_extended_versioning cl_khr_icd cl_khr_il_program > cl_khr_spirv_no_integer_wrap_decoration > Platform Extensions with Version > cl_khr_byte_addressable_store > 0x40 (1.0.0) > > cl_khr_create_command_queue > 0x40 (1.0.0) > > cl_khr_extended_versioning > 0x40 (1.0.0) > > cl_khr_icd > 0x40 (1.0.0) > > cl_khr_il_program > 0x40 (1.0.0) > > cl_khr_spirv_no_integer_wrap_decoration > 0x40 (1.0.0) > Platform Numeric Version 0xc0 (3.0.0) > Platform Extensions function suffix MESA > Platform Host timer resolution 1ns > > Platform Name rusticl > Number of devices 1 > Device Name AMD Radeon RX 580 > Series (polaris10, LLVM 17.0.0git, DRM 3.52, 6.4.2-1.ge2dafc9- > default) > Device Vendor AMD > Device Vendor ID 0x1002 > Device Version OpenCL 3.0 > Device UUID > -0100--- > Driver UUID > 414d442d-4d45-5341-2d44-5256 > Valid Device LUID No > Device LUID - > Device Node Mask 0 > Device Numeric Version 0xc0 (3.0.0) > Driver Version 23.2.0-devel > (git-0695ead057) > Device OpenCL C Version OpenCL C 1.2 > Device OpenCL C Numeric Version 0x402000 (1.2.0) > Device OpenCL C all versions OpenCL > C > 0xc0 (3.0.0) > OpenCL > C > 0x402000 (1.2.0) > OpenCL > C > 0x401000 (1.1.0) > OpenCL > C > 0x40 (1.0.0) > Device OpenCL C features > __opencl_c_integer_dot_product_input_4x8bit_packed > 0x80 (2.0.0) > > __opencl_c_integer_dot_product_input_4x8bit > 0x80 (2.0.0) > > __opencl_c_fp64 > 0x40 (1.0.0) > > __opencl_c_int64
Re: Problem with MESA-INTEL
Hi Larry, This mailing list is mostly for Mesa development and not for end user support. The best way to get help with Mesa driver problems is to open an issue here: https://gitlab.freedesktop.org/mesa/mesa/-/issues Hope this helps, Timur Larry Finger ezt írta (időpont: 2023. jún. 26., Hét 1:29): > On 6/25/23 14:37, Larry Finger wrote: > > Hi, > > > > I am new to the list, and hope that this is the correct place for this > > information. If not, suggestions would be appreciated. > > > > Beginning last week, Google Chrome started failing on my openSUSE > Tumbleweed. > > When it is started from the command line, the following is logged: > > > > finger@localhost > :~/home:lwfinger:branches:Virtualization/virtualbox>google-chrome-stable > > MESA-INTEL: warning: Haswell Vulkan support is incomplete > > MESA-INTEL: warning: Haswell Vulkan support is incomplete > > [567:567:0625/141831.899006:ERROR:vaapi_wrapper.cc(875)] > > vaQueryConfigEntrypoints failed, VA error: the requested VAProfile is > not supported > > [567:567:0625/141831.899241:ERROR:vaapi_wrapper.cc(875)] > > vaQueryConfigEntrypoints failed, VA error: the requested VAProfile is > not supported > > [567:567:0625/141831.899388:ERROR:vaapi_wrapper.cc(875)] > > vaQueryConfigEntrypoints failed, VA error: the requested VAProfile is > not supported > > [567:567:0625/141831.899540:ERROR:vaapi_wrapper.cc(875)] > > vaQueryConfigEntrypoints failed, VA error: the requested VAProfile is > not supported > > [567:567:0625/141833.018341:ERROR:shared_context_state.cc(81)] Skia > shader > > compilation error > > > > A lot more is output to the terminal, but until it is verified that this > is the > > correct place for this problem, that will be withheld. > > > > The running kernel is 6.4.0-rc7 from drm-tip of the i915 group. > > > > The lspci command shows the graphics device to be > > 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core > > Processor Integrated Graphics Controller [8086:0416] (rev 06) > > > > A separate box with an 8th generation i7 CPU is OK. > > > > Thanks for reading, > > I am not sure what fixed the problem, but my distro released kernel 6.3.9 > today, > and chrome is working again. > > I still get those messages that I posted above, but nothing more. > > Sorry for the noise. > > Larry > >
Re: Fixing vkCmdDrawIndexedIndirect with index buffer offset for llvmpipe
Hello Lukas, I'm not a llmpipe developer, but I think the place for this discussion is on the Mesa gitlab. Feel free to open an issue about this there or better yet, submit a merge request with your proposed fix. Best regards, Timur ezt írta (időpont: 2023. febr. 19., Vas 12:10): > Hello everyone, > > newbie to the Mesa codebase here. > > I found that in the current main branch the llvmpipe Vulkan driver does > not produce correct results for `vkCmdDrawIndexedIndirect` when the > preceding call to `vkCmdBindIndexBuffer` passed a non-zero value for > `offset`. I poked around in the code a little bit, found that the > `offset` parameter is just not used at all for indirect draws and came > up with the following two solutions to fix my usecase: > > > 1) > > https://gitlab.freedesktop.org/luckyxxl/mesa/-/commits/fix_indirect_draw_ib_offset1 > > While this is a pretty minimal change I don't think it's a good one. > Adding `index_offset` to `struct pipe_draw_indirect_info` feels like a > hack. Also it will fail silently when `offset` is not a multiple of the > index type size, which is valid according to the Vulkan specification. > > 2) > > https://gitlab.freedesktop.org/luckyxxl/mesa/-/commits/fix_indirect_draw_ib_offset2 > > While this one adheres the Vulkan specification in that any value for > `offset` is supported, I feel like it is a fairly large/risky change. > `struct pipe_draw_info` is used throughout the codebase in various > utility functions and drivers, and I can't judge how big the impact of > the suggested change would be. Also, it seems to me that the code of > many drivers should be updated to handle the new parameter, though that > might not be necessary given that the new behavior cannot be triggered > via the OpenGL API (see below). How would such a global change be > handled if it's worth proceeding-on? > > > The issue can only be triggered using the Vulkan API, given that there's > no way (at least none that I know of / could find) to use an offset into > the index buffer for indirect draws with the OpenGL API. Therefore I > think that some changes to core data-structures/algorithms are necessary > in order to be able to implement the fix, unless I oversaw something. I > would be glad if someone could advise on how to proceed: Does it look > worth to you to try to upstream one of the two suggested fixes? In that > case I'd be happy to write a proper PR. Or is the issue better worked-on > by a developer who is experienced with the code, in that case I'll > gladly file an issue and provide a repro. Also, as a final feedback, is > this mailing-list the correct place to discuss such a matter, or would > that better be done in a PR or via IRC? > > Thank you for your time :) > > Lukas > >
Re: Gitlab filters in Gmail
How do you separate gitlab comments on merge requests and issues?
Timur
On Thu, 2022-07-14 at 05:28 -0400, Marek Olšák wrote:
> Hi,
>
> Gitlab emails are difficult to filter because issues and MRs are not
> easy to distinguish. I know that Matt has a script which does this,
> but since that was kind of difficult for me to set up, I resorted to
> these filters instead and they work pretty well.
>
> Matches: from:gitlab ("created a merge request" OR "pushed new
> commits to merge request" OR ("Merge request" AROUND 1 "was"))
> Do this: Apply label "MR"
>
> Matches: from:gitlab "Issue was closed by"
> Do this: Apply label "Issue Closed"
>
> Matches: from:gitlab "Merge request" AROUND 1 "was merged"
> Do this: Apply label "Merged"
>
> Matches: from:gitlab "Merge request" AROUND 1 "was closed"
> Do this: Apply label "MR Closed"
>
>
> Issues are not labeled and it doesn't seem possible, but anything
> that is not a MR should be a Gitlab issue.
>
> Marek
Re: Fwd: What's the point of use_elf_tls and USE_ELF_TLS?
Hello, Usage of the ELF TLS is documented here: https://docs.mesa3d.org/dispatch.html#elf-tls Hope this helps, Timur On Tue, 2022-06-21 at 15:25 +0800, 罗勇刚(Yonggang Luo) wrote: > > I've seen them always defined? Can we remove them? > > -- > 此致 > 礼 > 罗勇刚 > Yours > sincerely, > Yonggang Luo > >
Re: Fwd: Debian 11 libegl1-mesa (20.3.5-1) - backport a fix
Hello, You can find the upcoming stable releases in the Mesa release calendar: https://docs.mesa3d.org/release-calendar.html Only the last two point releases receive stable updates. Older versions are no longer supported and don't get new releases. Please ask your distro maintainers to upgrade to a supported version. Best regards, Timur On Mon, 2022-06-20 at 10:38 +0200, Hiren wrote: > I wonder if this should go into upstream mesa instead of debian 11? > > We are looking to have a fix in mesa 22.0 backported to mesa 20.3. > See > https://github.com/Smithay/smithay/issues/438#issuecomment-1159750086 > for details > > -- Forwarded message - > From: Hiren > Date: Sun, Jun 19, 2022 at 6:16 PM > Subject: Debian 11 libegl1-mesa (20.3.5-1) - backport a fix > To: > Cc: > > > Hi, > > Please see > https://github.com/Smithay/smithay/issues/438#issuecomment-1159750086 > > We're looking to backport a mesa 22.0 fix to 20.3 which is what > debian 11 ships with. > > Could you assist with how this can be done please. Thanks. >
Re: Replacing NIR with SPIR-V?
Hi Abel, On Sun, 2022-01-23 at 13:58 +0100, Abel Bernabeu wrote: > > That is the thing: there is already a community maintained LLVM > backend for RISC-V and I need to see how to get value from that > effort. And that is a very typical escenario for new architectures. > There is already an LLVM backend for a programmable device and > someone asks: could you do some graphics around this without spending > millions? While LLVM is a very good tool, it is not perfect and may not be the best tool for compiling shaders. For example, ACO (the Valve-funded compiler for AMD GPUs) was created despite the existence of an LLVM backend. Our main concerns were: 1. Games stuttering due to slow compilation speed. 2. We are part of the Mesa source tree so we can fix bugs without waiting for a new LLVM release. > > - Use Mesa as a framework and translate NIR to assembly (most likely > choice). I think this is the optimal solution. See below for a writeup about how this works in practice. > > - Use Mesa as a framework and translate NIR to LLVM IR with some > intrinsics, then feed the pre-existing LLVM backend. A viable choice if you want to benefit from the infrastructure in Mesa, but don't want to invest in a custom backend yet. You can always choose to create a custom backend later, if you reached the limits of what LLVM can do for you. > > - Use some new alternative, possibly a Mesa fork relying on the > Khronos SPIR-V to LLVM IR translator. Start fixing the tool for > supporting graphics... Make SPIR-V the IR that communicates frontend > and backend :-) I'm not familiar with those tools so I can't judge their viability. > > I am not thinking in terms of what is best for Mesa, but in terms of > how could the RISC-V community organize its effort given that an LLVM > backend is a given thing. > > I see the current reasons why NIR is preferred over SPIR-V in Mesa. > So far you have given me three > > - There is a well designed library for traversing NIR, whereas SPIR-V > defines nothing. > - The arrays and structs are lowered before the shader is passed to > the backend. > - You see SPIR-V as a "serializing" format for IR to be exchanged > through the network (like a .PNG for shaders), whereas NIR's focus is > more about how the data structures are represented in memory while in > use. SPIR-V and NIR are designed for two different purposes: - SPIR-V is meant to be a high-level platform-independent format and the input to a compiler. - NIR is an intermediate representation to be used internally by a shader compiler. NIR's job is to represent a shader in such a way that it will be fast and easy to modify and optimize. The process of compilation is roughly this: 1. SPIR-V or GLSL (or another representation) is parsed into NIR. 2. Various optimizations are applied. We have a wide range of optimizations and thanks to the nature of NIR, it's rather easy to create more if the need arises. 3. Various lowerings are applied. NIR can understand which instructions are available in your backend and which aren't. It transforms the unsupported instructions to use supported ones. 4. A backend compiler gets the NIR and parses it into its own backend- specific IR. This is easy because the backend will only see instructions that it actually supports on the target hardware. 5. The backend may do further optimization and finally emit machine code that the GPU can understand. If you are interested how to build an OpenGL driver in Mesa, I recommend watching the XDC 2018 talk by Kenneth Graunke who talks about why and how he made the Intel Iris driver: https://www.youtube.com/watch?v=XUis_0lMUBI If you are interested in learning more about how to build a backend that uses NIR, I recommend these talks: https://www.youtube.com/watch?v=7C4PmtqBVqo https://www.youtube.com/watch?v=XoGmKhb5vpg Hope this helps, Timur
Re: Moving code around, post classic
On Tue, 2021-12-07 at 08:19 -0500, Alyssa Rosenzweig wrote > > If it were just linked lists, I'd say someone should write the > Coccinelle to transform the tree to use the one in util and call it a > day. It's a bit more complicated though, NIR depends on GLSL types. > Though that could probably continue to live in its current location > even > if glsl moves? Might breed confusion. These GLSL types seem to be used by a lot more than just GLSL. To avoid some of the confusion, why not rename them to something like NIR types, or something along these lines?
Re: [Mesa-dev] Workflow Proposal
On Thu, 2021-10-07 at 09:38 +0300, Martin Roukala (néé Peres) wrote: > > I'm with Jordan and Emma on this. Just have Marge add as many > "Approved-by: @USERID" to every commit in the series as there are > people > who pressed the "Approve" button, and be done with it :) > > Since it is a different tag, we know it was a "Whole-MR ACK" rather > than > a per-patch one, which would come in the Reviewed/Acked/Tested-by > form. > > Thanks for raising this up Mike! > > Martin Hi, I've never had a problem with manually adding Reviewed-by tags, but best would be to have an approve or review button next to each commit, which would allow us to approve individual commits rather than entire merge requests. If GitLab only supports per-merge-request granularity, the approve approach sounds fine for merge requests that aren't cross-cutting and therefore don't need reviewers from multiple teams. (I guess these are the the majority of MRs.) However, for larger MRs that touch eg. multiple drivers and/or NIR, I think the old review process is better (until we can do per-commit approval in GitLab). Best regards, Timur
Re: [Mesa-dev] Let's enable _GLIBCXX_ASSERTIONS=1 on mesa debug builds
Matt Turner ezt írta (időpont: 2021. szept. 10., P 22:33): > On Fri, Sep 10, 2021 at 10:20 AM Timur Kristóf > wrote: > > > > Hi, > > > > We've been recently working on tracking down some "mysterious" crashes > > that some users experienced on distro builds of mesa but we couldn't > > reproduce locally, until we found out about _GLIBCXX_ASSERTIONS=1 which > > seems to be not enabled by default in mesa, but is enabled by a lot of > > distros. > > > > I realize that enabling it by default on all mesa builds would have > > performance implications, so I propose to just enable it by default in > > mesa debug builds. > > > > What do you think? Would this be okay with the mesa community? > > I've never heard of this before. According to the documentation [1] it is: > > > _GLIBCXX_ASSERTIONS > > > > Undefined by default. When defined, enables extra error checking in the > form of precondition assertions, such as bounds checking in strings and > null pointer checks when dereferencing smart pointers. > > Seems reasonable to enable it for debug builds if we're using C++ > features in Mesa that it covers. > While at it, do you think we should also use any of the other similar macros from the doc? I think _GLIBCXX_DEBUG and _GLIBCXX_SANITIZE_VECTOR look particularly useful. > [1] https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html >
[Mesa-dev] Let's enable _GLIBCXX_ASSERTIONS=1 on mesa debug builds
Hi, We've been recently working on tracking down some "mysterious" crashes that some users experienced on distro builds of mesa but we couldn't reproduce locally, until we found out about _GLIBCXX_ASSERTIONS=1 which seems to be not enabled by default in mesa, but is enabled by a lot of distros. I realize that enabling it by default on all mesa builds would have performance implications, so I propose to just enable it by default in mesa debug builds. What do you think? Would this be okay with the mesa community? Thanks & best regards, Timur
Re: [Mesa-dev] [RFC] Concrete proposal to split classic
Why not proceed with splitting the classic drivers including i965 as was discussed previously? Then, when you feel that crocus and i915g are ready to be default, you can simply delete i965 from the classic branch and tell users they can use mesa main once again. On Tue, 2021-06-15 at 20:03 -0500, Jason Ekstrand wrote: > I'm bringing this up via e-mail so it gets a wider audience. Given > how will crocus is working at this point, is like to propose we hold > off for about three more releases before we drop classic. This next > release, 21.2, we'll have crocus as an option with i965 as the > default. There will also be a -Dprefer-crocus meson options so > distros or individuals can attempt to flip it on. The release after > that, 21.3, we'll keep i965 in the tree but have crocus be the > default (assuming things are going well.) Some time in 2022, probably > after the 22.2 release or so, we'll delete classic. > > Why wait so long? Well, it just landed and we don't have a Cherryview > story yet so I'm hesitant to make it the default too quickly. Even if > it were the default in 21.2, it's already too late, likely, to hit > the fall 2021 distro release cycle. If we flip it to the default > before the end of the year, that'll get crocus into spring distros. > This is good because 22.04 is an Ubuntu LTS release and I think > they'd rather bump crocus versions to fix bugs than backport on top > of i965. But that's really fort Ubuntu to decide. In any case, we > won't see broad-spread usage and the flood of bug reports until next > spring so we may want to wait until then to stay deleting code. > > If we wanted to accelerate things, one option, once we're ready, > would be to ask the person who manages the oibaf PPA to switch to > crocus early. That may get some early adopters on board. > > Thoughts? > > --Jason > > On April 9, 2021 22:09:14 Dylan Baker wrote: > > > Quoting Dylan Baker (2021-03-22 15:15:30) > > > Hi list, > > > > > > We've talked about it a number of times, but I think it's time > > > time to > > > discuss splitting the classic drivers off of the main development > > > branch > > > again, although this time I have a concrete plan for how this > > > would > > > work. > > > > > > First, why? Basically, all of the classic drivers are in > > > maintanence > > > mode (even i965). Second, many of them rely on code that no one > > > works > > > on, and very few people still understand. There is no CI for most > > > of > > > them, and the Intel CI is not integrated with gitlab, so it's > > > easy to > > > unintentionally break them, and this breakage usually isn't > > > noticed > > > until just before or just after a release. 21.0 was held up (in > > > small > > > part, also me just getting behind) because of such breakages. > > > > > > I konw there is some interest in getting i915g in good enough > > > shape that > > > it could replace i915c, at least for the common case. I also am > > > aware > > > that Dave, Ilia, and Eric (with some pointers from Ken) have been > > > working on a gallium driver to replace i965. Neither of those > > > things are > > > ready yet, but I've taken them into account. > > > > > > Here's the plan: > > > > > > 1) 21.1 release happens > > > 2) we remove classic from master > > > 3) 21.1 reaches EOL because of 21.2 > > > 4) we fork the 21.1 branch into a "classic-lts"¹ branch > > > 5) we disable all vulkan and gallium drivers in said branch, at > > > least at > > > the Meson level > > > 6) We change the name and precidence of the glvnd loader file > > > 7) apply any build fixups (turn of intel generators for versions > > > >= 7.5, > > > for example > > > 8) maintain that branch with build and critical bug fixes only > > > > > > This gives ditros and end users two options. > > > 1) then can build *only* the legacy branch in the a normal Mesa > > > provides > > > libGL interfaces fashion > > > 2) They can use glvnd and install current mesa and the legacy > > > branch in > > > parallel > > > > > > Because of glvnd, we can control which driver will get loaded > > > first, and > > > thus if we decide i915g or the i965 replacement is ready and turn > > > it on > > > by default it will be loaded by default. An end user who doesn't > > > like > > > this can add a new glvnd loader file that makes the classic > > > drivers > > > higher precident and continue to use them. > > > > > > Why fork from 21.1 instead of master? > > > > > > First, it allows us to delete classic immediately, which will > > > allow > > > refactoring to happen earlier in the cycle, and for any fallout > > > to be > > > caught and hopefully fixed before the release. Second, it means > > > that > > > when a user is switched from 21.1 to the new classic-lts branch, > > > there > > > will be no regressions, and no one has to spend time figuring out > > > what > > > broke and fixing the lts branch. > > > > > > When you say "build and critical bug fixes", what do you mean? > > > > > > I mean update
[Mesa-dev] How can we help improve Mesa stable releases and distro adoption?
Hi Everyone, We've talked about these issues in the RADV team recently, and we believe they concern everyone else too, so I'd like to propose a discussion about stable releases. 1. How can we help make the release manager's job easier? Dylan, could you share with us how this process works? I admit that I'm not sure how much effort needs to go into creating stable releases such as 20.3.X. How much of it is automated, what do you need to do manually? How much testing needs to go into a release? Most importantly, what could we (the dev team) do to help you? 2. How can we help distro maintainers ship up to date stable releases? For example, latest Ubuntu and Pop! OS are stuck at mesa 20.2.x, but Ubuntu LTS and Linux Mint have it even worse at mesa 20.0.x (according to distrowatch). I think this is sad because these are considered very popular and are often suggested to beginners and gamers. In reality, people who run these distros won't be able to use the latest HW, won't benefit from any of the work we put into mesa drivers during the past 6+ months and will experience all the bugs which we have solved a long time ago. (I know there are 3rd party repositories which cater to this, but that's not the same as getting 1st party support from an OS vendor.) What could we do to make the job of distro package maintainers easier and to compel them to upgrade to better supported releases? Maybe we could make fewer new mesa releases per year, but support each release for longer? Or try to better line up the mesa releases with distro releases? I'd really like to hear it from a distro maintainer's point of view, what keeps you on a release as old as 20.0 or 20.2 when you know that this seriously hurts your user experience? Best regards, Timur ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 20.3 status
Hi Dylan, Here is a merge request with the RADV and ACO patches on your list: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9557 I'd like to give some time for the team to review this and if no issues are found, this can go into 20.3. We don't actually want to have these in 20.3: - c40ea24ee0 radv: fix overflow when computing the SQTT buffer size - 5b5cd18853 radv: inhibit clock gating when tracing with SQTT I'm not sure what to do about these two, so I skipped them for now: - f695957421 radv: move queue object to a common base object - bd98fc39ae radv: reset object base on recycled command buffers Best regards, Timur On Thu, 2021-03-11 at 16:53 -0800, Dylan Baker wrote: > Hi list, > > Mesa 21.0.0 is now out the door. We're really behind on the 20.3 > branch, > but I'm just too exhuasted to try to keep maintaining both branches, > especially with 21.1 coming up, so I'm planning to do one more release > of 20.3.x along with this. You can see the current status of the branch > on githlab. The following are patches that 1) don't apply cleaningly, > 2) > don't compile, or 3) cause regressions in the CI. > > I'm hoping to make the final release (barring any pressing regressions > in this release) next wedensday. If you see something in here that you > want to see in that release, please create an MR agianst the > staging/20.3 branch. > > Cheers, > Dylan > > P.S. If you're interested in helping with releases, I'd love to talk > with you about it :) > > Outstanding patches: > > 9f2afe4170 v3dv: fix incorrect slice selection for TFU > jobs > > > > 2832cbea7a v3dv: fix BO list for TFU > jobs > > > > e5499ca2bf freedreno/a6xx: Fix SP_HS_UNKNOWN_A831 value and document > it > > > > 2d0c723ce6 radv: make sure FMASK compression is enabled for MSAA > copies > > > > 6b538506f2 aco/ra: Fix register allocation for subdword > operands > > > > b6b6d1ff3c radeonsi: fix hang caused by for loop with exec=0 in LS and > ES > > > > 38823ba60d panfrost: Fix estimate_texture_payload_size() on > Bifrost > > > > 198c3acacf r600/sfn: fix use of > b32all/and > > > > > 914c61d6c0 radv,aco: don't use MUBUF for multi-channel loads on GFX8 > with > robustness2 > > > > d74b012260 zink: fix vertex-stride > wrangling > > > > c40ea24ee0 radv: fix overflow when computing the SQTT buffer > size >
Re: [Mesa-dev] Rename "master" branch to "main"?
On Thu, 2020-08-06 at 14:17 +0200, Eric Engestrom wrote: > > There is an upstream issue about having gitlab handle the branch > renaming and provide redirections, MR re-targeting, etc. > > https://gitlab.com/gitlab-org/gitlab/-/issues/233427 > > If we wait for this feature instead of doing it by hand, it could be > much less disruptive to devs and everyone downstream from us, but > there's also no telling how long this will take. Sounds like this would save us a lot of hassle. If we are not in a hurry, I think the best option for us is to wait for this upstream issue. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
Hey Everyone, I've noticed a weird change on the new website, specifically on the release notes page, such as this one: https://docs.mesa3d.org/relnotes/20.1.0.html On the old site, the commits were grouped by authors. On the new site, there is no mention of the people who contributed to a release, only the list of commits is presented. Is this intentional? Could we change it back? I really liked how the old site gave a mention to everyone involved. Best regards, Timur On Sun, 2020-06-14 at 18:22 +0200, Dieter Nützel wrote: > GREAT work! > > Now, it's working with Konqueror (20.04.1 / Frameworks 5.70.0) - even > if > without 'hovered animation'... ;-) > > Greetings, > Dieter > > Am 14.06.2020 17:25, schrieb Daniel Stone: > > Hi, > > > > On Fri, 29 May 2020 at 10:08, Erik Faye-Lund > > wrote: > > > In the light of the explanation above, do you still have > > > objections to > > > this split? > > > > > > Obviously, we haven't moved forward yet ;-) > > > > Well, we have now after getting some agreement. Please enjoy your > > shiny new https://www.mesa3d.org and https://docs.mesa3d.org > > experience. > > > > Brian, could you please change the DNS for mesa3d.org and > > www.mesa3d.org to point to 35.227.58.183? No need to change > > archive.mesa3d.org, that should still point to the old site. > > > > Cheers, > > Daniel > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Memory allocation on Mesa
On Tue, 2020-05-12 at 08:51 +, Tamminen, Eero T wrote: > Hi, > > On Tue, 2020-05-12 at 10:36 +0200, Timur Kristóf wrote: > > On Mon, 2020-05-11 at 20:19 +, Tamminen, Eero T wrote: > > > I've done a lot of resource usage analysis at former job[1], but > > > I've > > > never had needed anything like that. malloc etc all reside in a > > > separate shared library from Mesa, so calls to them always cross > > > dynamic library boundary and therefore all of them can be caught > > > with > > > the dynamic linker features (LD_PRELOAD, LD_AUDIT...). > > > > I think he meant something like GCC's --wrap option, and wasn't > > talking > > about the dynamic linker. > > Using it requires relinking the SW to use, so I would use it only on > some embedded platform which dynamic linker doesn't support better > interception methods. Yes, I agree that the dynamic linker is probably the best way to deal with this kind of problem. > (Note: "--wrap" isn't GCC options, but one for binutils ld.) Indeed. Thanks for the correction. Timur ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Memory allocation on Mesa
On Mon, 2020-05-11 at 20:19 +, Tamminen, Eero T wrote: > Hi, > > On Mon, 2020-05-11 at 16:13 +, Jose Fonseca wrote: > > Some might retort: why not just play some tricks with the linker, > > and > > intercept all malloc/free calls, without actually having to modify > > any source code? > > > > Yes, that's indeed technically feasible. And is precisely the sort > > of trick I was planing to resort to satisfy VMware needs without > > having to further modify the source code. But for these tricks to > > work, it is absolutely imperative that one statically links C++ > > library and STL. The problem being that if one doesn't then > > there's > > an imbalance: the malloc/free/new/delete calls done in inline code > > on > > C++ headers will be intercepted, where as malloc/free/new/delete > > calls done in code from the shared object which is not inlined will > > not, causing havoc. This is OK for us VMware (we do it already for > > many other reasons, including avoiding DLL hell.) But I doubt it > > will be palatable for everybody else, particularly Linux distros, > > to > > have everything statically linked. > > Huh? > > I've done a lot of resource usage analysis at former job[1], but I've > never had needed anything like that. malloc etc all reside in a > separate shared library from Mesa, so calls to them always cross > dynamic library boundary and therefore all of them can be caught with > the dynamic linker features (LD_PRELOAD, LD_AUDIT...). I think he meant something like GCC's --wrap option, and wasn't talking about the dynamic linker. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Memory allocation on Mesa
On Mon, 2020-05-11 at 16:13 +, Jose Fonseca wrote: > Some might retort: why not just play some tricks with the linker, and > intercept all malloc/free calls, without actually having to modify > any source code? > > Yes, that's indeed technically feasible. And is precisely the sort > of trick I was planing to resort to satisfy VMware needs without > having to further modify the source code. But for these tricks to > work, it is absolutely imperative that one statically links C++ > library and STL. The problem being that if one doesn't then there's > an imbalance: the malloc/free/new/delete calls done in inline code on > C++ headers will be intercepted, where as malloc/free/new/delete > calls done in code from the shared object which is not inlined will > not, causing havoc. Wouldn't you face the same issue if you chose to wrap all calls to malloc and free in mesa, instead of relying on the linker? Any dynamically linked or 3rd party library, including the C++ standard library, will have no way of knowing about our wrapped malloc and free. Timur ___ 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 Sat, 2020-02-29 at 14:46 -0500, Nicolas Dufresne wrote: > > > > 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. > > In the mean time, you can help by taking the habit to use: > > git push -o ci.skip Thanks for the advice, I wasn't aware such an option exists. Does this also work on the mesa gitlab or is this a GStreamer only thing? How hard would it be to make this the default? > That's a much more difficult goal then it looks like. Let each > projects > manage their CI graph and content, as each case is unique. Running > more > tests, or building more code isn't the main issue as the CPU time is > mostly sponsored. The data transfers between the cloud of gitlab and > the runners (which are external), along to sending OS image to Lava > labs is what is likely the most expensive. > > As it was already mention in the thread, what we are missing now, and > being worked on, is per group/project statistics that give us the > hotspot so we can better target the optimization work. Yes, would be nice to know what the hotspot is, indeed. As far as I understand, the problem is not CI itself, but the bandwidth needed by the build artifacts, right? Would it be possible to not host the build artifacts on the gitlab, but rather only the place where the build actually happened? Or at least, only transfer the build artifacts on-demand? I'm not exactly familiar with how the system works, so sorry if this is a silly question. ___ 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 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 My 20 cents: 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. 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. 3. I completely agree with Pierre-Eric on MR 2569, let's not run the full CI pipeline on every change, only those parts which are affected by the change. It not only costs money, but is also frustrating when you submit a change and you get unrelated failures from a completely unrelated driver. Best regards, Timur ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Profile-guides optimizations
The GCC wiki says: "GCC uses execution profiles consisting of basic block and edge frequency counts to guide optimizations such as instruction scheduling, basic block reordering, function splitting, and register allocation." More info here: https://gcc.gnu.org/wiki/AutoFDO/Tutorial Timur On Friday, 14 February 2020, Marek Olšák wrote: > Yeah I guess it reduces instruction cache misses, but then other codepaths > are likely to get more misses. > > Does it do anything smarter? > > Marek > > On Thu., Feb. 13, 2020, 17:52 Dave Airlie, wrote: > > > On Fri, 14 Feb 2020 at 08:22, Marek Olšák wrote: > > > > > > I wonder what PGO really does other than placing likely/unlikely. > > > > With LTO it can do a lot more, like grouping hot functions into closer > > regions so they avoid TLB misses and faults etc. > > > > Dave. > > > -- Sent from my Sailfish device ___ 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
I think the question about PGO is this: are the profiles of the users' applications gonna be the same as the profile that is collected from the benchmarks? Eg. if the test benchmark uses different draw calls or triggers different shader compiler code paths than a your favourite game, in theory PGO could harm the performance of your game. Also, how do we prevent it from making bad decisions based on the hw that the profile was made on? For example, if you collect the profiling data from a machine that has a Polaris 10 GPU, then the profile will show that chip_class is extremely likely to be GFX8 and thus the PGO build will be optimized for that case. If I then run the same build on my Navi 10, the PGO build might actually be slower, because the driver needs to take a different code path than what the PGO build was optimized for. What do you guys think about this? Best regards, Timur On Thu, 2020-02-13 at 02:40 -0500, Marek Olšák wrote: > Can we automate this? > > Let's say we implement noop ioctls for radeonsi and iris, and then we > run the drivers to collect pgo data on any hw. > > Can meson execute this build sequence: > build with pgo=generate > run tests > clean > build with pgo=use > > automated as buildtype=release-pgo. > > Marek > > On Wed., Feb. 12, 2020, 23:37 Dieter Nützel, > wrote: > > Hello Marek, > > > > I hoped you would ask this... > > ...but first sorry for the delay of my announced numbers. > > Our family is/was sick, my wife more than me and our children are > > fine, > > again. > > So be lenient with me somewhat. > > > > Am 12.02.2020 19:46, schrieb Marek Olšák: > > > How do you enable LTO+PGO? Is it something we could enable by > > default > > > for release builds? > > > > > > Marek > > > > I think we can achieve this. > > > > I'm running with LTO+PGO 'release' since late December (around > > Christmas). > > My KDE Plasma5 (OpenGL 3.0) system/desktop was never > > agiler/fluider > > since then. > > Even the numbers (glmark2) show it. The 'glmark2' numbers are the > > best > > I've ever seen on this system. > > LTO offer only some small space reduction and hardly any speedup. > > But LTO+PGO is GREAT. > > > > First I compile with '-Db_lto=true -Db_pgo=generate'. > > > > mkdir build > > cd build > > meson ../ --strip --buildtype release -Ddri-drivers= > > -Dplatforms=drm,x11 > > -Dgallium-drivers=r600,radeonsi,swrast -Dvulkan-drivers=amd > > -Dgallium-nine=true -Dgallium-opencl=standalone -Dglvnd=true > > -Dgallium-va=true -Dgallium-xvmc=false -Dgallium-omx=disabled > > -Dgallium-xa=false -Db_lto=true -Db_pgo=generate > > > > After that my 'build' dir looks like this: > > > > drwxr-xr-x 8 dieter users4096 13. Feb 04:34 . > > drwxr-xr-x 14 dieter users4096 13. Feb 04:33 .. > > drwxr-xr-x 2 dieter users4096 13. Feb 04:34 bin > > -rw-r--r-- 1 dieter users 4369873 13. Feb 04:34 build.ninja > > -rw-r--r-- 1 dieter users 4236719 13. Feb 04:34 > > compile_commands.json > > drwxr-xr-x 2 dieter users4096 13. Feb 04:34 include > > drwxr-xr-x 2 dieter users4096 13. Feb 04:34 meson-info > > drwxr-xr-x 2 dieter users4096 13. Feb 04:33 meson-logs > > drwxr-xr-x 2 dieter users4096 13. Feb 04:34 meson-private > > drwxr-xr-x 14 dieter users4096 13. Feb 04:34 src > > > > time nice +19 ninja > > > > Lasts ~15 minutes on my aging/'slow' Intel Xeon X3470 Nehalem, > > 4c/8t, > > 2.93 GHz, 24 GB, Polaris 20. > > Without LTO+PGO it is ~4-5 minutes. (AMD anyone?) > > > > Then I remove all files/dirs except 'src'. > > > > Next 'installing' the new built files under '/usr/local/' (mostly > > symlinked to /usr/lib64/). > > > > Now run as much OpenGL/Vulkan progs as I can. > > Normaly starting with glmark2 and vkmark. > > > > Here comes my (whole) list: > > Knights > > Wireshark > > K3b > > Skanlite > > Kdenlive > > GIMP > > Krita > > FreeCAD > > Blender 2.81x > > digikam > > K4DirStat > > Discover > > YaST > > Do some 'movements'/work in/with every prog. > > + > > some LibreOffice work (OpenGL enabled) > > one or two OpenGL games > > and Vulkan games > > + > > run some WebGL stuff in my browsers (Konqi/FF). > > > > After that I have the needed '*.gcda' files in 'src'. > > > > Now second rebuild in 'src'. > > Due to the deleted files/dirs I can do a second 'meson' config run > > in my > > current 'build' dir. > > > > meson ../ --strip --buildtype release -Ddri-drivers= > > -Dplatforms=drm,x11 > > -Dgallium-drivers=r600,radeonsi,swrast -Dvulkan-drivers=amd > > -Dgallium-nine=true -Dgallium-opencl=standalone -Dglvnd=true > > -Dgallium-va=true -Dgallium-xvmc=false -Dgallium-omx=disabled > > -Dgallium-xa=false -Db_lto=true -Db_pgo=use > > > > After around 5-6 minutes (!!!) I can install the LTO+PGO 'release' > > build > > driver files and enjoy next level of OpenGL speed. > > Vulkan do NOT show such GREAT improvements. > > > > Only '-Db_lto=true -Db_pgo=generate' need ~3 times compilation and > > mostly linking time. > > > > Below
Re: [Mesa-dev] -fno-common build failures (default from upcoming gcc release 10)
I've fixed most of the problems in 2385, but the problem still remains in omx. Could someone who's familiar with omx please take a look? Alternatively, maybe we can try adding -fcommon to just omx, until this issue is resolved. On Tue, 2020-01-21 at 18:49 +0100, Bas Nieuwenhuizen wrote: > I think this ended up spawning a bunch of work in > https://gitlab.freedesktop.org/mesa/mesa/issues/2385 > > On Mon, Jan 20, 2020 at 3:41 PM Stefan Dirsch > wrote: > > Hi > > > > Starting from the upcoming GCC release 10, the default of -fcommon > > option will > > change to -fno-common. Due to this we're going to see a lot of > > build failures > > in Mesa drivers like > > > > multiple definition of `syncobj_handle'; src/amd/vulkan/9198681@@ > > vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o (symbol > > from plugin):(.text+0x0): first defined here > > [ 213s] > > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse- > > linux/bin/ld: > > src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_wayland.c.o > > (symbol from > > plugin): in function > > `radv_GetPhysicalDeviceWaylandPresentationSupportKHR': > > > > I'm wondering if there is already anybody working on fixing these > > issues or is > > it recommended to workaround it by setting -fcommon manually > > somehow? How can > > the latter be done when using meson/ninja as build tool? > > > > Thanks, > > Stefan > > > > Public Key available > > -- > > Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH > > Tel: 0911-740 53 0Maxfeldstraße 5 > > FAX: 0911-740 53 479 D-90409 Nürnberg > > http://www.suse.deGermany > > > > (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Requiring a full author name when contributing to mesa?
On Fri, 2019-12-13 at 11:00 +1100, Timothy Arceri wrote: > On 13/12/19 10:15 am, Alex Deucher wrote: > > What does the name matter? The name is the least of your worries. > > What if their patch uses a patented algorithm? Does anyone check > > for > > that? The whole Signed-off-by thing just just hazing for newbs. > > Someone took the time to write and submit a patch. We trust they > > did > > the right thing and didn't do anything illegal. It's on the > > reviewers > > to determine if the patch is reasonable and should be applied. The > > name is just window dressing. > > Yes exactly the name is just window dressing, where a window dressing > is > "designed to create a favourable impression". In this case to make > our > project look competently and professionally run at a glance. I've > been > lucky enough to be employed to work on this project for around 5 > years > now, but don't expect this to last forever. Eventually I'd like to > be > able to point out to future employers the work I've been doing for > all > this time. Personally I'd like the window dressing to look nice when > this time comes. > > If other developers don't care which was my original question then > I'll > stop wasting my time requesting people not use such author names. We review code, not people. I agree that we should prefer a 'real' name, but we shouldn't require it. Some people may have a good reason to conceal their identity. I get what you mean, but why do you feel that allowing people to contribute using a nickname is unprofessional? You can still tell your (hypothetical) future employer that you worked on a high-profile free / open source project where several big companies managed to work together. The fact that contributions from amateurs (with or without a 'proper' name) is accepted I think makes the project look better, not worse. Just my 20 cents. Best regards, Tim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Nine] 'meson: add -Werror=empty-body to disallow `if(x); `' - 'broke' Nine
I think it depends on how much time it adds to the CI.
If the overhead is negligible, then it makes a lot of sense to have CI
make a release build in addition to the debug ones.
While we are at it:
Would it be possible to add some CI tests to ensure that Nine doesn't
break (even if it builds), similarly to how some drivers run their CTS
tests in there? For instance, can we run Xnine or some other small
testing tool in the CI?
What do you think about this, Axel?
Thanks & best regards,
Tim
On Fri, 2019-10-25 at 11:48 +0100, Eric Engestrom wrote:
> (for the record, the MR has been reviewed and will be merged when the
> pipeline comes back all green)
>
> The problem is that the CI does debug builds, while this was
> a release-build-only issue.
>
> We could perform multiple types of builds each time, but that would
> multiply the CI time/cost; I'll take a look now to see the best way
> to
> do that and see if the time cost is reasonable.
> (Meson has 6 build types, so testing all of them is not reasonable,
> but
> maybe we can test debug and release)
>
>
> On Friday, 2019-10-25 10:49:04 +0200, Timur Kristóf wrote:
> > Hi guys,
> >
> > How is it possible that the CI didn't detect this problem?
> > Isn't there at least one build in the CI system which builds Nine?
> >
> > I've created a MR to deal with it:
> > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2465
> >
> > Best regards,
> > Tim
> >
> >
> > On Thu, 2019-10-24 at 23:31 +0200, Axel Davy wrote:
> > > Hi Dieter,
> > >
> > > Maybe the best fix would be to change the definition of WARN and
> > > DBG
> > > when DEBUG is disabled.
> > >
> > > The definitions are in nine_debug.h
> > >
> > > I haven't tried by maybe using "(void)" instead of nothing would
> > > work
> > > ?
> > >
> > > Yours,
> > >
> > > Axel
> > >
> > > On 24/10/2019 16:34, Dieter Nützel wrote:
> > > > Hello Eric,
> > > >
> > > > your mentioned commit
> > > > (8d43e2b2ded0fe3c82d49561cdab9f208f9e64b6)
> > > > broke
> > > > building with NIne (-Dgallium-nine=true) for me.
> > > >
> > > > starting with
> > > > [-]
> > > > e_st@sta/cubetexture9.c.o' -c
> > > > ../src/gallium/state_trackers/nine/cubetexture9.c
> > > > ../src/gallium/state_trackers/nine/cubetexture9.c: In function
> > > > ‘NineCubeTexture9_ctor’:
> > > > ../src/gallium/state_trackers/nine/cubetexture9.c:108:43:
> > > > error:
> > > > suggest braces around empty body in an ‘if’ statement
> > > > [-Werror=empty-body]
> > > > 108 | "but this is unimplemented\n");
> > > > | ^
> > > > cc1: some warnings being treated as errors
> > > >
> > > > --
> > > > Next
> > > >
> > > > /surface9.c.o' -c ../src/gallium/state_trackers/nine/surface9.c
> > > > ../src/gallium/state_trackers/nine/surface9.c: In function
> > > > ‘NineSurface9_GetContainer’:
> > > > ../src/gallium/state_trackers/nine/surface9.c:334:40: error:
> > > > suggest
> > > > braces around empty body in an ‘if’ statement [-Werror=empty-
> > > > body]
> > > > 334 | DBG("QueryInterface FAILED!\n");
> > > > |^
> > > > cc1: some warnings being treated as errors
> > > >
> > > > --
> > > >
> > > > @sta/swapchain9.c.o' -c
> > > > ../src/gallium/state_trackers/nine/swapchain9.c
> > > > ../src/gallium/state_trackers/nine/swapchain9.c: In function
> > > > ‘present’:
> > > > ../src/gallium/state_trackers/nine/swapchain9.c:737:51: error:
> > > > suggest
> > > > braces around empty body in an ‘if’ statement [-Werror=empty-
> > > > body]
> > > > 737 | pSourceRect->top, pSourceRect->bottom);
> > > > | ^
> > > > ../src/gallium/state_trackers/nine/swapchain9.c:741:47: error:
> > > > suggest
> > > > braces around empty body in an ‘if’ statement [-Werror=empty-
> > > > body]
> > > > 741 | pDestRect->top, pDestRect->bottom);
> > > > | ^
> > > > cc1:
Re: [Mesa-dev] [Nine] 'meson: add -Werror=empty-body to disallow `if(x); `' - 'broke' Nine
Hi guys,
How is it possible that the CI didn't detect this problem?
Isn't there at least one build in the CI system which builds Nine?
I've created a MR to deal with it:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2465
Best regards,
Tim
On Thu, 2019-10-24 at 23:31 +0200, Axel Davy wrote:
> Hi Dieter,
>
> Maybe the best fix would be to change the definition of WARN and DBG
> when DEBUG is disabled.
>
> The definitions are in nine_debug.h
>
> I haven't tried by maybe using "(void)" instead of nothing would work
> ?
>
> Yours,
>
> Axel
>
> On 24/10/2019 16:34, Dieter Nützel wrote:
> > Hello Eric,
> >
> > your mentioned commit (8d43e2b2ded0fe3c82d49561cdab9f208f9e64b6)
> > broke
> > building with NIne (-Dgallium-nine=true) for me.
> >
> > starting with
> > [-]
> > e_st@sta/cubetexture9.c.o' -c
> > ../src/gallium/state_trackers/nine/cubetexture9.c
> > ../src/gallium/state_trackers/nine/cubetexture9.c: In function
> > ‘NineCubeTexture9_ctor’:
> > ../src/gallium/state_trackers/nine/cubetexture9.c:108:43: error:
> > suggest braces around empty body in an ‘if’ statement
> > [-Werror=empty-body]
> > 108 | "but this is unimplemented\n");
> > | ^
> > cc1: some warnings being treated as errors
> >
> > --
> > Next
> >
> > /surface9.c.o' -c ../src/gallium/state_trackers/nine/surface9.c
> > ../src/gallium/state_trackers/nine/surface9.c: In function
> > ‘NineSurface9_GetContainer’:
> > ../src/gallium/state_trackers/nine/surface9.c:334:40: error:
> > suggest
> > braces around empty body in an ‘if’ statement [-Werror=empty-body]
> > 334 | DBG("QueryInterface FAILED!\n");
> > |^
> > cc1: some warnings being treated as errors
> >
> > --
> >
> > @sta/swapchain9.c.o' -c
> > ../src/gallium/state_trackers/nine/swapchain9.c
> > ../src/gallium/state_trackers/nine/swapchain9.c: In function
> > ‘present’:
> > ../src/gallium/state_trackers/nine/swapchain9.c:737:51: error:
> > suggest
> > braces around empty body in an ‘if’ statement [-Werror=empty-body]
> > 737 | pSourceRect->top, pSourceRect->bottom);
> > | ^
> > ../src/gallium/state_trackers/nine/swapchain9.c:741:47: error:
> > suggest
> > braces around empty body in an ‘if’ statement [-Werror=empty-body]
> > 741 | pDestRect->top, pDestRect->bottom);
> > | ^
> > cc1: some warnings being treated as errors
> >
> > --
> >
> > evice9.c.o' -c ../src/gallium/state_trackers/nine/device9.c
> > ../src/gallium/state_trackers/nine/device9.c: In function
> > ‘NineDevice9_ctor’:
> > ../src/gallium/state_trackers/nine/device9.c:296:49: error:
> > suggest
> > braces around empty body in an ‘if’ statement [-Werror=empty-body]
> > 296 | DBG("\033[1;32mCSMT is active\033[0m\n");
> > | ^
> > ../src/gallium/state_trackers/nine/device9.c: In function
> > ‘create_zs_or_rt_surface’:
> > ../src/gallium/state_trackers/nine/device9.c:1221:87: error:
> > suggest
> > braces around empty body in an ‘if’ statement [-Werror=empty-body]
> > 1221 | DBG("FIXME Used shared handle! This option isn't
> > probably handled correctly!\n");
> > > ^
> > ../src/gallium/state_trackers/nine/device9.c: In function
> > ‘NineDevice9_UpdateSurface’:
> > ../src/gallium/state_trackers/nine/device9.c:1307:53: error:
> > suggest
> > braces around empty body in an ‘if’ statement [-Werror=empty-body]
> > 1307 | pSourceRect->right, pSourceRect->bottom);
> > | ^
> > ../src/gallium/state_trackers/nine/device9.c:1309:68: error:
> > suggest
> > braces around empty body in an ‘if’ statement [-Werror=empty-body]
> > 1309 | DBG("pDestPoint = (%u,%u)\n", pDestPoint->x,
> > pDestPoint->y);
> > > ^
> > ../src/gallium/state_trackers/nine/device9.c: In function
> > ‘NineDevice9_StretchRect’:
> > ../src/gallium/state_trackers/nine/device9.c:1588:53: error:
> > suggest
> > braces around empty body in an ‘if’ statement [-Werror=empty-body]
> > 1588 | pSourceRect->right, pSourceRect->bottom);
> > | ^
> > ../src/gallium/state_trackers/nine/device9.c:1591:49: error:
> > suggest
> > braces around empty body in an ‘if’ statement [-Werror=empty-body]
> > 1591 | pDestRect->right, pDestRect->bottom);
> > | ^
> > ../src/gallium/state_trackers/nine/device9.c: In function
> > ‘NineDevice9_ColorFill’:
> > ../src/gallium/state_trackers/nine/device9.c:1786:41: error:
> > suggest
> > braces around empty body in an ‘if’ statement [-Werror=empty-body]
> > 1786 | pRect->right, pRect->bottom);
> > | ^
Re: [Mesa-dev] nir: Add ability for shaders to use window space coordinates - broken tessellation under NIR - bisected
Hi, I was able to reproduce the problem with heaven, and that the proposed patch fixes it, so I made a MR: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/402 Best regards, Tim On Thu, 2019-03-07 at 08:27 +0100, Timur Kristóf wrote: > Hi Dieter, > > Thanks for noticing this. > I think I made a mistake by setting window_space_position the way I > did. Should've only set that for vertex shaders. > > I believe this is the right thing to do: > https://gitlab.freedesktop.org/Venemo/mesa/commit/4d8b97bacbe14bd6584d7a45ff98e65dfcb4c02b > Still need to test it myself. If it works, I'll submit a MR. > > Let me know what you think. > Best regards, > Tim > > > On Thu, 2019-03-07 at 05:45 +0100, Dieter Nützel wrote: > > This commit (#317f10bf404) brake whole tessellation (empty parts of > > the > > screen) running UH under radeonsi NIR on Polaris 20 (RX580). > > > > 317f10bf404b562e1dda79c0636aee86beeccc2f is the first bad commit > > commit 317f10bf404b562e1dda79c0636aee86beeccc2f > > Author: Timur Kristóf > > Date: Tue Feb 5 18:08:24 2019 +0100 > > > > nir: Add ability for shaders to use window space coordinates. > > > > This patch adds a shader_info field that tells the driver to > > use > > window > > space coordinates for a given vertex shader. It also enables > > this > > feature > > in radeonsi (the only NIR-capable driver that supported it in > > TGSI), > > and makes tgsi_to_nir aware of it. > > > > Signed-Off-By: Timur Kristóf > > Tested-by: Andre Heider > > Tested-by: Rob Clark > > Reviewed-by: Timothy Arceri > > Reviewed-by: Eric Anholt > > > > :04 04 3123b07ce063ffd4fee56974c64c130f3e617373 > > df57eb5bb70c0e46583399c73db499e1970fdd1b M src > > > > Reverting it fixed UH. > > > > Sorry, I don't have time for a ticket, yet 'cause I badly need > > some > > sleep... > > > > Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] nir: Add ability for shaders to use window space coordinates - broken tessellation under NIR - bisected
Hi Dieter, Thanks for noticing this. I think I made a mistake by setting window_space_position the way I did. Should've only set that for vertex shaders. I believe this is the right thing to do: https://gitlab.freedesktop.org/Venemo/mesa/commit/4d8b97bacbe14bd6584d7a45ff98e65dfcb4c02b Still need to test it myself. If it works, I'll submit a MR. Let me know what you think. Best regards, Tim On Thu, 2019-03-07 at 05:45 +0100, Dieter Nützel wrote: > This commit (#317f10bf404) brake whole tessellation (empty parts of > the > screen) running UH under radeonsi NIR on Polaris 20 (RX580). > > 317f10bf404b562e1dda79c0636aee86beeccc2f is the first bad commit > commit 317f10bf404b562e1dda79c0636aee86beeccc2f > Author: Timur Kristóf > Date: Tue Feb 5 18:08:24 2019 +0100 > > nir: Add ability for shaders to use window space coordinates. > > This patch adds a shader_info field that tells the driver to > use > window > space coordinates for a given vertex shader. It also enables > this > feature > in radeonsi (the only NIR-capable driver that supported it in > TGSI), > and makes tgsi_to_nir aware of it. > > Signed-Off-By: Timur Kristóf > Tested-by: Andre Heider > Tested-by: Rob Clark > Reviewed-by: Timothy Arceri > Reviewed-by: Eric Anholt > > :04 04 3123b07ce063ffd4fee56974c64c130f3e617373 > df57eb5bb70c0e46583399c73db499e1970fdd1b M src > > Reverting it fixed UH. > > Sorry, I don't have time for a ticket, yet 'cause I badly need some > sleep... > > Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [MR] radeonsi: Use uniform location when calculating const_file_max.
Hi, The following MR fixes an issue we've discovered while working on NIR support for Gallium Nine. When there are NIR uniform variables whose location is explicitly set, radeonsi did not take that into account when calculating const_file_max, resulting in rendering glitches in some games. This patch fixes that. https://gitlab.freedesktop.org/mesa/mesa/merge_requests/271 Best regards, Tim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [MR] WIP: Improve TTN so it can be used by Gallium Nine
Hi, I've polished the MR according to feedback, and also added some additional fixes. Also removed the WIP tag. With these changes, most nine games we tested can work flawlessly on radeonsi with NIR. https://gitlab.freedesktop.org/mesa/mesa/merge_requests/225 Code reviews are very welcome. Best regards, Tim On Fri, 2019-02-08 at 12:09 +0100, Timur Kristóf wrote: > Hi, > > This MR is part of our ongoing work to support NIR in nine. We are > currently testing on radeonsi, but our ultimate goal with this is to > make it possible for nine to run with iris (and eventually zink). > > These patches give some polish to tgsi_to_nir (aka. TTN), so that it > can handle the TGSI input that it receives from nine. Any feedback on > this patch series is greatly welcome. > > Some games we tested are already playable on radeonsi with NIR (and > to > some degree on iris too, but with glitches). > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/225 > > Best regards, > Tim > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [MR] WIP: Improve TTN so it can be used by Gallium Nine
Hi, This MR is part of our ongoing work to support NIR in nine. We are currently testing on radeonsi, but our ultimate goal with this is to make it possible for nine to run with iris (and eventually zink). These patches give some polish to tgsi_to_nir (aka. TTN), so that it can handle the TGSI input that it receives from nine. Any feedback on this patch series is greatly welcome. Some games we tested are already playable on radeonsi with NIR (and to some degree on iris too, but with glitches). https://gitlab.freedesktop.org/mesa/mesa/merge_requests/225 Best regards, Tim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA
Tested-By: Timur Kristóf It may be worth to note that the issue addressed was with an external GPU (through Thunderbolt 3) and the performance benefit may be less extreme on a system on which the bandwidth isn't as constrained. (Also, the TB3 eGPU is still outperformed by a normal PCI-E GPU.) Cheers & best regards, Tim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
