Re: [Mesa-dev] [RFC] Concrete proposal to split classic

[Emma Anholt]

On Tue, Jun 15, 2021 at 8:16 PM Jason Ekstrand  wrote:
>
> On Tue, Jun 15, 2021 at 8:46 PM Timothy Arceri  wrote:
> >
> > On 6/16/21 11:03 AM, 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?

It certainly is tempting to just throw away classic without going
through this LTS branch adventure (I might say "charade") for distros.
I really think that people with i8xx/r200/r100 are better served with
swrast than HW GL in an otherwise-current world of software, and for
an old-distro snapshot where lots of software *would* work on that
hardware, what we do in current Mesa doesn't matter.  i915's right at
the cusp of usefulness in my opinion, and I'd put r300 pretty close to
it.

If we're acting like this LTS branch is a serious thing, though, then
I don't see a good reason to wait until 2022.  Let "did they build
crocus" be the switch between current Mesa and LTS i965.

I really want !8044 and garbage-collecting huge swaths of the GLSL
compiler, and while 2022 may realistically be when we can do that by,
I think we'll be slower about pushing on it if people are thinking
"well, we can't delete anything till next year anyway".

> > I though the idea was to put everything in a classic branch and let distros 
> > run "classic" hardware from that. What happens after 3 releases does i965 
> > still go to the classic branch with the other classic drivers? If so is it 
> > really worth waiting just because Ubuntu might have to back-port a bug fix?
>
> Yeah, that was the idea.  However, with crocus in good shape and Emma
> Anholt working on i915g, it may be that the actual answer is we just
> throw away the classic drivers and the only thing you really need the
> old branch for is r200 and ancient nouveau.

i915g still has major issues: large vertex count crashes, lack of link
failures, and crashes on compile failures being the top ones.  Once I
get driver-produced link failures plumbed through gallium somehow
(feels possible now that we precompile, and vc4 really needs it for
conformance too) and the NIR stuff landed, I think it'll be a pretty
plausible driver, and probably on average better for users than the
bitrotted stuff we've shipped for the last decade.  Regression-free
would be a long road, though, and given a different compiler pipeline
that might schedule differently plus the texture phase limits,
possibly not tractable in practice.

By far the limiting factor for i915g progress now that I've got some
CI rigged up is review.  My preference would be that we all agree that
nobody wants to look at i915, and some responsible folks (ajax and a
couple Intel volunteers, perhaps?) bless me to merge without review
once an i915g-only MR has been up for a week.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] bad performance issue in GPU & CPU data sharing

[Emma Anholt]

On Mon, Jun 7, 2021 at 1:53 AM Zong, Wei  wrote:
>
>
>
> > -Original Message-
> > From: Palli, Tapani 
> > Sent: Thursday, June 3, 2021 1:23 PM
> > To: Zong, Wei ; mesa-dev@lists.freedesktop.org
> > Subject: Re: [Mesa-dev] bad performance issue in GPU & CPU data sharing
> >
> > Hi;
> >
> > On 5/31/21 12:33 PM, Zong, Wei wrote:
> > > Hello,
> > >
> > > I'm using GLES shader to run algorithms on image frames, I got very
> > > bad performance issue in GPU & CPU data sharing, especially retrieve
> > > data from GPU to CPU.
> > >
> > > Basically, I use
> > > */glGenBuffers/*/*/glBindBuffer/*/*/glBufferData(target, size, data,
> > > usage) /*to create GPU buffer object and initialize GPU data store
> > > with CPU data pointer. After GLES shader finished the processing, I
> > > use /*glMapBufferRange*///to retrieve processed image data back to
> > > CPU, and for some reason I have to do an extra data copy from the gl
> > > map pointer to another CPU buffer, this is super slow.
> > >
> > > Here's the code snippet
> > > https://github.com/intel/libxcam/blob/master/modules/gles/gl_buffer.cp
> > > p#L94
> > >  > > pp#L94>
> > >
> > > https://github.com/intel/libxcam/blob/master/modules/gles/gl_buffer.cp
> > > p#L127
> > >  > > pp#L127>
> > >
> > > I wonder If there has other efficient way to sharing data between CPU
> > > & GPU GLES shader?
> > >
> > > Thanks,
> > >
> > > Zong Wei
> > >
> >
> > Could you break down the use-case here a bit, why do you need CPU access to
> > the image? If I understand correctly, is it so that camera pipeline renders 
> > to a
> > dmabuf and then this is imported to GLES for processing and then you map it 
> > to
> > CPU for ... something?
> >
> > Thanks;
> >
> > // Tapani
>
> Hi Tapani,
> I got multiple input video frames from decoder, copied these frames to egl 
> buffers, used GLES shader to stitch these frames into one high resolution 
> frame (8K), then I mapped the stitched frame to CPU, encoded the frame into 
> h246 stream. I don't have GPU encoder to handle 8K frame.
>
> I noticed glMapBufferRange Api description from 
> https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glMapBufferRange.xhtml
> "Mappings to the data stores of buffer objects may have nonstandard 
> performance characteristics. For example, such mappings may be marked as 
> uncacheable regions of memory, and in such cases reading from them may be 
> very slow. To ensure optimal performance, the client should use the mapping 
> in a fashion consistent with the values of GL_BUFFER_USAGE for the buffer 
> object and of access. Using a mapping in a fashion inconsistent with these 
> values is liable to be multiple orders of magnitude slower than using normal 
> memory."
>
> Seems I should find a way to map the buffer as cacheable memory. How to map a 
> cacheable memory? And how to use DMA buffering?

