Hi,
An issue recently came up in the GL working group: what is the robustness
behavior of framebuffer fetch? For example, if a framebuffer attachment
format is R8_UNORM, what are the YZW components which get read back?
If people from all the drivers (besides panfrost) which support this
extension
Hi all,
Gitlab is back enough for discussion and review. If you are a
developer/maintainer for a gallium driver/frontend/util/bug, you should be
checking out this MR from a couple weeks ago to make sure nothing breaks:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34054
I'm planning
Another one here:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33946
On Wed, Mar 5, 2025 at 7:36 AM Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:
> Hi,
>
> I'm working on some big refactorings for gallium to improve CPU
> performance. The fir
Hi,
I'm working on some big refactorings for gallium to improve CPU
performance. The first MR can be found here:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33813
If applicable, please review and sign off within the next couple days.
Given the speed with which mesa moves, I'd like
Hi,
If you aren't hitting the kopper init paths (e.g., kopper_init_screen),
you're doing something wrong.
I'm not sure exactly what's going on there with gfxstream, but for gbm+zink
you should be getting a backtrace like this on init:
#0 kopper_init_screen (screen=0x25e010, driver_name_is_inferr
On Wed, Jun 19, 2024 at 1:22 PM Triang3l wrote:
> The shader compiler in R600g is actively developed (and I think OpenGL 4.6
> support is among the main goals), I don't see why it needs to be moved to a
> low-priority branch or to stop getting new NIR infrastructure updates
> with the
> current a
In looking at the gallium tree, I'm wondering if it isn't time for a second
amber branch to prune some of the drivers that cause pain when doing big
tree updates:
* nv30
* r300
* r600
* lima
* virgl
* tegra
* ???
There's nothing stopping these drivers from continuing to develop in an
amber branch
This doesn't solve the problem about missing CLC, but I pass
-Dintel_rt=disabled to avoid the whole thing.
On Fri, Apr 5, 2024, 6:05 PM Brian Paul wrote:
> I'm trying to build the Intel Vulkan driver. First time in a few
> months. I'm having build problems related to clc. I'm on Ubuntu 22.04
Hi,
In recent times, Mesa CI has grown the clang-format job which enforces
formatting in some parts of the tree.
I hate this job, and I think the majority of Mesa developers also hate this
job. This majority is, of course, excluding a small number of very vocal
enthusiasts, as seen in e.g.,
https
On one hand I think it's a great idea. Moving code out of drivers to common
means fixing bugs helps everyone, and implementing new features is the same.
On the other hand, everyone's already got code that works, which means both
a lot of work to switch that code over to common and then the usual c
Hi,
As everyone has likely noticed, we've had a significant uptick of spam on
Mesa-related IRC channels lately. Sometimes these occurrences go on for
many hours before someone takes action.
I'd like to request that all commonly-affected channels (#dri-devel,
#intel-3d, #freedesktop, ???) take som
; On Fri, May 5, 2023 at 5:33 PM Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
>
>> Can you provide a gfxreconstruct of the scenario?
>>
>> On Fri, May 5, 2023 at 10:32 AM George Karpathios
>> wrote:
>>
>>> Hi Mike,
>>>
&
e gotten a bit worse actually.
>
> Best regards,
> George
>
>
> On Fri, May 5, 2023 at 3:08 PM Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
>
>> Hi,
>>
>> Can you try commenting out the same lines from last time and see whether
>>
Hi,
Can you try commenting out the same lines from last time and see whether
that affects anything?
Mike
On Fri, May 5, 2023 at 7:30 AM George Karpathios wrote:
> Hi list,
>
> I'm using Lavapipe for Vulkan software rendering support in a modeling
> application. I notice a large performance hi
Hi,
We went through this already some time ago, but we've been getting
increasing amounts of spam in #dri-devel, and the current
number/availability of moderators doesn't appear to be sufficient. Can we
add some people to the ops list to improve the situation?
Thanks,
Mike
Hm that should probably query the total available memory on the system. You
can submit an MR to make that change if you're interested?
Mike
On Tue, Apr 11, 2023 at 9:35 AM George Karpathios wrote:
> Hi list,
>
> I'd like to ask how I can increase the memory of the Lavapipe device
> over 2GB th
ry* nice frame times. Great catch, thank you!
> But I don't see anything on the viewport, I guess due to the early return.
> How should I proceed?
>
> Best regards,
> George
>
>
> On Fri, Apr 7, 2023 at 4:56 PM Mike Blumenkrantz <
> michael.blumenkra...@gmail.co
Looks like it's compiling a lot of shader variants.
You could try adding a return at the top of update_inline_shader_state() to
see if it's trying too hard to inline.
On Fri, Apr 7, 2023 at 9:53 AM George Karpathios wrote:
> Hi again, thank you Adam & Marek for your feedback! I appreciate it.
>
Hi,
After some vigorous and robust discussion with Erik, we've decided that
zink will no longer require any rb/ab/etb tags to be applied to patches in
MRs.
Following in Turnip's footsteps, any MR that receives sufficient reviewage
in gitlab comments can be merged directly with no further action n
Hi,
In accordance with some gitlab discussions, I'm looking at removing
rbug/xvmc/graw tests
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18705
If you have feedback about this, please comment on the merge request.
Mike
Hi,
I did a GL 4.6 CTS run today on a very recent version of CTS, and I found a
class of tests which target failure cases (specifically return codes) for
various API. A number of these tests failed, which means they fail for all
Mesa drivers, which means the upcoming CTS release will be impossible
Actually I lied: the lavapipe patch can't be applied to that branch, so it
can be ignored too.
On Fri, Apr 22, 2022 at 6:53 AM Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:
> You can just drop the zink patches. I'll make a staging MR for the
> lavapipe one.
&g
You can just drop the zink patches. I'll make a staging MR for the lavapipe
one.
Thanks again for all your work!
On Fri, Apr 22, 2022 at 12:56 AM Dylan Baker wrote:
> Hi all,
>
> I've spent a good deal of time this week crushing the backlog of
> patches on the mesa 20.0 series before making the
We might want to consider pushing out the branch point a week anyway to
help people get CTS in order?
On Fri, Jan 7, 2022 at 1:08 PM Ian Romanick wrote:
> Blarg. That all sounds awful. I think (hope!) I speak for everyone when
> I say that we all appreciate your and daniels' efforts to keep thi
On Wed, Oct 6, 2021 at 2:46 PM Jason Ekstrand wrote:
> On Wed, Oct 6, 2021 at 12:37 PM Mike Blumenkrantz
> wrote:
> >
> > On Wed, Oct 6, 2021 at 1:27 PM Bas Nieuwenhuizen <
> b...@basnieuwenhuizen.nl> wrote:
> >>
> >> On Wed, Oct 6, 2021 at 7:07 PM
On Wed, Oct 6, 2021 at 1:27 PM Bas Nieuwenhuizen
wrote:
> On Wed, Oct 6, 2021 at 7:07 PM Jason Ekstrand
> wrote:
> >
> > On Wed, Oct 6, 2021 at 11:24 AM Emma Anholt wrote:
> > >
> > > On Wed, Oct 6, 2021 at 9:20 AM Mike Blumenkrantz
> > > wr
Hi,
It's recently come to my attention that gitlab has Approvals. Was anyone
else aware of this feature? You can just click a button and have your name
recorded in the system as having signed off on landing a patch? Blew my
mind.
So with that being said, we also have this thing in the Mesa repo w
You can drop the zink patches, I have a hard time figuring out how time
works these days.
On Wed, Sep 15, 2021, 1:09 PM Dylan Baker wrote:
> Hi everyone, there's a few patch now outstanding for the 21.2 branch,
> and I'd like to get some help from the relavent develoeprs on either
> backporting
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10144 should do
it.
On Fri, Apr 9, 2021 at 12:50 PM Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:
> Hi,
>
> I'll take care of all the lavapipe ones and get a MR up for you later
> today.
>
>
>
Hi,
I'll take care of all the lavapipe ones and get a MR up for you later today.
Mike
On Fri, Apr 9, 2021, 12:39 PM Dylan Baker wrote:
> Hi all,
>
> I've been a little behind on release work recently, and I'm tryinng to
> cleanup the backlog of patches against the 21.0 branch that haven't bee
> 4096 is the minimum maximum that Vulkan supports. I believe that's what
> Nvidia and AMD's Windows Vulkan drivers say.
>
> If you want your Vulkan app to be really cross-platform it's a limit to
> be aware of.
>
> -Brian
>
>
> &g
zink ones done here
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9504
On Wed, Mar 10, 2021 at 3:39 PM Dylan Baker wrote:
> Hi list,
>
> I think we're just about ready for the mesa 21.0 release. Sorry I've
> been really about this. Here's a lis tof all outstanding patches that
> eith
+1 always in favor of getting more people into the review pipeline
On Thu, Jan 21, 2021 at 10:05 AM Alyssa Rosenzweig <
alyssa.rosenzw...@collabora.com> wrote:
> Hi all,
>
> Icecream95[1], a long-time Mesa/Panfrost contributor, has requested
> developer access to mesa on the GitLab issue tracker
Hi Ilia,
I'm not entirely sure what you're asking here.
This patch doesn't change anything related to gl_Layer reads, it just
forces the geometry shader codepath unconditionally when VS_LAYER_VIEWPORT
isn't enabled in order to successfully write the gl_Layer output. If
anything, this should be be
Hey, congrats! That's awesome!
On Tue, Nov 24, 2020 at 6:24 AM apinheiro wrote:
> So just a for your information, we submitted v3dv for Vulkan 1.0
> conformance around one month ago, in behalf of the Raspberry Foundation,
> and it is not official [1]. Here the Foundation blog post [2].
>
> We wa
Possibly worth noting as another point for reference is that zink also uses
variables.
On Sun, Oct 11, 2020, 11:08 AM Jason Ekstrand wrote:
> First off, I should point out that the AMD NIR -> LLVM translator is,
> as far as I know, the only NIR back-end that consumes variables at
> all. Most ba
Hi All,
I was thinking it'd be nice to have labels in Mesa for difficulty in order
to help both newer and more experienced contributors choose issues/MRs
which fit their level of comfort and available time. This might look like:
* easy
* challenging
* impossible
Naturally we could then also crea
Thanks all!
On Mon, Aug 3, 2020, 12:20 PM Kenneth Graunke wrote:
> On Friday, July 31, 2020 7:14:49 AM PDT Mike Blumenkrantz wrote:
> > Hi,
> >
> > I'd like to request marge access for the piglit and mesa gitlab projects.
> > I've been contributing a
Hi,
I'd like to request marge access for the piglit and mesa gitlab projects.
I've been contributing a number of patches here (primarily to
zink/gallium), and this would be useful in my continued work.
Regards,
Mike (zmike)
___
mesa-dev mailing list
me
39 matches
Mail list logo
