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
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?
>
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
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
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
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
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,
>
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
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
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
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
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 distr
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.
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
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
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:
-
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
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
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
> >
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?
> >
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
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
> >
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
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
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
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
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
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:
> &g
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
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.
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.
>
>
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
.
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
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
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
35 matches
Mail list logo