If you're on x86, then you want to use MOVNTDQA (see Mesa's
`streaming-load-memcpy.c`) to move the WC contents you mapped from GL
to a malloc()ed temporary before handing it to your encoder that will
likely be doing random, small-word access to the buffer.  If you're on
ARM, then the best you can do is NEON loads from WC and store to your
cached temporary.

It will be slow, but this is the cost of accessing GPU memory (and a
reason to figure out if your platform has some accelerated encoding
capability and use that).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Workflow Proposal

[Emma Anholt]

On Sun, Oct 10, 2021 at 4:44 PM apinheiro  wrote:
>
> Answering here, as it is the second time it is mentioned that Rb is only
> for "who can help support this years from now?", but not specifically to
> this email.
>
> On 7/10/21 15:00, Alyssa Rosenzweig wrote:
> >> I would love to see this be the process across Mesa.  We already don't
> >> rewrite commit messages for freedreno and i915g, and I only have to do
> >> the rebase (busy-)work for my projects in other areas of the tree.
> > Likewise for Panfrost. At least, I don't do the rewriting. Some Panfrost
> > devs do, which I'm fine with. But it's not a requirement to merging.
> >
> > The arguments about "who can help support this years from now?" are moot
> > at our scale... the team is small enough that the name on the reviewer
> > is likely the code owner / maintainer, and patches regularly go in
> > unreviewed for lack of review bandwidth.
>
> There is another reason to the Rb tag, that is to measure the quantity
> of patch review people do.
>
> This was well summarized some years ago by Matt Turner, as it was
> minimized (even suggested to be removed) on a different thread:
>
> https://lists.freedesktop.org/archives/mesa-dev/2019-January/213586.html

I was part of the Intel team when people started doing this r-b
counting.  I believe that it was being done due to Intel management's
failure to understand who was doing the work on the team and credit
them appropriately, and also to encourage those doing less to step up.
Unfortunately, the problem with Intel management wasn't a lack of
available information, and I didn't see publishing the counts change
reviews either.

Re: [Mesa-dev] Workflow Proposal

[Emma Anholt]

On Wed, Oct 6, 2021 at 9:20 AM Mike Blumenkrantz
 wrote:
>
> 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 where 
> everyone* has to constantly be adding these esoteric tags like Reviewed-by (I 
> reviewed it), and Acked-by (I rubber stamped it), or Tested-by (I compiled it 
> and maybe ran glxgears), and so forth.
>
> * Except some incredibly smart people already know where I'm going with this
>
> Instead of continuing to have to manually update each patch with the 
> appropriate and definitely-unforgeable tags, what if we just used Approvals 
> in the UI instead? We could then have marge-bot require approvals as needed 
> in components and bring reviewing into the current year. Just think: no more 
> rewriting all the commit logs and force-pushing the branch again before you 
> merge!
>
> Anyway, I thought maybe this would be a nice idea to improve everyone's 
> workflows. What do other people think?

I would love to see this be the process across Mesa.  We already don't
rewrite commit messages for freedreno and i915g, and I only have to do
the rebase (busy-)work for my projects in other areas of the tree.

I don't think we should have marge-bot require approvals
per-component, though.  There are times when an MR only incidentally
touches a component (for example, changing function signatures in
gallium), and actually getting a dev from every driver to sign off on
it would be too much.

Re: [Mesa-dev] Workflow Proposal

[Emma Anholt]

On Wed, Oct 6, 2021 at 12:28 PM Jordan Justen  wrote:
>
> Mike Blumenkrantz  writes:
>
> > On Wed, Oct 6, 2021 at 1:27 PM Bas Nieuwenhuizen 
> > wrote:
> >
> >> On Wed, Oct 6, 2021 at 7:07 PM Jason Ekstrand 
> >> wrote:
> >> >
> >> > My primary grip with approvals or the  button is that it's the wrong
> >> > granularity.  It's per-MR instead of per-patch.  When people are
> >> > regularly posting MRs that touch a bunch of different stuff, per-patch
> >> > review is pretty common.  I'm not sure I want to lose that.  :-/
>
> Could a hybrid approach work? Marge could just add:
>
> Approved-by: @jljusten
>
> to the commit message based on the state of the MR. But, for MR's where
> r-b is more appropriate, the developer can still manually add
> Reviewed-by.
>
> Personally I don't find adding the r-b and force pushing to be much of a
> burden, but I could see how in some cases of a small MR, it could be
> nice to just click some buttons on the web-page and be done with it.
>
> But, I really would like Marge to add something to the commit messages
> indicating who approved it. Yeah, you can get that info today by
> following the Part-of link, but there's no guarantees about that being
> around forever.

Part of the deal with gitlab was that sysadmins would be keeping the
gitlab links working at least in a static form if we ever decided to
turn down gitlab.  Just like bugzilla still responds to queries even
after we decided to migrate away.

Re: [Mesa-dev] Workflow Proposal

[Emma Anholt]

On Wed, Oct 6, 2021 at 10:07 AM 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
> >  wrote:
> > >
> > > 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 where 
> > > everyone* has to constantly be adding these esoteric tags like 
> > > Reviewed-by (I reviewed it), and Acked-by (I rubber stamped it), or 
> > > Tested-by (I compiled it and maybe ran glxgears), and so forth.
> > >
> > > * Except some incredibly smart people already know where I'm going with 
> > > this
> > >
> > > Instead of continuing to have to manually update each patch with the 
> > > appropriate and definitely-unforgeable tags, what if we just used 
> > > Approvals in the UI instead? We could then have marge-bot require 
> > > approvals as needed in components and bring reviewing into the current 
> > > year. Just think: no more rewriting all the commit logs and force-pushing 
> > > the branch again before you merge!
> > >
> > > Anyway, I thought maybe this would be a nice idea to improve everyone's 
> > > workflows. What do other people think?
>
> My primary grip with approvals or the  button is that it's the wrong
> granularity.  It's per-MR instead of per-patch.  When people are
> regularly posting MRs that touch a bunch of different stuff, per-patch
> review is pretty common.  I'm not sure I want to lose that.  :-/

If we leave aside the "marge bot requires approvals" thing, which I
don't think is plausible, then we could have it both ways: easy MRs
get a thumbs up from someone reasonable and we hand it directly to
marge, or complicated MRs can have people doing per-patch review like
they do today, and someone at the end decides to hand to marge (with
or without per-patch rbs rebased in).

Re: [Mesa-dev] Workflow Proposal

[Emma Anholt]

"

On Thu, Oct 7, 2021 at 1:38 AM Eero Tamminen  wrote:
>
> Hi,
>
> On 6.10.2021 23.00, Jordan Justen wrote:
> > Bas Nieuwenhuizen  writes:
> >> On Wed, Oct 6, 2021 at 8:49 PM Jordan Justen  
> >> wrote:
> >>> I guess I missed where it was suggested that Marge should remove
> >>> Reviewed-by tags. I don't think Marge should ever remove something from
> >>> the commit message.
> >>
> >> AFAIU this is upstream Marge behavior. Once you enable the
> >> Approval->Rb tag conversion it removes existing Rb tags. Hence why we
> >> don't have the conversion enabled.
> >>
> >
> > Ah, I guess it is documented for --add-reviewers here:
> >
> > https://github.com/smarkets/marge-bot#adding-reviewed-by-tested-and-part-of-to-commit-messages
> >
> > "All existing Reviewed-by: trailers on commits in the branch will be
> >   stripped."
>
> This sounds horrible from the point of view of trying to track down
> somebody who knows about what's & why's of some old commit that is later
> on found to cause issues...
>
> For whom those extra Rb tags are a problem and why?

To explain Marge's behavior here: I think their concern is if it was
assigned to Marge with one set of reviewers, then failed to merge,
then assigned to Marge again with another set of reviewers flagged in
the MR, then they want to update the set of reviewers associated with
the merge without leaving in someone who had retracted their review.

For Mesa where people provide per-patch review, that's silly.  We
could fork and strip out that behavior, but in the original proposal
this flag wasn't getting enabled anyway so Marge's behavior is moot.

And, again, if you want to "track down somebody who knows about what's
& why's of some old commit", just click the link that's right there in
the commit, which gives you not just the names but also the comments
they had about the commit back when they reviewed it!

Re: Moving code around, post classic

[Emma Anholt]

On Mon, Dec 6, 2021 at 3:50 PM Dylan Baker  wrote:
>
> Classic is gone, and the cleanups have begun, obviously. There is
> another cleanup that I had in mind, which is moving src/mesa into
> src/gallium/frontends/mesa. This makes the build system a little
> cleaner, as currently we do some bending over backwards to get gallium,
> mesa, and their tests built in the right order. But that's a big ol `git
> mv`, and when I proposed it Dave and Ilia suggested it would be best to
> do all of the post-classic code motion at once. So, let's talk about
> what we want to move, and where we want to move it.
>
> Among the suggestions we had were:
>
> 1. Move src/mesa into src/gallium/frontends/mesa (I have patches for
>this)
>
>Seems like a pretty obvoius thing to do, given that all of the other
>gallium state trackers live there (OpenCL, video, d3d9, etc)
>
> 2. Move src/compiler/glsl into src/gallium/frontends/mesa as well
>
> Given that there are now no? drivers that use GLSL-IR directly, it
> might make sense to move the glsl compiler into the mesa
> state_tracker, and just have that lower to TGSI or NIR, and treat
> GLSL-IR as an implementation detail of the OpenGL frontend.
>
> Unfortunately, there are a lot of code outside of glsl that uses the
> linked list implementation in the glsl compiler, and not the on in
> util.
>
> 3. Move src/gallium* to src/
>
> This was suggested, though given the existance of Vulkan, it wasn't
> clear that this was a good idea or not
>
> 4. What to do about the src/loader, src/glx, src/egl, src/mapi,
>src/glapi
>
> These are all part of OpenGL, but not really part of gallium, but if
> we don't move src/gallium/* to src/ does it make sense to leave them
> in the root?

FWIW, I'm mildly against moving src/mesa to src/gallium/frontends/mesa
(or /gl would make more sense to me at that point).  That feels like a
whole lot of gratuitous typing of longer paths to me, when GL feels
like a pretty fundamental thing in the repo and not worth hiding way
down there.

[Mesa-dev] deqp-runner "suite" support

[Emma Anholt]

One of the irritating parts of deqp testing in our CI is that
deqp-runner has only been able to invoke one deqp binary per
deqp-runner invocation, which meant that we have to split out each of
deqp-gles*, deqp-egl, and glcts into different CI jobs, producing a
whole lot of output for devs to review when things go wrong (or for me
to review when trying to find slow testcases to optimize).  It also
wastes hardware time bringing up the test environment for each CI job,
and makes job tuning to meet our ~10-minute runtime goal a lot of
fuss.

So, I'm adding support to deqp-runner to describe a test suite in a
toml file and have it run all the deqp-*s in parallel.  I'm already
enjoying it for doing full, quick softpipe CTS runs locally.  I'm
hoping to merge it next week when I get back from camping, so I
thought I'd put the MR up here for feedback on the interface:

deqp-runner code:
https://gitlab.freedesktop.org/anholt/deqp-runner/-/merge_requests/14

Mesa commit showing its use:
https://gitlab.freedesktop.org/anholt/mesa/-/commit/8c70ab9a9e285882ec9740f1a1f058b3135c5ee9

Test Mesa pipeline:
https://gitlab.freedesktop.org/anholt/mesa/-/pipelines/365283

Should any of the toml keys be renamed?  Should anything else be in
command line args? Do we need toml top-level settings for "apply this
to all the [[deqp]]s"?  Should I bite the bullet and let you do both
deqp and piglit in the same suite config (new runner binary?)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: git and Marge troubles this week

[Emma Anholt]

On Fri, Jan 7, 2022 at 6:18 AM Connor Abbott  wrote:
>
> Unfortunately batch mode has only made it *worse* - I'm sure it's not
> intentional, but it seems that it's still running the CI pipelines
> individually after the batch pipeline passes and not merging them
> right away, which completely defeats the point. See, for example,
> !14213 which has gone through 8 cycles being batched with earlier MRs,
> 5 of those passing only to have an earlier job in the batch spuriously
> fail when actually merging and Marge seemingly giving up on merging it
> (???). As I type it was "lucky" enough to be the first job in a batch
> which passed and is currently running its pipeline and is blocked on
> iris-whl-traces-performance (I have !14453 to disable that broken job,
> but who knows with the Marge chaos when it's going to get merged...).
>
> Stepping back, I think it was a bad idea to push a "I think this might
> help" type change like this without first carefully monitoring things
> afterwards. An hour or so of babysitting Marge would've caught that
> this wasn't working, and would've prevented many hours of backlog and
> perception of general CI instability.

I spent the day watching marge, like I do every day.  Looking at the
logs, we got 0 MRs in during my work hours PST, out of about 14 or so
marge assignments that day.  Leaving marge broken for the night would
have been indistinguishable from the status quo, was my assessment.

There was definitely some extra spam about trying batches, more than
there were actual batches attempted.  My guess would be gitlab
connection reliability stuff, but I'm not sure.

Of the 5 batches marge attempted before the change was reverted, three
fell to https://gitlab.freedesktop.org/mesa/mesa/-/issues/5837, one to
the git fetch fails, and one to a new timeout I don't think I've seen
before: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/17357425#L1731.
Of all the sub-MRs involved in those batches, I think two of those
might have gotten through by dodging the LAVA lab fail.  Marge's batch
backoff did work, and !14436 and maybe !14433 landed during that time.

Re: PowerVR Vulkan driver

[Emma Anholt]

Welcome!  I'm really excited to see this happening, and your early
upstreaming work.

On Fri, Mar 4, 2022 at 7:44 AM  wrote:
>
> Hi All,
>
> I'm excited to share that over the last year we've been working on a new
> Vulkan driver, compiler and Linux kernel DRM driver for our PowerVR
> GPUs. As it was important for us to do things "right", we got Collabora
> involved early on in the project. They've been a big help and have
> guided us with the approach and overall design of the driver.
>
> I've sent an initial merge request for the Mesa parts of the driver
> here:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15243
>
> The corresponding MRs for the kernel driver and firmware haven't been
> sent yet, as the kernel driver still has a few things that need
> finalising. We're currently exploring the best approach for getting it
> merged upstream while temporarily maintaining enough flexibility to make
> changes to the uAPI (any guidance here is very welcome). In the meantime
> you can find the kernel code here:
>
> https://gitlab.freedesktop.org/frankbinns/powervr/-/tree/powervr-next
>
> and the firmware here:
>
> https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr

I took a look through the UAPI.  The only real red flag to me was the
UAPI structs talking about firmware versions.  Have you thought about
how you're going to ship updates to the kernel and firmware, but still
run with old userspace?  This is not something you have to deal with
in most software stacks, but for desktop Linux, we have the
expectation that you can uprev the kernel (and probably also
linux-firmware) and break existing userspace.  Usually, we try to
design UAPI so we can map userspace's request onto whatever the
HW/firmware's layout might be in the future, and you only require
updated userspace when supporting new hardware.

If you actually expect new firmware API to change in a way you can't
just remap (e.g. some of those iovas point to structs in GPU memory
set up by userspace and interpreted by the firmware), I guess you
could delay poweron and firmware load until userspace comes in and
tells you what API it needs and then you can load the corresponding
firmware version, so you can at least dynamically choose a firmware
per boot at least.

This can all be solved, just something that looks like maybe is going
to take a bit of thought.

> In addition to highlighting the MR, I also wanted to take the
> opportunity to provide a bit more information and to introduce myself
> and the rest of the team.
>
> As mentioned in the MR, the driver will initially support three GPUs
> based on our Rogue architecture. The first of these (GX6250) is one of
> our earlier Rogue based GPUs, whereas the other two (AXE-1-16M and
> BXS-4-64) are some of our most recently available GPUs.
>
> For initial development we've been using an Acer Chromebook R13 as a
> target device (this contains a Mediatek MT8173 SoC/GX6250 GPU). We also
> hope to gain support for the TI AM62 SoC (AXE-1-16M GPU), which is in
> the process of having support upstreamed [1].
>
> To help speed up development, we've been making use of the existing open
> source, but not upstream, kernel mode driver (pvrsrvkm) from our DDK. A
> kernel with the pvrsrvkm sources in-tree can be found here:
>
> https://gitlab.freedesktop.org/frankbinns/powervr/-/tree/ddk/1.14@6193520
>
> The Vulkan driver has a thin abstraction layer (inspired by radv) to
> allow it to make use of the pvrsrvkm driver and the new powervr kernel
> driver (support for the former being hidden behind a build config
> option).

We have something similar on the Qualcomm side (not really even
abstraction, though!), where we can run on either upstream DRM or
downstream KGSL.  Definitely the right way to go, because it means you
get to swap the components out to try to isolate whether it's your
userspace driver or something in the software stack underneath you
(DRM getting PTEs right?  devfreq?  that one weird interconnect driver
you forgot about because it's so ugly nobody's wanted to look at
upstreaming it?) that's causing whatever slowdown you're
investigating.

> Unlike other driver efforts, we chose to start with a Vulkan driver as
> we thought that this would be a more interesting proposition than a
> native OpenGL ES driver. Obviously there's a lot of OpenGL ES content
> out there, but in recent years there's been a lot of effort put into GL
> to Vulkan translation layers. We therefore felt that a Vulkan driver
> together with Zink/ANGLE would be a good way to support multiple APIs
> from the get go.

Absolutely agree here.  You've got to make Vulkan good anyway, so
focus your efforts.

> I know a lot of effort has been put into Mesa CI over the last few
> years, so we'll be looking to add support for our driver once it's
> upstream. The aim is to start looking at what's required in the next
> week or two in preparation for this (again, any guidance here is very
> welcome).

The good news 

git and Marge troubles this week

[Emma Anholt]

As you've probably noticed, there have been issues with git access
this week.  The fd.o sysadmins are desperately trying to stay on
vacation because they do deserve a break, but have still been working
on the problem and a couple of solutions haven't worked out yet.
Hopefully we'll have some news soon.

Due to these ongoing git timeouts, our CI runners have been getting
bogged down with stalled jobs and causing a lot of spurious failures
where the pipeline doesn't get all its jobs assigned to runners before
Marge gives up.  Today, I asked daniels to bump Marge's pipeline
timeout to 4 hours (up from 1).  To get MRs flowing at a similar rate
despite the longer total pipeline times, we also enabled batch mode as
described at 
https://github.com/smarkets/marge-bot/blob/master/README.md#batching-merge-requests.

It means there are now theoretical cases as described in the README
where Marge might merge a set of code that leaves main broken.
However, those cases are pretty obscure, and I expect that failure
rate to be much lower than the existing "you can merge flaky code"
failure rate and worth the risk.

Hopefully this gets us all productive again.

GLSL-to-TGSI going away

[Emma Anholt]

I just posted a status update to the MR with the summary of remaining work:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8044#note_1346175

I started this project back in December 2020, and have been pushing all the
TGSI drivers along since then.  We're down to very few test regressions in
the remaining drivers, and landing it nets us test fixes and performance
wins while removing 22,000 lines of unmaintained, non-CI-tested code.

This email is your warning that, once those linked MRs land, I plan on
landing !8044 and saying goodbye to the GLSL-to-TGSI path.

Re: [Intel-gfx] No Mesa DRI Intel 945G in Debian Bookworm since Feb. 2022 package change

[Emma Anholt]

Debian packaging apparently just decided not to include i915g in the
transition?  Not our fault.

On Mon, Dec 5, 2022 at 9:59 AM Rodrigo Vivi  wrote:

> Cc: mesa-dev ml
>
> On Sat, Dec 03, 2022 at 03:00:44AM -0500, Felix Miata wrote:
> > From libgl1-mesa-dri:amd64 changelog:
> > mesa (22.0.0~rc2-1) experimental; urgency=medium
> >
> >   * New upstream release candidate.
> >   * path_max.diff: Refreshed.
> >   * rules: Drop classic drivers (r100, r200, nouveau_vieux, i915, i965).
> >
> >  -- Timo Aaltonen   Thu, 17 Feb 2022
> 22:04:03 +0200
> >
> > # xdriinfo
> > libGL error: MESA-LOADER: failed to open i915: /usr/lib/dri/i915_dri.so:
> cannot open shared object file: No such file or directory (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
> > libGL error: failed to load driver: i915
> > Screen 0: swrast
> >
> > # pinxi -GSaz --vs --zl --hostname
> > pinxi 3.3.23-05 (2022-11-07)
> > System:
> >   Host: gx62b Kernel: 5.19.0-2-amd64 arch: x86_64 bits: 64 compiler: gcc
> > v: 11.3.0 parameters: root=LABEL= ipv6.disable=1
> net.ifnames=0
> > biosdevname=0 plymouth.enable=0 noresume mitigations=auto
> consoleblank=0
> >   Desktop: Trinity v: R14.0.13 tk: Qt v: 3.5.0 info: kicker wm: Twin v:
> 3.0
> > vt: 7 dm: 1: TDM 2: XDM Distro: Debian GNU/Linux bookworm/sid
> > Graphics:
> >   Device-1: Intel 82945G/GZ Integrated Graphics vendor: Dell driver: i915
> > v: kernel arch: Gen-3.5 process: Intel 90nm built: 2005-06 ports:
> > active: DVI-D-1,VGA-1 empty: none bus-ID: 00:02.0 chip-ID: 8086:2772
> > class-ID: 0300
> >   Display: x11 server: X.Org v: 1.21.1.4 driver: X: loaded: modesetting
> > dri: swrast gpu: i915 display-ID: :0 screens: 1
> >   Screen-1: 0 s-res: 3600x1200 s-dpi: 120 s-size: 762x254mm
> (30.00x10.00")
> > s-diag: 803mm (31.62")
> >   Monitor-1: DVI-D-1 pos: primary,left model: NEC EA243WM serial:
> 
> > built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
> > size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10
> modes:
> > max: 1920x1200 min: 640x480
> >   Monitor-2: VGA-1 pos: right model: Dell P2213 serial:  built:
> 2012
> > res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2 size: 473x296mm
> (18.62x11.65")
> > diag: 558mm (22") ratio: 16:10 modes: max: 1680x1050 min: 720x400
> >   API: OpenGL v: 4.5 Mesa 22.2.4 renderer: llvmpipe (LLVM 15.0.5 128
> bits)
> > direct render: Yes
> >
> > In Bullseye:
> > ...
> >   API: OpenGL v: 1.4 Mesa 20.3.5 renderer: Mesa DRI Intel 945G
> > direct render: Yes
> > # xdriinfo
> > Screen 0: i915
> >
> > What are Bookworm users supposed to do to make Mesa DRI work correctly
> > now that i915_dri.so is missing? Did it get moved to some other .deb
> > I can't ID? I don't think Crocus is supposed to work on Gen3. At least,
> > export MESA_LOADER_DRIVER_OVERRIDE=crocus in
> /etc/X11/Xsession.d/10-crocus.sh
> > doesn't help.
> >
> > In openSUSE Tumbleweed in 22.2.4 i915 is still included in its Mesa-dri
> > package, and Mesa DRI Intel 945G is working as expected.
> > --
> > Evolution as taught in public schools is, like religion,
> >   based on faith, not based on science.
> >
> >  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
> >
> > Felix Miata
>

Dropping libGL/EGL vs DRI driver cross compatibility

[Emma Anholt]

Now that Amber exists and glvnd seems to be the route we plan on for
"supporting" old DRI drivers, I'm working toward garbage collecting a lot
of extra layering that we have to support out of tree DRI drivers.  I feel
that the loader interface gets in the way of implementing new EGL
functionality, and obscures how the window system interacts with the
gallium drivers.  If we ensure that we only load a Mesa driver from our
tree, then the window system can just interact with the dri_screen and
pipe_screen directly.

MR is up at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20069

Anyone see any blocking issues for this?