Re: [Mesa-dev] Rename "master" branch to "main"?

[Eric Anholt]

On Tue, Mar 23, 2021 at 7:02 AM Jason Ekstrand  wrote:
>
> Trying to pick this discussion back up.  Daniel Stone thinks it's a
> half hour of API bashing to retarget all the MRs so, if the fd.o
> admins have some heads up, it should be tractable.  Should we do this
> right after branching 21.1 along with the LTS branch?

+1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Eric Anholt]

On Mon, Mar 22, 2021 at 3:27 PM Dylan Baker  wrote:
>
> 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

I would like it if Intel could avoid garbage-collecting older-HW
shared code for at least a release due aforementioned WIPs, but I
think it's time to call the classic i965_dri.so and i915_dri.so done.

+1 from me assuming that we validate that one can actually get a
working X server with the mesa-legacy set installed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] docs: consistent language

[Eric Anholt]

+1 to all of this.

On Mon, Mar 15, 2021 at 1:54 PM Jason Ekstrand  wrote:
>
> Three comments:
>
>  1. +1
>  2. Khronos has generally standardized on American English in their
> specs so I guess that provides some sort of prior art or something.
>  3. I'd generally be a fan of encouraging American spellings in common
> code as well.  As someone who doesn't use auto-complete, having to
> remember which variable is named "color" and which is "colour" would
> get painful.  Fortunately, we don't have a whole lot of variation here
> but it'd be good to keep consistency.
>
> --Jason
>
> On Mon, Mar 15, 2021 at 12:59 PM Ian Romanick  wrote:
> >
> > On 3/15/21 5:44 AM, Erik Faye-Lund wrote:
> > > TLDR; I'm proposing to standardize on US English in our public-facing
> > > documentation.
> > >
> > > I proposed an MR a while back that changed the only occurrence of the
> > > UK English spelling "optimisation" for the US English spelling
> > > "optimization", which is already used 34 times in the docs. I've done
> > > similar changes in the past.
> > >
> > > But this time Ian brought up the good point that picking a preferred
> > > language should probably be done using group consensus on the mailing
> > > list than just picking what's currently most popular.
> >
> > Over the years we've had quite a few contributions from folks in many
> > different English spelling parts of the world where the UK spelling is
> > the norm... though I don't think there have been that many from the UK
> > itself. :)  I suggested getting some group consensus because I didn't
> > want any of those people to feel left out or undervalued.
> >
> > If anyone doesn't feel comfortable speaking out publicly about this,
> > please feel free to contact Erik or me privately.
> >
> > > So, I hereby propose to pick US English as our default language for
> > > user-facing documentation.
> > >
> > > I'm not proposing to force anyone to use a particular English variant
> > > for things like comments, commit messages or variable names. I don't
> > > think there's much value in enforcing that, and I think it'd be
> > > perfectly fine if any particular driver wanted to pick a particular
> > > variant of English.
> > >
> > > The main reason I want to standardize on an English variant is that I'm
> > > trying create a word-list for domain-specific/technical language to
> > > detect spelling mistakes in the docs more easily. And not having to add
> > > both US and UK English words makes this list easier to maintain. I'm
> > > not planning on going 100% systematically though the dictionary to
> > > detect UK English words that might be in my system dictionary, just to
> > > fix the words that currently cause me (a tiny amount of) pain ;)
> > >
> > > The main reason why I'm proposing US English over for instance UK
> > > English is that this seems to be the dominant variant currently in the
> > > documentation. So it seems like the pragmatic choice to me.
> > >
> > > Thoughts? Any objections to sticking to US English in the docs?
> > >
> > > The MR in question:
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8572
> > >
> > > Ian's response:
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8572#note_808593
> > >
> > > Previous changes:
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6864
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6894
> > >
> > >
> > > ___
> > > 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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] deqp-runner now has a piglit-runner

[Eric Anholt]

I wanted to link everyone to the new piglit runner that @pepp wrote
based on the deqp-runner codebase.  You can find build instructions
and example command lines at https://crates.io/crates/deqp-runner

I'm planning on using it in freedreno CI.  Some notable features it
has for freedreno compared to the python runner:

- cuts piglit runtime by something like 1/3 (when in process isolation mode).
- automatically detects flakes, supports known-flakes files
- nice clean status reports at the end of the run
- built-in support for sharding across boards or doing fractional runs
- Incremental status reports so you know if the runner is still
producing results

Notable features it doesn't have:

- piglit subtest reporting
- individual shader_runner subtest parsing in no_isolation mode
- fast skipping based on extension requirements in the XML
- piglit python-style results output you can feed into the framework's
html generation

I would love to hear from anyone else who wants to try it out and see
how it works for you.  repo at
https://gitlab.freedesktop.org/anholt/deqp-runner for any issues you
want to file.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] deqp-runner 0.5.0 released

[Eric Anholt]

Just wanted to give a heads up that I've pushed a new release of the
deqp runner with fixes for test runtime based on today's investigation
into the cost of including skipped tests in the list of tests to run.
I've retuned the maximum test group size and disabled (by default)
some test group size smarts that were costing us runtime.

The overall effect on one of my cheza deqp-vk runs locally is a
runtime reduction from 8:34 to 4:39.

If you're using piglit's deqp or parallel-deqp-runner, please check it
out.  Your test runtimes (and error logging, and summaries, and flake
handling, and regressoin tracking, and etc.) should all be improved.
Installation instructions at:

https://gitlab.freedesktop.org/anholt/deqp-runner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] A little note on git_sha1.h build status

[Eric Anholt]

If you're like me, you may have noticed that when you're hacking on
something and rebuilding repeatedly, the ninja build spends a whole
lot of time on:

[1/90] Generating git_sha1.h with a custom command

I found https://github.com/nico/ninjatracing today and applied it, and
it looks like there's nothing we're doing wrong -- git_sha1.h is
completing quickly, but not until a slow command (building that file
you're hacking on) is started, and then the status doesn't update
until the next command completes.

Now I just need a meta-ninja that can process my 8 different build
directories in parallel.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Can't get self-built Mesa to work on the Raspberry Pi 4

[Eric Anholt]

You need to enable kmsro.

On Wed, Jan 6, 2021 at 3:31 AM  wrote:
>
> Hi all,
>
> In order to check whether a OpenGL ES driver bug I'm hitting on the
> Raspberry Pi 4 still appears in the latest Mesa version, I'm trying to
> build Mesa myself and run my application with that. Unfortunately I'm
> having no success with either 19.3.2 (the version distributed with
> raspbian), 20.3.2 (the latest release) or the current master. Each time
> the driver initialization fails with the following messages printed to
> the console:
>
> libGL error: failed to create dri screen
> libGL error: failed to load driver: vc4
>
> This is my meson setup command line:
>
> ~/Downloads/meson-0.56.0/meson.py setup -Ddri-drivers=
> -Dgallium-drivers=v3d,vc4 -Dvulkan-drivers= -Dplatforms=x11
> -Dbuildtype=debug -Dbackend=ninja -Dprefix=/home/pi/mesa-build build
>
> (vc4 seems to be required in the gallium-drivers option, otherwise it
> failed with 'libGL error: MESA-LOADER: failed to open vc4 [...]'. I
> guess this makes sense given the dependency on vc4 as explained here
> https://docs.mesa3d.org/drivers/v3d.html ?)
>
> I'm having this issue using both SDL or freeglut and either starting the
> app from ssh (using 'export DISPLAY=:0') or directly on the desktop.
>
> I'm a total beginner when it comes to Mesa and the pi graphics driver
> stack, so any help would be highly appreciated :) Thanks!
>
> Lukas
> ___
> 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] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Eric Anholt]

Classic swrast didn't have MSAA either, so it sounds like softpipe
meets your requirements as stated.

I suspect actually by MSAA you meant GL_POLYGON_SMOOTH_HINT, the weird
old sometimes-it-gets-you-coverage-in-alpha-output knob.  Since you're
software rasterizing, I'd recommend that you instead render at a
higher res and downscale-- I suspect this with llvmpipe would be
faster overall, and you'd get better quality even with aniso disabled.
I feel like removing swrast support for GL_POLYGON_SMOOTH_HINT is
fairly legitimate -- intel doesn't support it either, and it is just
supposed to be a hint for the pre-msaa world.

We ought to sort out aniso for llvmpipe anyway, though I don't know
much about implementing it, and the fact that conformance doesn't
detect lack of any aniso is a big disappointment.  I heard ajax was
poking at resurrecting msaa for softpipe, which would clear out a lot
of our conformance fails there, and might avoid the need for user code
changes if 4x MSAA is enough.

On Mon, Jan 4, 2021 at 12:01 PM Brian Paul  wrote:
>
> Hi Andreas,
>
> I'm forwarding your message to the mesa-dev list for better visibility.
>
> BTW, when you say "antialiasing" below, what exactly do you mean?
>
> -Brian
>
>
>  Forwarded Message 
> Subject:[Mesa-users] Issues with removal of classic OSMesa
> Date:   Thu, 31 Dec 2020 12:56:04 +0100
> From:   Andreas Fänger 
> To: mesa-us...@lists.freedesktop.org
>
> Hi,
>
> I've just seen that classic OSMesa has been removed (again) from Mesa3D
> a few weeks ago with this commit "mesa: Retire classic OSMesa".
>
> We are still actively using classical OSMesa for high quality rendering
> of still images in a headless environment with no GPU support
> (server-based rendering on windows and linux)
>
> Unfortunately, none of the alternative software renderers provide all
> the features that we require, which is antialiasing and anisotropic
> filtering. The current state is (correct me if I'm wrong)
>
> * softpipe: anisotropic filtering is supported, no antialiasing
>
> * llvmpipe: no anisotropic filtering, has MSAA
>
> * openswr: no anisotropic filtering, has MSAA, no OSMesa interface (?)
>
> We had hoped that classical OSMesa is only removed when there is a full
> replacement after the discussions in 2016 when OSMesa was about to be
> removed for the first time
>
> https://lists.freedesktop.org/archives/mesa-dev/2016-March/109665.html
>
> https://lists.freedesktop.org/archives/mesa-users/2016-March/001132.html
>
> and the commit that reverted the removal
>
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=9601815b4be886f4d92bf74916de98f3bdb7275c
>
> Are there any plans to enhance the renderers so that at least one of
> them is providing both anisotropic filtering and antialiasing?
>
> As far as I know, anisotropic texture filtering is also one of the
> OpenGL 4.6 requirements.
>
> In 2016 I was told that there are only very few developers involved in
> llvmpipe and that chances are not high that someone is going to port the
> softpipe anisotropic filtering implementation as llvmpipe is much more
> complex. Is there any change in that situation?
>
> If there are no such plans, is there any chance of reverting this commit
> again so that classical OSMesa is available for windows and linux in
> mesa >20?
>
> Regards,
>
> Andreas Fänger
>
> ___
> 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] Can I please get +o in #dri-devel to quiet verbal abuse?

[Eric Anholt]

I've added you to chanserv permissions (I think), feel free to use it
for that spammer.  Thanks!

On Sun, Dec 27, 2020 at 9:01 PM Ryan Houdek  wrote:
>
> Can someone with permissions give me +o in #dri-devel through chanserv?
> IRC alias is HdkR, Nickserv alias is Sonicadvance1.
>
> Nobody should be required to put up with the verbal abuse constantly when the 
> spammer comes in.
> I'm around at almost all times and will be able to quiet them whenever it 
> happens.
> I've already PM'd ajax but I figured I would mail the list as well.
> ___
> 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] Cross-compile from Linux to Windows

[Eric Anholt]

On Mon, Nov 9, 2020 at 2:19 AM Federico Dossena  wrote:
>
> I'm sorry to bother you in the dev list but it seems to be the only one
> with activity so it seems like the best place to ask.
>
> I maintain some Mesa builds for Windows. These are builds of libgl-gdi
> with llvmpipe, for both x86 and x86_64; in other words, they're
> opengl32.dll files that users can drop into their game/application to
> have software rendering for OpenGL as a workaround for broken drivers or
> as a fallback for older systems.
> I've always used scons on Windows and msvc as a compiler to make these
> builds, but now that scons is being deprecated I've been trying to use
> meson and ninja to cross-compile from Linux (amd64) to Windows (both x86
> and x86_64) without much success. I can get regular Linux builds without
> issues though.
>
> I tried reading the Mesa documentation on cross-compiling but it's very
> minimal and it's partially obsolete so I thought it would be best to ask
> you directly: how do I make these builds? Explain like I'm 5, basically.

I would recommend looking at the windows builds we have in CI as your guide.

https://gitlab.freedesktop.org/mesa/mesa/tree/master/.gitlab-ci/windows
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Rust drivers in Mesa

[Eric Anholt]

On Wed, Oct 14, 2020 at 3:26 PM Alyssa Rosenzweig
 wrote:
>
> > Since the majority opinion seemed to be "if someone wanted to use it
> > in a leaf node without making everyone use it, that's fine", I've
> > started trying to put together the CI bits necessary to enable it.
> > Currently fighting with meson cross files a bit, but the linting works
> > and the amd64 build works.
> >
> > https://gitlab.freedesktop.org/anholt/mesa/-/commits/ci-rust
>
> Good luck :)
>
> I didn't think to enforce a lint during CI. Part of me wonders if we
> should be doing that for C too, but we can shave that yak sometime else.

I don't think style-linting C is reasonable, but doing pep8 linting
would be nice.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] piglit merge access

[Eric Anholt]

On Tue, Oct 13, 2020 at 1:13 AM andrey simiklit
 wrote:
>
> Hi,
>
> I would like to request merge access for piglit gitlab. I have contributed a 
> number of commits for mesa/piglit. It would help in my work because sometimes 
> even already reviewed MRs remain not pushed for months.

I've added you now.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Rust drivers in Mesa

[Eric Anholt]

On Tue, Oct 13, 2020 at 12:08 AM Thomas Zimmermann  wrote:
>
> Hi
>
> On Fri, 02 Oct 2020 08:04:43 -0700 "Dylan Baker"  wrote:
>
> > I have serious concerns about cargo and crate usage. Cargo is basically npm 
> > for rust, and shares all of the bad design decisions of npm, including 
> > linking multiple versions of the same library together and ballooning 
> > dependency lists that are fetched intrigued from the internet. This is both 
> > a security problem and directly in conflict with meson's design off one and 
> > only one version of a project. And while rust prevents certain kinds of 
> > bugs, it doesn't prevent design bugs or malicious code. Add a meson 
> > developer the rust community has been incredibly hard to work with and 
> > basically hostile to every request we've made "cargo is hour you build 
> > rust", is essentially the answer we've gotten from them at every turn. And 
> > if you're not going to use cargo, is rust really a win? The standard 
> > library is rather minimal "because just pull in 1000 crates". The distro 
> > people can correct me if I'm wrong, but when librsvg went to rust it was a 
> > nightmare, several distros went a long time without
  u
>  pdates because of cargo.
>
> I can't say much about meson, but using Rust has broken the binaries of
> several packages on i586 for us; which consequently affects Gnome and KDE.
> [1][2] Rust uses SSE2 instructions on platforms that don't have them. There's
> a proposed workaround, but it's not yet clear if that's feasible in practice.
>
> Best regards
> Thomas
>
> [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1162283
> [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1077870

>From the first bug:

>Not entirely sure what to do about this. i586 is unsupported by Rust (tier 2) 
>and as such the package is built for i686

This really sounds like your distro is just building with the wrong
rust target for packages targeting an earlier processor.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Rust drivers in Mesa

[Eric Anholt]

On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig
 wrote:
>
> Hi all,
>
> Recently I've been thinking about the potential for the Rust programming
> language in Mesa. Rust bills itself a safe system programming language
> with comparable performance to C [0], which is a naturally fit for
> graphics driver development.
>
> Mesa today is written primarily in C, a notoriously low-level language,
> with some components in C++. To handle the impedance mismatch, we've
> built up a number of abstractions in-tree, including multiple ad hoc
> code generators (GenXML, NIR algebraic passes, Bifrost disassembler). A
> higher level language can help avoid the web of metaprogramming and
> effect code that is simpler and easier to reason about. Similarly, a
> better type system can aid static analysis.
>
> Beyond abstraction, Rust's differentiating feature is the borrow checker
> to guarantee memory safety. Historically, safety has not been a primary
> concern of graphics drivers, since drivers are implemented as regular
> userspace code running in the process of the application calling them.
> Unfortunately, now that OpenGL is being exposed to untrusted code via
> WebGL, the driver does become an attack vector.
>
> For the time being, Mesa attempts to minimize memory bugs with defensive
> programming, safe in-tree abstractions (including ralloc), and static
> analysis via Coverity. Nevertheless, these are all heuristic solutions.
> Static analysis is imperfect and in our case, proprietary software.
> Ideally, the bugs we've been fixing via Coverity could be caught at
> compile-time with a free and open source toolchain.
>
> As Rust would allow exactly this, I see the primary benefit of Rust in
> verifying correctness and robustness, rather than security concerns per
> se.  Indeed, safety guarantees do translate well beyond WebGL.
>
> Practically, how would Rust fit in with our existing C codebase?
> Obviously I'm not suggesting a rewrite of Mesa's more than 15 million
> lines of C. Instead, I see value in introducing Rust in targeted parts
> of the tree. In particular, I envision backend compilers written in part
> in Rust. While creating an idiomatic Rust wrapper for NIR or Gallium
> would be prohibitively costly for now, a backend compiler could be
> written in Rust with IR builders exported for use of the NIR -> backend
> IR translator written in C.
>
> This would have minimal impact on the tree. Users that are not building
> such a driver would be unaffected. For those who _are_ building Rust
> code, the Rust compiler would be added as a build-time dependency and
> the (statically linked) Rust standard library would be added as a
> runtime dependency. There is concern about the Rust compiler requiring
> LLVM as a dependency, but again this is build-time, and no worse than
> Mesa already requiring LLVM as a runtime dependency for llvmpipe and
> clover. As for the standard library, it is possible to eliminate the
> dependency as embedded Rust does, perhaps calling out to the C standard
> library via the FFI, but this is likely quixotic. I do regret the binary
> size increase, however.
>
> Implications for the build system vary. Rust prefers to be built by its
> own package manager, Cargo, which is tricky to integrate with other
> build systems. Actually, Meson has native support for Rust, invoking the
> compiler directly and skipping Cargo, as if it were C code. This support
> is not widely adopted as it prevents linking with external libraries
> ("crates", in Rust parlance), with discussions between Rust and Meson
> developers ending in a stand-still [1]. For Mesa, this might be just
> fine. Our out-of-tree run-time dependencies are minimal for the C code,
> and Rust's standard library largely avoids the need for us to maintain a
> Rust version of util/ in-tree. If this proves impractical in the
> long-term, it is possible to integrate Cargo with Meson on our end [2].
>
> One outstanding concern is build-time, which has been a notorious
> growing pain for Rust due to both language design and LLVM itself [3],
> although there is active work to improve both fronts [4][5]. I build
> Mesa on my Arm laptop, so I suppose I'd be hurt more than many of us.
> There's also awkward bootstrapping questions, but there is work here too
> [6].
>
> If this is of interest, please discuss. It's clear to me Rust is not
> going away any time soon, and I see value in Mesa embracing the new
> technology. I'd like to hear other Mesa developers' thoughts.

Since the majority opinion seemed to be "if someone wanted to use it
in a leaf node without making everyone use it, that's fine", I've
started trying to put together the CI bits necessary to enable it.
Currently fighting with meson cross files a bit, but the linting works
and the amd64 build works.

https://gitlab.freedesktop.org/anholt/mesa/-/commits/ci-rust
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] Rust drivers in Mesa

[Eric Anholt]

On Fri, Oct 2, 2020 at 8:05 AM Dylan Baker  wrote:
>
> I have serious concerns about cargo and crate usage. Cargo is basically npm 
> for rust, and shares all of the bad design decisions of npm, including 
> linking multiple versions of the same library together and ballooning 
> dependency lists that are fetched intrigued from the internet. This is both a 
> security problem and directly in conflict with meson's design off one and 
> only one version of a project. And while rust prevents certain kinds of bugs, 
> it doesn't prevent design bugs or malicious code. Add a meson developer the 
> rust community has been incredibly hard to work with and basically hostile to 
> every request we've made "cargo is hour you build rust", is essentially the 
> answer we've gotten from them at every turn. And if you're not going to use 
> cargo, is rust really a win? The standard library is rather minimal "because 
> just pull in 1000 crates". The distro people can correct me if I'm wrong, but 
> when librsvg went to rust it was a nightmare, several distros went a long 
> time without u
 pdates because of cargo.

(I am not currently advocating for cargo usage, but...)

The standard library is large compared to what we currently allow for
Mesa dependencies (libexpat, libz, libdrm basically).  First thought I
had was that my hash table/set is garbage compared to theirs, and we
could probably just wrap rust's with my C API and get a win for
compiler perf.  Having to write u_dynarray-using code makes one wish
we had Vec<>.  util/os_socket.c?  We write all sorts of stuff to work
around how we have no standard library worth speaking of currently,
and time we spend optimizing hash_table.c and fnv1 (or oh wait
xxhash32 or is that one actually best...) is time that we're not
getting to spend on making graphics code better.

If you're worried about cargo deps, introduce a cargo lockfile, even
though we're a library.  Lockfiles are for rust code used as a rust
library, I see no reason not to lock when our library has a C
interface.  Then you don't have the multiple deps or random versions
thing, it's up to us what we want to use, even if you're downloading
git of that hash off the internet.

Yes, there's the "if you blindly uprev, you can pull in malicious
deps" thing.  I feel pretty good about that given the rate of
dependency compromise attacks I've seen detected in npm/cargo/etc.,
compared to the rate of CVEs we could generate if we chose to aim a
fuzzer basically anywhere in our codebase.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Rust drivers in Mesa

[Eric Anholt]

On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig
 wrote:
>
> Hi all,
>
> Recently I've been thinking about the potential for the Rust programming
> language in Mesa. Rust bills itself a safe system programming language
> with comparable performance to C [0], which is a naturally fit for
> graphics driver development.
>
> Mesa today is written primarily in C, a notoriously low-level language,
> with some components in C++. To handle the impedance mismatch, we've
> built up a number of abstractions in-tree, including multiple ad hoc
> code generators (GenXML, NIR algebraic passes, Bifrost disassembler). A
> higher level language can help avoid the web of metaprogramming and
> effect code that is simpler and easier to reason about. Similarly, a
> better type system can aid static analysis.
>
> Beyond abstraction, Rust's differentiating feature is the borrow checker
> to guarantee memory safety. Historically, safety has not been a primary
> concern of graphics drivers, since drivers are implemented as regular
> userspace code running in the process of the application calling them.
> Unfortunately, now that OpenGL is being exposed to untrusted code via
> WebGL, the driver does become an attack vector.
>
> For the time being, Mesa attempts to minimize memory bugs with defensive
> programming, safe in-tree abstractions (including ralloc), and static
> analysis via Coverity. Nevertheless, these are all heuristic solutions.
> Static analysis is imperfect and in our case, proprietary software.
> Ideally, the bugs we've been fixing via Coverity could be caught at
> compile-time with a free and open source toolchain.
>
> As Rust would allow exactly this, I see the primary benefit of Rust in
> verifying correctness and robustness, rather than security concerns per
> se.  Indeed, safety guarantees do translate well beyond WebGL.
>
> Practically, how would Rust fit in with our existing C codebase?
> Obviously I'm not suggesting a rewrite of Mesa's more than 15 million
> lines of C. Instead, I see value in introducing Rust in targeted parts
> of the tree. In particular, I envision backend compilers written in part
> in Rust. While creating an idiomatic Rust wrapper for NIR or Gallium
> would be prohibitively costly for now, a backend compiler could be
> written in Rust with IR builders exported for use of the NIR -> backend
> IR translator written in C.
>
> This would have minimal impact on the tree. Users that are not building
> such a driver would be unaffected. For those who _are_ building Rust
> code, the Rust compiler would be added as a build-time dependency and
> the (statically linked) Rust standard library would be added as a
> runtime dependency. There is concern about the Rust compiler requiring
> LLVM as a dependency, but again this is build-time, and no worse than
> Mesa already requiring LLVM as a runtime dependency for llvmpipe and
> clover. As for the standard library, it is possible to eliminate the
> dependency as embedded Rust does, perhaps calling out to the C standard
> library via the FFI, but this is likely quixotic. I do regret the binary
> size increase, however.
>
> Implications for the build system vary. Rust prefers to be built by its
> own package manager, Cargo, which is tricky to integrate with other
> build systems. Actually, Meson has native support for Rust, invoking the
> compiler directly and skipping Cargo, as if it were C code. This support
> is not widely adopted as it prevents linking with external libraries
> ("crates", in Rust parlance), with discussions between Rust and Meson
> developers ending in a stand-still [1]. For Mesa, this might be just
> fine. Our out-of-tree run-time dependencies are minimal for the C code,
> and Rust's standard library largely avoids the need for us to maintain a
> Rust version of util/ in-tree. If this proves impractical in the
> long-term, it is possible to integrate Cargo with Meson on our end [2].
>
> One outstanding concern is build-time, which has been a notorious
> growing pain for Rust due to both language design and LLVM itself [3],
> although there is active work to improve both fronts [4][5]. I build
> Mesa on my Arm laptop, so I suppose I'd be hurt more than many of us.
> There's also awkward bootstrapping questions, but there is work here too
> [6].
>
> If this is of interest, please discuss. It's clear to me Rust is not
> going away any time soon, and I see value in Mesa embracing the new
> technology. I'd like to hear other Mesa developers' thoughts.

For me, every day I write C code, I wish I was writing rust.  I've
written hobby rust (https://crates.io/crates/gpu-trace-perf) and also
dabbled in a huge project (https://servo.org/), and I've gone through
a bit of the struggles with the borrow checker and come out the other
side being really convinced that the language is worth it.  Getting to
write rust for $dayjob is probably the only thing that could drag me
away from the Mesa project, which I love.

I think we'll miss out on a ton 

Re: [Mesa-dev] Gallium interface rename proposals

[Eric Anholt]

On Sat, Sep 19, 2020 at 3:24 AM Marek Olšák  wrote:
>
> Hi,
>
> I don't know if you have been following gitlab, but there are a few cleanups 
> that I have been considering doing.
>
> Rename PIPE_TRANSFER flags to PIPE_MAP, and pipe_transfer_usage to 
> pipe_map_flags:
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5749
>
> Other proposed renames:
>
> transfer_map -> resource_map
> transfer_unmap -> resource_unmap
> transfer_flush_region -> resource_flush_mapped_range
> draw_vbo -> draw
>
> pipe_transfer_* aux helpers -> pipe_resource_* or pipe_texture_* depending on 
> context. We already have pipe_buffer_map.
>
> I'm inclined to keep the struct pipe_transfer name unchanged to indicate that 
> mappings can cause internal copies.\

I'm a fan of all of these changes, it feels like they get us closer to
normal terminology in the field.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] nir-to-tgsi review?

[Eric Anholt]

I'd love to get some review on
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3395

I think it's time to make the switch for softpipe.  It improves
performance significantly (~10%) and makes it pass far more piglit
tests than glsl_to_tgsi does.  There are 5 regressions in doubles, but
given how broken doubles were before this I think we don't need to get
every last doubles regression fixed.  There's also one gles31
regression in GSes, but I think that's just an instance of "softpipe
GS handling is broken across the board" as one can see with the
deqp-softpipe-skips.txt list

I also have followup work waiting for this MR -- using it to replace
mesa_to_tgsi (-1200 lines), making i915g use it (letting that driver
compile far more programs than it used to), replacing ATIFS to TGSI
(cutting code and introducing optimization to this ancient shader
path), and eventually pushing it into other TGSI-consuming drivers so
we can delete glsl_to_tgsi (-10kloc) and start cleaning up the program
compile path in mesa/st (my original motivation here).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] CI for vallium question

[Eric Anholt]

On Sun, Aug 16, 2020 at 2:01 PM Dave Airlie  wrote:
>
> meson-gallium builds all the gallium drivers but no vulkan drivers.
> meson-vulkan builds all the vulkan driver but no gallium.
>
> I've changed the enable to be -Dvulkan-drivers=swrast to enable it, so
> I suppose the former is more suitable, but just looking for
> suggestions.

I would also put it in the meson-gallium group (more accurately "build
most of mesa")

LMK if you have any questions about hooking it up to deqp-runner CI,
I'm definitely looking forward to seeing that in place!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Rename "master" branch to "main"?

[Eric Anholt]

On Mon, Aug 3, 2020 at 8:30 AM Jason Ekstrand  wrote:
>
> All,
>
> I'm sure by now you've all seen the articles, LKML mails, and other
> chatter around inclusive language in software.  While mesa doesn't
> provide a whole lot of documentation (hah!), we do have a website, a
> code-base, and a git repo and this is something that we, as a project
> should consider.
>
> What I'm proposing today is simply re-naming the primary Git branch
> from "master" to "main".  Why "main"?  Because that's what GitHub has
> chosen "main" as their new default branch name and so it sounds to me
> like the most likely new default.
>
> As far as impact on the project goes, if and when we rename the
> primary branch, the old "master" branch will be locked (no
> pushing/merging allowed) and all MRs will have to be re-targeted
> against the new branch.  Fortunately, that's very easy to do.  You
> just edit the MR and there's a little drop-down box at the top for
> which branch it targets.  I just tested this with one of mine and it
> seems to work ok.
>
> As far as other bits of language in the code-base, I'm happy to see
> those cleaned up as people have opportunity.  I'm not aware of any
> particularly egregious offenders.  However, changing the name of the
> primary branch is something which will cause a brief hiccup in
> people's development process and so warrants broader discussion.
>
> Thoughts?

+1 from me
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] postmortem: a306 job fails on db410c-1 today

[Eric Anholt]

Looks like in configuring the runners to do !5661's nginx for getting
artifacts (.qpa xml files, particularly), I forgot that I had
previously used that port for passthrough caching of fd.o access to
reduce egress (which has been unused since switching off of LAVA).
And, after identifying the problem this afternoon, I turned off the
(also unused) caching nginx on the servo runner instead of the
fastboot runner, so the problem continued into the evening.  We hadn't
identified it in merging !5661 by apparently not ending up with any of
our 3 jobs allocated to #1/7 active runners in any of the pipelines
before merging.

Resolution: When enabling new runner functionality, try multiple
pipelines running in parallel to try to make sure that all the runners
get tested.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] postmortem: arm64_test job timeouts today

[Eric Anholt]

With the landing of
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5839 we
entered a state that caused future pipelines to fail.

This is due to an unfortunate interaction between gitlab MRs and
ci-templates' model of container image distribution: MRs are tested in
the submitter's repository, but ci-templates only replicates container
images from mesa/mesa to user repositories.  So, if someone has ever
uploaded a container image to their repo under a tag that can pass the
tests, they can land code that makes all future pipelines fail.  In
this case, arm64_test was near the timeout for the pipelines and was
failing for most people, including marge, and marge's queue ended up
quite backed up.

There are a few things we can do to mitigate this particular job's timeouts:

- https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5669 would
give us twice the -j flags for our builds on fd.o's x86 runners (such
as for the arm64_test job)
- https://gitlab.freedesktop.org/mesa/mesa/-/issues/3123 would let us
move back to debian testing or unstable for the test images, and use
more debian packages (like apitrace) instead of hand-building them in
our CI system
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962718 would let
us cut a big portion of the test container build times

However, I have no solution for the general problem of "users can
merge code that causes failing container builds for others."  Could we
make ci-templates not use registry-cached containers in marge-bot
pipelines, and then replicate the image up to mesa/mesa somehow?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] nir: find_msb vs clz

[Eric Anholt]

On Wed, Apr 1, 2020 at 11:39 AM Erik Faye-Lund
 wrote:
>
> While working on the NIR to DXIL conversion code for D3D12, I've
> noticed that we're not exactly doing the best we could here.
>
> First some background:
>
> NIR currently has a few instructions that does kinda the same:
>
> 1. nir_op_ufind_msb: Finds the index of the most significant bit,
> counting from the least significant bit. It returns -1 on zero-input.
>
> 2. nir_op_ifind_msb: A signed version of ufind_msb; looks for the first
> non sign-bit. It's not terribly interesting in this context, as it can
> be trivially lowered if missing, and it doesn't seem like any hardware
> supports this natively. I'm just mentioning it for completeness.
>
> 3. nir_op_uclz: Counts the amount of leading zeroes, counding from the
> most significant bit. It returns 32 on zero-input, and only exist in an
> unsigned 32-bit variation.
>
> ufind_msb is kinda the O.G here, uclz was recently added, and is as far
> as I can see only used in an intel-specific SPIR-V instruction.
>
> Additionally, there's the OpenCLstd_Clz SPIR-V instruction, which we
> lower to ufind_msb using nir_clz_u(), regardless if the backend
> supports nir_op_uclz or not.
>
> It seems only the nouveau's NV50 backend actually wants ufind_msb,
> everything else seems to convert ufind_msb to some clz-variant while
> emitting code. Some have to special-case on zero-input, and some
> not...
>
> All of this is not really awesome in my eyes.
>
> So, while adding support for DXIL, I need to figure out how to map
> these (well, ufind_msb at least) onto the DXIL intrinsics. DXIL doesn't
> have a ufind_msb, but it has a firstbit_hi that is identical to
> nir_op_uclz... except that it returns -1 on zero-input :(
>
> For now, I'm lowering ufind_msb to something ufind_msb while emitting
> code, like everyone else. But this feels a bit dirty, *especially*
> since we have a clz-instruction that *almost* fits. And since we're
> targetting OpenCL, which use clz as it's primitive, we end up doing 32
> - (32 - x), and since that inner isub happens while emitting, we can't
> easily optimize it away without introducing an optimizing backend...
>
> The solution seems obvious; use nir_op_uclz instead.
>
> But that's also a bit annoying, for a few reasons:
>
> 1. Only *one* backend actually implements support for it. So this
> either means a lot of work, or making it an opt-in feature somehow.
>
> 2. We would probably have to support lowering in either direction to
> support what all hardware prefers.
>
> 3. That zero-case still needs special treatment in several backends, it
> seems. We could alternatively declare that nir_op_uclz is undefined for
> zero-input, and handle this when lowering...?
>
> 4. It seems some (Intel?) hardware only supports 32-bit clz, so we
> would have to lower to something else for other bit-sizes. That's not
> too hard, though.
>
> So yeah...
>
> I guess the first step would be to add a switch to use nir_uclz()
> instead of nir_clz_u() when handling OpenCLstd_Clz in vtn.
>
> Next, I guess I would add a lower_ufind_msb flag to
> nir_shader_compiler_options, and make nir_opt_algebraic.py lower
> ufind_msb to uclz.
>
> Finally, we can start implementing support for this in more drivers,
> and flip on some switches.
>
> I'm still not really sold on what to do about the special-case for
> zero... By making it undefined, I think we're just punishing all
> backends, just in the name of making the compiler backends a bit
> simpler, so that doesn't seem too good of an idea either.
>
> Does anyone have a better idea? I would kinda love to optimize away the
> zero-case if it's obvious that it's impossible, e.g cases like "clz(x |
> 1)"...

FWIW, as a datapoint: broadcom's v3d has a clz that returns 32 for clz(0).

I would generally be of the opinion that we should have NIR opcodes
that match any common hardware instructions, and lowering in algebraic
to help turn input patterns into clean sequences of hardware
instructions.
___
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

[Eric Anholt]

On Fri, Feb 28, 2020 at 1:20 AM Eero Tamminen  wrote:
>
> Hi,
>
> On 28.2.2020 10.48, Dave Airlie wrote:
> >> Yes, we could federate everything back out so everyone runs their own
> >> builds and executes those. Tinderbox did something really similar to
> >> that IIRC; not sure if Buildbot does as well. Probably rules out
> >> pre-merge testing, mind.
> >
> > Why? does gitlab not support the model? having builds done in parallel
> > on runners closer to the test runners seems like it should be a thing.
> > I guess artifact transfer would cost less then as a result.
>
> Do container images being tested currently include sources, build
> dependencies or intermediate build results in addition to the installed
> binaries?
>
>
> Note: with e.g. Docker, removing those after build step doesn't reduce
> image size.
>
> You need either to do the removal in the same step, like this:
> 
> RUN git clone --branch ${TAG_LIBDRM} --depth 1 \
>  https://gitlab.freedesktop.org/mesa/drm.git && \
>  cd drm  &&  mkdir build  &&  cd build  && \
>  meson --prefix=${INSTALL_DIR} --libdir ${LIB_DIR} \
>-Dcairo-tests=false ../  && \
>  ninja  &&  ninja install  && \
>  cd ../..  &&  rm -r drm
> 
>
> Or use multi-stage container where the final stage installs just
> the run-time dependencies, and copies the final (potentially stripped)
> installed binaries from the build stage.

Our container builds already contain all the cleanup and don't do
multi-stage builds.  If you have concerns about container size, I
recommend picking a job using a container, pulling that container, and
going in and taking a look around instead of speculating.
___
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

[Eric Anholt]

On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie  wrote:
>
> On Fri, 28 Feb 2020 at 18:18, Daniel Stone  wrote:
> >
> > On Fri, 28 Feb 2020 at 03:38, Dave Airlie  wrote:
> > > b) we probably need to take a large step back here.
> > >
> > > Look at this from a sponsor POV, why would I give X.org/fd.o
> > > sponsorship money that they are just giving straight to google to pay
> > > for hosting credits? Google are profiting in some minor way from these
> > > hosting credits being bought by us, and I assume we aren't getting any
> > > sort of discounts here. Having google sponsor the credits costs google
> > > substantially less than having any other company give us money to do
> > > it.
> >
> > The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> > comparable in terms of what you get and what you pay for them.
> > Obviously providers like Packet and Digital Ocean who offer bare-metal
> > services are cheaper, but then you need to find someone who is going
> > to properly administer the various machines, install decent
> > monitoring, make sure that more storage is provisioned when we need
> > more storage (which is basically all the time), make sure that the
> > hardware is maintained in decent shape (pretty sure one of the fd.o
> > machines has had a drive in imminent-failure state for the last few
> > months), etc.
> >
> > Given the size of our service, that's a much better plan (IMO) than
> > relying on someone who a) isn't an admin by trade, b) has a million
> > other things to do, and c) hasn't wanted to do it for the past several
> > years. But as long as that's the resources we have, then we're paying
> > the cloud tradeoff, where we pay more money in exchange for fewer
> > problems.
>
> Admin for gitlab and CI is a full time role anyways. The system is
> definitely not self sustaining without time being put in by you and
> anholt still. If we have $75k to burn on credits, and it was diverted
> to just pay an admin to admin the real hw + gitlab/CI would that not
> be a better use of the money? I didn't know if we can afford $75k for
> an admin, but suddenly we can afford it for gitlab credits?

As I think about the time that I've spent at google in less than a
year on trying to keep the lights on for CI and optimize our
infrastructure in the current cloud environment, that's more than the
entire yearly budget you're talking about here.  Saying "let's just
pay for people to do more work instead of paying for full-service
cloud" is not a cost optimization.


> > Yes, we could federate everything back out so everyone runs their own
> > builds and executes those. Tinderbox did something really similar to
> > that IIRC; not sure if Buildbot does as well. Probably rules out
> > pre-merge testing, mind.
>
> Why? does gitlab not support the model? having builds done in parallel
> on runners closer to the test runners seems like it should be a thing.
> I guess artifact transfer would cost less then as a result.

Let's do some napkin math.  The biggest artifacts cost we have in Mesa
is probably meson-arm64/meson-arm (60MB zipped from meson-arm64,
downloaded by 4 freedreno and 6ish lava, about 100 pipelines/day,
makes ~1.8TB/month ($180 or so).  We could build a local storage next
to the lava dispatcher so that the artifacts didn't have to contain
the rootfs that came from the container (~2/3 of the insides of the
zip file), but that's another service to build and maintain.  Building
the drivers once locally and storing it would save downloading the
other ~1/3 of the inside of the zip file, but that requires a big
enough system to do builds in time.

I'm planning on doing a local filestore for google's lava lab, since I
need to be able to move our xml files off of the lava DUTs to get the
xml results we've become accustomed to, but this would not bubble up
to being a priority for my time if I wasn't doing it anyway.  If it
takes me a single day to set all this up (I estimate a couple of
weeks), that costs my employer a lot more than sponsoring the costs of
the inefficiencies of the system that has accumulated.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Drop scons for 20.1?

[Eric Anholt]

On Tue, Feb 25, 2020 at 3:42 PM Kristian Høgsberg  wrote:
>
> It's been a while since Dylan did the work to make meson support
> Windows and there's been plenty of time to provide feedback or improve
> argue why we still need scons. I haven't seen any such discussion and
> I think we've waited long enough.
>
> Let's drop scons for the next release and move things forward?

I agree.  We shouldn't be spending project resources (developer time,
CI machine time) on a duplicate build system for a closed source fork
of Mesa.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Broken rendering of glxgears on S/390 architecture (64bit, BigEndian)

[Eric Anholt]

On Tue, Feb 4, 2020 at 7:54 PM Rob Clark  wrote:
>
> it seems like BE vs formats (vs llvm) is a constant nightmare, because
> there are essentially no mesa dev's working on BE devices (ie. issues
> are generally discovered long after the fact when mesa changes finally
> propagate into into enterprise distros).. but with gitlab we have now
> a sane scheme to plug in more decentralized CI runners if someone
> wants to step up and figure out how get some BE test coverage into
> CI.. just saying.. ;-)

We don't even need runners:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3643
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] Mesa 20.0 branchpoint planned for 2020/01/29, Milestone opened

[Eric Anholt]

On Thu, Jan 23, 2020 at 9:44 AM Jason Ekstrand  wrote:
>
> Should we make iris the default for 20.0?  I think it's time.  Sadly, gitlab 
> milestones don't let you comment on them.

It does seem like it's time to flip that switch.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] marge currently down

[Eric Anholt]

marge broke over the holidays due to a gitlab upgrade.  It's unclear
when we'll get it back up -- daniels might do a downgrade but is
currently out sick

https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/228
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Merge bot ("Marge") enabled

[Eric Anholt]

On Tue, Dec 17, 2019 at 9:53 AM Juan A. Suarez Romero
 wrote:
>
> On Fri, 2019-12-13 at 13:35 -0800, Eric Anholt wrote:
> > I finally got back around to experimenting with the gitlab merge bot,
> > and it turns out that the day I spent a few weeks back I had actually
> > given up 5 minutes before the finish line.
> >
> > Marge is now enabled for mesa/mesa, piglit, and parallel-deqp-runner.
> > How you interact with marge:
> >
> > - Collect your reviews
> > - Put reviewed-by tags in your commits
>
> I don't know if this is possible, but another cool improvement would be using
> the approvals feature to replace reviewed-by: a MR should be approved by at
> least one person, and Marge could add this information in the commit as a
> "Reviewed-by" tag. This way, we ensure all MR are reviewed, and we don't need 
> to
> update the MR manually just to ensure a reviewed-by is added.

Approvers is a gitlab EE feature, while freedesktop.org uses the
open-source gitlab CE.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Merge bot ("Marge") enabled

[Eric Anholt]

On Fri, Dec 13, 2019 at 1:35 PM Eric Anholt  wrote:
>
> I finally got back around to experimenting with the gitlab merge bot,
> and it turns out that the day I spent a few weeks back I had actually
> given up 5 minutes before the finish line.
>
> Marge is now enabled for mesa/mesa, piglit, and parallel-deqp-runner.

First surprise!  Two of these repos had "pipelines must pass in order
to merge" unset in their settings, so Marge skipped the tests on her
first merge.  I've now set that (and also the fancy new "enable delete
source branch after merge" setting!) in those repositories.

Hopefully this doesn't break some other workflow.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Merge bot ("Marge") enabled

[Eric Anholt]

I finally got back around to experimenting with the gitlab merge bot,
and it turns out that the day I spent a few weeks back I had actually
given up 5 minutes before the finish line.

Marge is now enabled for mesa/mesa, piglit, and parallel-deqp-runner.
How you interact with marge:

- Collect your reviews
- Put reviewed-by tags in your commits
- When you would have clicked "Merge when pipeline succeeds" (or,
worse, rebase and then merge when pipeline succeeds), instead edit the
assignee of the MR (top right panel of the UI) and assign to Marge Bot
- Marge will eventually take your MR, rebase it and let the pipeline run.
- If the pipeline passes, Marge will merge it
- If the pipeline fails, Marge will note it in the logs and unassign
herself (so your next push with a "fix" won't get auto-merged until
you decide to again).

In the commit logs of the commits that Marge rebased (they'll always
be rebased), you'll get:

Part-of: 


In the final commit of that MR, you'll get:

Tested-by: Marge Bot


I feel like this is a major improvement to our workflow, in terms of
linking commits directly to their discussions without indirecting
through google.

Note that one Marge instance will only process one MR at a time, so we
could end up backed up.  There's a mode that will form merge trains,
but I don't understand that mode enough yet to trust it. I think for
Mesa at this point this is going to be fine, as we should still be
able to push tens of MRs through per day.  As we scale up, we may find
that we need a separate Marge for piglit and other projects, which I
should be able to set up reasonably at this point.

Once we settle in with Marge and learn to trust our robot overlords,
I'll update the contributor docs to direct people to Marge instead of
the "merge when pipeline succeeds" button.  I'm also hoping that once
our commit logs are full of links to discussions, we can drop the
mandatory squashing of r-b tags into commit messages and thus make our
process even easier for new contributors.
___
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?

[Eric Anholt]

On Wed, Dec 11, 2019 at 2:35 PM Timothy Arceri  wrote:
>
> Hi,
>
> So it seems lately we have been increasingly merging patches with made
> up names, or single names etc [1]. The latest submitted patch has the
> name Icecream95. This seems wrong to me from a point of keeping up the
> integrity of the project. I'm not a legal expert but it doesn't seem
> ideal to be amassing commits with these type of author tags from that
> point of view either.
>
> Is it just me or do others agree we should at least require a proper
> name on the commits (as fake as that may be also)? Seems like a low bar
> to me.

I'm of the opinion that in fact all names are made up, and we don't
want to be getting into the business of requiring legal names for
committing.  If legal names were what you were getting at: have you
checked the legal names of your fellow contributors match what they're
contributing under?

I don't know what legal risk you might be thinking of, that seems like
spreading fear for no reason to me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Running the CI pipeline on personal Mesa branches

[Eric Anholt]

On Fri, Dec 6, 2019 at 3:56 PM Rob Clark  wrote:
>
> On Fri, Dec 6, 2019 at 3:46 PM Bas Nieuwenhuizen
>  wrote:
> >
> > On Fri, Dec 6, 2019 at 10:49 AM Michel Dänzer  wrote:
> > >
> > >
> > > I just merged
> > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2794 , which
> > > affects people who want to run the CI pipeline on personal Mesa branches:
> > >
> > > Pushing changes to a personal branch now always creates a pipeline, but
> > > none of the jobs in it run by default. (There are no longer any special
> > > branch names affecting this, because creating MRs from such special
> > > branches resulted in duplicate CI job runs)
> > >
> > > The container stage jobs can be triggered manually from the GitLab UI
> > > (and maybe also via the GitLab API, for people who'd like to automate
> > > this? I haven't looked into that). The build/test stage jobs run
> > > automatically once all their dependencies have passed.
> > >
> > > As an example, in order to run one of the "piglit-*" test jobs, one has
> > > to manually trigger the "x86_build" and "x86_test" jobs.
> > >
> > > The pipelines created for merge requests still run all jobs by default
> > > as before.
> > >
> > >
> > > The main motivation for these changes is to avoid wasting CI runner
> > > resources. In that same spirit, please also cancel any unneeded
> > > build/test jobs. This can be done already before those jobs start
> > > running, e.g. while the container stage jobs run.
> >
> > No complaint about not running the pipelines by default in personal
> > repositories, but expecting people to cancel automatically spawned CI
> > jobs as normal part of their workflow seems incredibly fiddly and
> > fragile to me. Are we *that* constrained?
> >
>
> It would be nice if there was some way to setup some conservative
> filters to exclude groups of tests, ie. if only paths changed were
> under src/freedreno or src/gallium/drivers/freedreno, then no need to
> run panfrost CI, and visa versa.  We probably shouldn't try to fine
> tune that *too* much at this risk of skipping tests that should have
> run, but seems like there should be same safe low hanging fruit to cut
> down on CI runs in common cases.
>
> I guess maybe that only helps if the bottleneck are the hw CI runners,
> which might not be the case.. I'm not sure.

Our bottleneck, every time I go check, is in x86_64 build/test job slots.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Eric Anholt]

On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák  wrote:
>
> Hi,
>
> Here are 2 proposals to simplify and better optimize the GL->Gallium 
> translation.
>
> 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> Classic drivers won't share any code with master. glvnd will load them, but 
> glvnd is not ready for this yet.
>
> 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, 
> mesa/vbo, mesa/program, and drivers/dri/common need to be forked and 
> mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target 
> location.
>
> Option 2 is more acceptable to people who want to keep classic drivers in the 
> tree and it can be done right now.

(resending reply-all)

I object to both of these.  They increase work for Mesa folks like me
who do tree-wide work.

I feel like we're finally (formats, util/ helpers, etc.) paying down
the technical debt that we built with gallium copying so much of
src/mesa/main, and saying "let's go duplicate more code so we can do
some unspecified optimization work" gets me really upset.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Eric Anholt]

On Tue, Dec 3, 2019 at 10:48 PM Marek Olšák  wrote:
>
> On Wed., Dec. 4, 2019, 01:20 Tapani Pälli,  wrote:
>>
>> Hi;
>>
>> On 12/4/19 2:39 AM, Marek Olšák wrote:
>> > Hi,
>> >
>> > Here are 2 proposals to simplify and better optimize the GL->Gallium
>> > translation.
>> >
>> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
>> > Classic drivers won't share any code with master. glvnd will load them,
>> > but glvnd is not ready for this yet.
>> >
>> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
>> > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be
>> > forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can
>> > be the target location.
>> >
>> > Option 2 is more acceptable to people who want to keep classic drivers
>> > in the tree and it can be done right now.
>> >
>> > Opinions?
>> >
>>
>> I'm still quite newbie with gallium side of things and I'd like to know
>> more about the possible simplifications and optimizations that could be
>> done if this happened. Is this more about 'cleaning up the tree' or are
>> there also some performance opportunities we are missing right now with
>> current state?
>
>
> It's possible to reduce CPU overhead even more by moving state translation 
> from st_validate_state to GL functions. This is possible already, but at the 
> cost of effectively adding dead code to classic drivers. In theory we could 
> do slightly better without classic drivers, but we don't know for sure.

So just go do that!  Seriously, just stuff the state structs in the
Mesa context and maintain them as we go, the overhead for classic will
be low enough.  We're going to want to track the raw-style state
anyway for glGet() and all our validation, so it's not like we're
going to be garbage collecting a ton of stuff by forking out classic
drivers.

> If we had nir_to_tgsi, we could remove TGSI support from st/mesa. Option 1 
> would leave st/mesa as the only consumer of Mesa IR and GLSL IR, so both IRs 
> could be eliminated in favor of NIR more easily. Although I guess a simpler 
> option is not to touch anything.

I would love to see someone pick up my nir-to-tgsi branch (now 5 years
old?) and run with it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] How do people feel about D3D in piglit?

[Eric Anholt]

On Tue, Nov 19, 2019 at 8:26 AM Jason Ekstrand  wrote:
>
> Ok, that's a bit of a weird click-bait title but it's descriptive.  One of 
> the things that we really need to get tested in piglit is the GL <-> Vulkan 
> interop extensions.  The Vulkan bits are implemented in ANV and RADV and the 
> GL bit is implemented in radeonsi but we don't have a good test plan at the 
> moment.  Because any such tests necessarily go across APIs, they can't really 
> be put into the Vulkan CTS or the OpenGL CTS.  This makes piglit the natural 
> place to put such tests.
>
> Ok, back to my question at the top.  Let's say that someone wants to use said 
> piglit tests on Windows.  In that case, they really need to be able to test 
> Vulkan <-> D3D11 interop as well as Vulkan <-> GL.  One could imagine, for 
> instance, that maybe DXVK would like to implement such interop on top of 
> Vulkan <-> Vulkan interop in which case they would need tests.
>
> So, does anyone have a major problem with Piglit linking against D3D APIs 
> when built on Windows?  I'm happy if it has to sit behind a flag.

Sounds like the right place to me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa CI with trace regression testing

[Eric Anholt]

Eero Tamminen  writes:

> Hi,
>
> On 27.9.2019 4.32, Eric Anholt wrote:
>> Alexandros Frantzis  writes:
>>> The last couple of months we (at Collabora) have been working on a
>>> prototype for a Mesa testing system based on trace replays that supports
>>> correctness regression testing and, in the future, performance
>>> regression testing.
>>>
>>> We are aware that large-scale CI systems that perform extensive checks
>>> on Mesa already exist. However, our goal is not to reach that kind of
>>> scale or exhaustiveness, but to produce a system that will be simple and
>>> robust enough to be maintained by the community, while being useful
>>> enough so that the community will want to use and maintain it. We also
>>> want to be able to make it fast enough so that it will be run eventually
>>> on a regular basis, ideally in pre-commit fashion.
>>>
>>> The current prototype focuses on the correctness aspect, replaying
>>> traces and comparing images against a set of reference images on
>>> multiple devices. At the moment, we run on softpipe and
>>> intel/chromebook, but it's straightforward to add other devices through
>>> gitlab runners.
>>>
>>> For the prototype we have used a simple approach for image comparison,
>>> storing a separate set of reference images per device and using exact
>>> image comparison, but we are also investigating alternative ways to deal
>>> with this. First results indicate that the frequency of reference image
>>> mismatches due to non-bug changes in Mesa is acceptable, but we will get
>>> a more complete picture once we have a richer set of traces and a longer
>>> CI run history.
>
> For CI, I think discarding/ignoring too unstable / slow traces would
> be perfectly acceptable. [1]
>
>
>> Some missing context: I was told that over 2400 commits, in glmark2 + a
>> couple of other open source traces, on intel, there was one spurious
>> failure due to this diff method.  This is lower than I felt like it was
>> when I did this in piglit on vc4, but then I was very actively changing
>> optimization in the compiler while I was using that tool.
>
> Few years ago when I was looking at the results from ezBench (at
> the same time) bisecting Mesa commit ranges for build, run-time,
> performance and rendering issues, it was very useful to have
> rendering diff results in addition to performance numbers.
>
> Rendering didn't change too often, but one needs to look at every change
> screenshot directly, error metrics about them aren't enough.  Some
> innocent accuracy difference due to calculation order change can cause
> e.g. marginally different color on huge area on the rendered result [1],
> whereas some real rendering error can be just some tiny reflection
> missing from the render, which one would never see from running
> benchmark (even with correct one running beside it), one sees them only
> from static screenshots.
>
> [1] Whether screenshots are affected by calculation changes, depends
> a lot on the benchmark, how stable its calculations are in regards to
> accuracy variations. Some benchmarks even use random in their shaders...
>
> (If I remember correctly, good example of unstable results were some
> of the GpuTest benchmarks.)
>
>
>>> The current design is based on an out-of-tree approach, where the tracie
>>> CI works independently from Mesa CI, fetching and building the latest
>>> Mesa on its own. We did this for maximum flexibility in the prototyping
>>> phase, but this has a complexity cost, and although we could continue to
>>> work this way, we would like to hear people's thoughts about eventually
>>> integrating with Mesa more closely, by becoming part of the upstream
>>> Mesa testing pipelines.
>>>
>>> It's worth noting that the last few months other people, most notably
>>> Eric Anholt, have made proposals to extend the scope of testing in CI.
>>> We believe there is much common ground here (multiple devices,
>>> deployment with gitlab runners) and room for cooperation and eventual
>>> integration into upstream Mesa. In the end, the main difference between
>>> all these efforts are the kind of tests (deqp, traces, performance) that
>>> are being run, which all have their place and offer different
>>> trade-offs.
>>>
>>> We have also implemented a prototype dashboard to display the results,
>>> which we have deployed at:
>>>
>>> https://tracie.freedesktop.org
>>>
>>> We are working to improve the dashbo

Re: [Mesa-dev] Mesa CI with trace regression testing

[Eric Anholt]

Alexandros Frantzis  writes:

> Hi all,
>
> The last couple of months we (at Collabora) have been working on a
> prototype for a Mesa testing system based on trace replays that supports
> correctness regression testing and, in the future, performance
> regression testing.
>
> We are aware that large-scale CI systems that perform extensive checks
> on Mesa already exist. However, our goal is not to reach that kind of
> scale or exhaustiveness, but to produce a system that will be simple and
> robust enough to be maintained by the community, while being useful
> enough so that the community will want to use and maintain it. We also
> want to be able to make it fast enough so that it will be run eventually
> on a regular basis, ideally in pre-commit fashion.
>
> The current prototype focuses on the correctness aspect, replaying
> traces and comparing images against a set of reference images on
> multiple devices. At the moment, we run on softpipe and
> intel/chromebook, but it's straightforward to add other devices through
> gitlab runners.
>
> For the prototype we have used a simple approach for image comparison,
> storing a separate set of reference images per device and using exact
> image comparison, but we are also investigating alternative ways to deal
> with this. First results indicate that the frequency of reference image
> mismatches due to non-bug changes in Mesa is acceptable, but we will get
> a more complete picture once we have a richer set of traces and a longer
> CI run history. 

Some missing context: I was told that over 2400 commits, in glmark2 + a
couple of other open source traces, on intel, there was one spurious
failure due to this diff method.  This is lower than I felt like it was
when I did this in piglit on vc4, but then I was very actively changing
optimization in the compiler while I was using that tool.

> The current design is based on an out-of-tree approach, where the tracie
> CI works independently from Mesa CI, fetching and building the latest
> Mesa on its own. We did this for maximum flexibility in the prototyping
> phase, but this has a complexity cost, and although we could continue to
> work this way, we would like to hear people's thoughts about eventually
> integrating with Mesa more closely, by becoming part of the upstream
> Mesa testing pipelines.
>
> It's worth noting that the last few months other people, most notably
> Eric Anholt, have made proposals to extend the scope of testing in CI.
> We believe there is much common ground here (multiple devices,
> deployment with gitlab runners) and room for cooperation and eventual
> integration into upstream Mesa. In the end, the main difference between
> all these efforts are the kind of tests (deqp, traces, performance) that
> are being run, which all have their place and offer different
> trade-offs.
>
> We have also implemented a prototype dashboard to display the results,
> which we have deployed at:
>
> https://tracie.freedesktop.org
>
> We are working to improve the dashboard and provide more value by
> extracting and displaying additional information, e.g., "softpipe broken
> since commit NNN".
>
> The dashboard is currently specific to the trace playback results, but
> it would be nice to eventually converge to a single MesaCI dashboard
> covering all kinds of Mesa CI test results. We would be happy to help
> develop in this direction if there is interest.
>
> You can find the CI scripts for tracie at:
>
> https://gitlab.freedesktop.org/gfx-ci/tracie/tracie
>
> Code for the dashboard is at:
>
> https://gitlab.freedesktop.org/gfx-ci/tracie/tracie_dashboard
>
> Here is an example of a failed CI job (for a purposefully broken Mesa
> commit) and the report of the failed trace (click on the red X to
> see the image diffs):
>
> https://tracie.freedesktop.org/dashboard/job/642369/
>
> Looking forward to your thoughts and comments.

A couple of thoughts on this:

A separate dashboard is useful if we have traces that are too slow to
run pre-merge or are not redistributable.  For traces that are
redistributable and cheap to run, we should run them in our CI and block
the merge instead of having someone have to watch an external dashboard
and report things to get patched up after regressions have already
landed.

I'm reluctant to add "maintain a web service codebase" as one of the
things that the Mesa project does, if there are alternatives that don't
involve that.  I've been thinking about a perf dashboard, and for that
I'd like to reuse existing open source projects like grafana.  If we
start our own dashboard project, are we going to end up reimplementing
that one?


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] freedreno CI day 1

[Eric Anholt]

Eric Anholt  writes:

> [ Unknown signature status ]
> I pushed the branch enabling freedreno CI today.  Now all the MRs will
> get pre-merge testing with GLES3.1 on A630, and GLES2 on A307.
>
> See .gitlab-ci/README.md for more info on how it works.  Also, as a
> reminder, if you want to get something tested before generating your MR,
> you can either edit .gitlab-ci.yml to change .ci-run-policy, or push the
> branch to your repo with a name starting with "ci-".  Secondary note: If
> you make an MR from a branch starting with "ci-", it will have two
> pipelines run every time you update it :(
>
> Today's surprises:
>
> - layout_binding.ssbo.fragment_binding_array is unstable
>
> I did one test to see if a patch I had on hand would fix it, and it
> didn't, so I pushed through a patch disabling that test from CI so you
> all wouldn't see those failures.
>
> - EXT4 FS corruption
>
> A few unfortunate events came together for this one: I had the kernel
> boot args mounting / rw out of habit from back in my NFS-root days, and
> there's no initrd to fsck /, and also I have harshly power-cycled them
> all in the process of setting things up.  This adds up to "there's minor
> corruption on / that may impact test runs."  Watch out for mysterious
> docker errors.  If this occurs at a bothersome rate, feel free to push a
> disable of freedreno CI until I can fix it, though it doesn't look too
> bad yet.  I'll be fixing those boot args and making sure that we've got
> clean filesystems on all boards tomorrow.

I've now enabled fsck on all the boards and we should be back in
business.  Looks like I can do this kind of change (bringing each board
down in turn) without interrupting overall CI availability, which seems
like a pretty good test.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] freedreno CI day 1

[Eric Anholt]

I pushed the branch enabling freedreno CI today.  Now all the MRs will
get pre-merge testing with GLES3.1 on A630, and GLES2 on A307.

See .gitlab-ci/README.md for more info on how it works.  Also, as a
reminder, if you want to get something tested before generating your MR,
you can either edit .gitlab-ci.yml to change .ci-run-policy, or push the
branch to your repo with a name starting with "ci-".  Secondary note: If
you make an MR from a branch starting with "ci-", it will have two
pipelines run every time you update it :(

Today's surprises:

- layout_binding.ssbo.fragment_binding_array is unstable

I did one test to see if a patch I had on hand would fix it, and it
didn't, so I pushed through a patch disabling that test from CI so you
all wouldn't see those failures.

- EXT4 FS corruption

A few unfortunate events came together for this one: I had the kernel
boot args mounting / rw out of habit from back in my NFS-root days, and
there's no initrd to fsck /, and also I have harshly power-cycled them
all in the process of setting things up.  This adds up to "there's minor
corruption on / that may impact test runs."  Watch out for mysterious
docker errors.  If this occurs at a bothersome rate, feel free to push a
disable of freedreno CI until I can fix it, though it doesn't look too
bad yet.  I'll be fixing those boot args and making sure that we've got
clean filesystems on all boards tomorrow.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Enabling freedreno CI in Mesa MRs

[Eric Anholt]

Rob Clark  writes:

> On Wed, Sep 4, 2019 at 1:42 PM Eric Anholt  wrote:
>>
>> If you haven't seen this MR:
>>
>> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1632
>>
>> I feel ready to enable CI of freedreno on Mesa MRs.  There are some docs
>> here:
>>
>> https://gitlab.freedesktop.org/mesa/mesa/blob/e81a2d3b40240651f506a2a5afeb989792b3dc0e/.gitlab-ci/README.md
>>
>> Once we merge this, this will greatly increase Mesa's pre-merge CI
>> coverage on MRs by getting us up to GLES3.1 going through the CTS.  Once
>> krh is ready to put up an in-progress MR of tess, we can override the
>> GLES3.1 run to force-enable 3.2 with the remaining tess issues as
>> expected fails, and get a whole lot more API coverage.
>>
>> As far as stability of this CI, I've been through I think an order of
>> magnitude more runs of the CI than are visible from that MR, and I'm
>> pretty sure we've got a stable set of tests now -- I'm currently working
>> on fixing the flappy tests so we can drop the a630-specific skip list.
>> The lab has also been up for long enough that I'm convinced the HW is
>> stable enough to subject you all to it.
>
> I won't claim to be an unbiased observer, but I'm pretty excited about
> this.  This has been in the works for a while, and I think it is to
> the point where we aren't going to get much more useful testing of our
> gitlab runners with it living off on a branch, so at some point you
> just have to throw the switch.
>
> I'd propose, that unless there are any objections, we land this Monday
> morning (PST) on master, to ensure a relatively short turn-around just
> in case something went badly.
>
> (I can be online(ish) over the weekend if we want to throw the switch
> sooner.. but I might be AFK here and there to get groceries and things
> like that.  So response time might be a bit longer than on a week
> day.)

I'm going to be gone on my yearly bike trip until Tuesday, so I propose
delaying until then so I can be more responsive :)


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Enabling freedreno CI in Mesa MRs

[Eric Anholt]

Tomeu Vizoso  writes:

> On Fri, 6 Sep 2019 at 03:23, Rob Clark  wrote:
>>
>> On Wed, Sep 4, 2019 at 1:42 PM Eric Anholt  wrote:
>> >
>> > If you haven't seen this MR:
>> >
>> > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1632
>> >
>> > I feel ready to enable CI of freedreno on Mesa MRs.  There are some docs
>> > here:
>> >
>> > https://gitlab.freedesktop.org/mesa/mesa/blob/e81a2d3b40240651f506a2a5afeb989792b3dc0e/.gitlab-ci/README.md
>> >
>> > Once we merge this, this will greatly increase Mesa's pre-merge CI
>> > coverage on MRs by getting us up to GLES3.1 going through the CTS.  Once
>> > krh is ready to put up an in-progress MR of tess, we can override the
>> > GLES3.1 run to force-enable 3.2 with the remaining tess issues as
>> > expected fails, and get a whole lot more API coverage.
>> >
>> > As far as stability of this CI, I've been through I think an order of
>> > magnitude more runs of the CI than are visible from that MR, and I'm
>> > pretty sure we've got a stable set of tests now -- I'm currently working
>> > on fixing the flappy tests so we can drop the a630-specific skip list.
>> > The lab has also been up for long enough that I'm convinced the HW is
>> > stable enough to subject you all to it.
>>
>> I won't claim to be an unbiased observer, but I'm pretty excited about
>> this.  This has been in the works for a while, and I think it is to
>> the point where we aren't going to get much more useful testing of our
>> gitlab runners with it living off on a branch, so at some point you
>> just have to throw the switch.
>>
>> I'd propose, that unless there are any objections, we land this Monday
>> morning (PST) on master, to ensure a relatively short turn-around just
>> in case something went badly.
>>
>> (I can be online(ish) over the weekend if we want to throw the switch
>> sooner.. but I might be AFK here and there to get groceries and things
>> like that.  So response time might be a bit longer than on a week
>> day.)
>>
>> Objections anyone?  Or counter-proposals?
>
> I like the MR a lot and I think it will be a great base for CI for
> panfrost and other gallium SoC drivers.
>
> I'm concerned about the reliability of the current setup though, the
> latest CI run I see in anholt/mesa seemed to fail due to problems in
> the runners?
>
> https://gitlab.freedesktop.org/anholt/mesa/pipelines/61502

Those A306 failures were from the disk filling up, and scripting a fix
for that was one of the TODO items in the MR and is done now.

The A630 failure there is the actual driver bug that that that run
caught.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Enabling freedreno CI in Mesa MRs

[Eric Anholt]

If you haven't seen this MR:

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1632

I feel ready to enable CI of freedreno on Mesa MRs.  There are some docs
here:

https://gitlab.freedesktop.org/mesa/mesa/blob/e81a2d3b40240651f506a2a5afeb989792b3dc0e/.gitlab-ci/README.md

Once we merge this, this will greatly increase Mesa's pre-merge CI
coverage on MRs by getting us up to GLES3.1 going through the CTS.  Once
krh is ready to put up an in-progress MR of tess, we can override the
GLES3.1 run to force-enable 3.2 with the remaining tess issues as
expected fails, and get a whole lot more API coverage.

As far as stability of this CI, I've been through I think an order of
magnitude more runs of the CI than are visible from that MR, and I'm
pretty sure we've got a stable set of tests now -- I'm currently working
on fixing the flappy tests so we can drop the a630-specific skip list.
The lab has also been up for long enough that I'm convinced the HW is
stable enough to subject you all to it.

Once this is merged, please @anholt me on your MRs if you find spurious
failures in freedreno so I can go either disable those tests or fix
them.

For some info on how I set up my DUTs, see
https://gitlab.freedesktop.org/anholt/mesa/wikis/db410c-setup for
starting from a pretty normal debian buster rootfs.  I'd love to work
with anyone on replicating this style of CI for your own hardware lab if
you're interested, or hooking pre-merge gitlab CI up to your existing CI
lab if you can make it public-access (panfrost?  Intel's CI?)


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Switching to Gitlab Issues instead of Bugzilla?

[Eric Anholt]

Kenneth Graunke  writes:

> [ Unknown signature status ]
> Hi all,
>
> As a lot of you have probably noticed, Bugzilla seems to be getting a
> lot of spam these days - several of us have been disabling a bunch of
> accounts per day, sweeping new reports under the rug, hiding comments,
> etc.  This bug spam causes emails to be sent (more spam!) and then us
> to have to look at ancient bugs that suddenly have updates.
>
> I think it's probably time to consider switching away from Bugzilla.
> We are one of the few projects remaining - Mesa, DRM, and a few DDX
> drivers are still there, but almost all other projects are gone:
>
> https://bugs.freedesktop.org/enter_bug.cgi
>
> Originally, I was in favor of retaining Bugzilla just to not change too
> many processes all at once.  But we've been using Gitlab a while now,
> and several of us have been using Gitlab issues in our personal repos;
> it's actually pretty nice.

Yes, please.  I haven't been participating in bugzilla, in favor of
personal github and krh's mesa gitlab.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] dEQP + llvmpipe

[Eric Anholt]

Ilia Mirkin  writes:

> Hi Eric,
>
> I see that you recently added testing dEQP with llvmpipe in the CI. It
> looks like a number of your expected failures would be resolved by
> disabling some llvmpipe optimizations. You can do this by running with
>
> GALLIVM_DEBUG=no_rho_approx,no_brilinear,no_quad_lod
>
> in the environment. Some of this is detailed in
> https://bugs.freedesktop.org/show_bug.cgi?id=94957 .

Yeah, this was discussed in the MR.  I think that for GL and GLES
contexts, we should disable noncormant hacks instead of using env vars
to falsely claim conformance.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Getting write permissions on the mesa repo to push panfrost stuff

[Eric Anholt]

Boris Brezillon  writes:

> Hello,
>
> Alyssa recently proposed that I push my own panfrost-related
> submissions once they received proper review and are considered
> ready to merged (meaning that received enough A-b/R-b tags).
>
> In order to do that, I'd need to obtain write permissions on the git
> repo. Note that I already have an account on fd.o (my nick is
> bbrezillon). I guess Alyssa and/or Tomew will ack this request soon. Let
> me know if you need anything else from me.

I've added you -- you certainly did good work when we were working on
vc4.  Coordinate with Alyssa and Tomeu on expectations for merging to
panfrost :)


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [MR] Update README to recommend MRs instead of `git send-email`

[Eric Anholt]

Jason Ekstrand  writes:

> On Tue, Jul 9, 2019 at 11:19 AM Kristian Høgsberg 
> wrote:
>
>> On Tue, Jul 9, 2019 at 12:17 AM Daniel Stone  wrote:
>> >
>> > Hi,
>> >
>> > On Sat, 6 Jul 2019 at 18:39, Ilia Mirkin  wrote:
>> > > I see this as driving away contributions, esp from new people. MR's
>> > > are annoying to create, since they require dealing with the hosting
>> > > provider, getting it to host clones, etc. Everyone has email.
>> >
>> > My position - and the evidence of velocity from projects who have
>> > switched - is already pretty clear, but you might be interested to
>> > read that even kernel.org admins are trying to move away from email:
>> >
>> https://people.kernel.org/monsieuricon/patches-carved-into-developer-sigchains
>>
>> I have the same experience - I've used git since before it was usable
>> and I'm more than happy to not have to worry about making git
>> send-email work. I'm pretty sure that gitlab in general lowers the bar
>> for contributions considerably, I know I find my self doing a lot more
>> reviews and drive-by comments because of how easy it feels
>
>
> I know I'm a gitlab fan-boy so you all know I like this.  What I will say
> is that it's not only easier for new developers because PRs are a concept
> they already know from GitHub and the like but it's also easier for
> maintainers.  I've actually started getting annoyed when people send
> patches to the list and I have to apply them from e-mail.  It's so much
> easier to just check that they've added all the tags and click a couple
> buttons in the web UI than to have to find the thing on patchwork, download
> it, hope it applies, and push it.

Same.  I'm actually not reading patches on the mailing list any more.
If you want my input, put it in the system where I don't have to waste
my time tracking if it's been merged or not and whether you responded to
my comments from the last round.

I don't think we're quite to "make sure they've added the tags and click
the button" safely since we don't have pre-merge testing happening (you
have to trust that the submitter tested, and master hasn't regressed
things since then).  I'm working on that.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] What does WIP really mean in an MR?

[Eric Anholt]

Eric Engestrom  writes:

> On Saturday, 2019-06-29 22:59:21 +0200, apinheiro wrote:
>> 
>> On 29/6/19 2:30, Rob Clark wrote:
>> > I had interpreted it as literally the "block the gitlab merge button"
>> > option, ie. "I want to get feedback but it is not ready to merge and
>> > I'll drop the WIP tag when I think it is"..
>> 
>> 
>> > 
>> > (comments inline)
>> > 
>> > On Fri, Jun 28, 2019 at 5:12 PM Ian Romanick  wrote:
>> > > After a conversation yesterday with a couple of the other Intel devs,
>> > > I've come to the conclusion that *everyone* interprets WIP to mean
>> > > something different.  I heard no less than four interpretations.
>> > > 
>> > > * This series is good.  It hasn't been reviewed, so don't click "merge."
>> > isn't that the point of a MR.. doesn't seem like a reason for "WIP"
>> 
>> 
>> I agree with Rob here. What I understand of WIP is that there is some reason
>> that prevents a MR to be merged, even if I still want it to be reviewed, or
>> if it is fully reviewed. For example, I send a MR with patches that I think
>> that are correct, so people can start to review it. But on a rebase, I found
>> that the branch causes regressions on piglit/cts/whatever. I still think
>> that the patches are correct, but those regressions need to be investigated
>> before pushing. So I just add a WIP on the MR to prevent to be merged by
>> mistake.
>
> Kind of just saying "+1" here, but yeah that's also my understanding of "WIP".

+1

"WIP" is for "There is some issue with this (other than lack of review)
that prevents merging, so disable the merge button."


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm: add gbm_{bo, surface}_create_with_modifiers2

[Eric Anholt]

Daniel Stone  writes:

> Hi,
>
> On Tue, 25 Jun 2019 at 16:07, Jason Ekstrand  wrote:
>> On Tue, Jun 25, 2019 at 4:04 AM Daniel Stone  wrote:
>>> On Tue, 25 Jun 2019 at 07:26, Simon Ser  wrote:
>>> > > I noticed that original patch (v1) for gbm_bo_create_with_modifiers did
>>> > > have usage at first but it was removed during the review. I'm having
>>> > > trouble digging what was the reason for this?
>>> >
>>> > I'm not sure either. Daniel said it was a mistake.
>>> >
>>> > Adding the 63bd2ae7452d4 folks to the discussion. Ben, do you remember
>>> > the details?
>>>
>>> We decided to remove it since we decided that modifiers were a good
>>> enough proxy for usage; no need to pass SCANOUT or TEXTURE anymore,
>>> because we already get the scanout modifiers from KMS and the texture
>>> modifiers from EGL.
>>>
>>> In hindsight, I think this was a mistake since it only handles buffer
>>> layout, and not buffer placement or cache configuration.
>>
>>
>> It's not great but modifiers should be able to handle that as well.  You can 
>> have _CONTIGUOUS versions of the modifiers supported by scanout and scanout 
>> will only advertise those and the caller has to know to place them in 
>> contiguous memory.  That's just an example but I think it would probably 
>> work for a lot of the cases.  If not, I'd love to know why not.
>
> Sometimes it's _CONTIGUOUS, sometimes it's _ON_THIS_PCIE_DEVICE.
> Either way, it does seem like a bit of an abuse: it has nothing to do
> with internal buffer layout, but how and where the backing pages are
> sourced.
>
> Given that it's completely orthogonal, I wouldn't like to go trying to
> combine it into the same namespace.

Agreed.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

[Eric Anholt]

Elie Tournier  writes:

> On Mon, Jun 24, 2019 at 11:41:55AM -0700, Eric Anholt wrote:
>> Elie Tournier  writes:
>> 
>> > Hi there,
>> >
>> > Great topic. For the past few days, I was looking at a CI for Mesa:
>> > https://gitlab.freedesktop.org/hopetech/tracie
>> > OK, it's in a very very alpha stage. ;)
>> 
>> I did one of those things using apitrace diff-images in piglit:
>> 
>> https://gitlab.freedesktop.org/mesa/piglit/tree/master/tests/apitrace
>> 
>> https://github.com/anholt/trace-db
>> 
>> It was bad.  diff-images is too picky and you end up needing to bless
>> new images constantly.  I have decided to not pursue this line of
>> testing any further because it was so unproductive.
> For now, my plan is to run the CI only once a week.
> So efficiency is not my top priority right now. But it will at some point.
>
> I'm trying to figure out which tools is the best for this job:
> Correctness *and* perf testing.
>
>> 
>> What I *am* interested in trying with traces for correctness testing is
>> using a single driver to replay trace keyframes multiple times and make
>> sure the image is invariant.  This could catch a large class of UB in
>> real world applications without needing continuous human intervention.
> So what's happening if an object is not render in all frame?

That would not be something that the tool I want to build could catch,
but also I don't think you'll manage to build a tool to do that that
doesn't involve a lot of human intervention.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

[Eric Anholt]

Rob Clark  writes:

> On Thu, Jun 20, 2019 at 12:26 PM Eric Anholt  wrote:
>
> (tbh I've not really played w/ renderdoc yet.. I should probably do so..)
>
>>   - Mozilla folks tell me that firefox's WebRender display lists can be
>> captured in browser and then replayed from the WR repo under
>> apitrace or rendredoc.
>>
>>   - I tried capturing Mozilla's new Pathfinder (think SVG renderer), but
>> it wouldn't play the demo under renderdoc.
>>
>>   Do you have some apps that should be represented here?
>>
>> - Add microbenchmarks?  Looks like it would be pretty easy to grab
>>   piglit drawoverhead results, not using renderdoc.  Capturing from
>>   arbitrary apps expands the scope of the repo in a way I'm not sure I'm
>>   excited about (Do we do different configs in those apps?  Then we need
>>   config infrastructure.  Ugh).
>>
>> - I should probably add an estimate of "does this overall improve or
>>   hurt perf?"  Yay doing more stats.
>>
>> - I'd love to drop scipy.  I only need it for stats.t.ppf, but it
>>   prevents me from running run.py directly on my targets.
>
> thoughts about adding amd_perfcntr/etc support?  I guess some of the
> perfcntrs we have perhaps want some post-processing to turn into
> usuable numbers, and plenty of them we don't know much about what they
> are other than the name.  But some of them are easy enough to
> understand (like # of fs ALU cycles, etc), and being able to compare
> that before/after shader optimizations seems useful.

I'm not coming up with a good usecase for that, myself -- shader-db
gives me a reasonable proxy for ALU cycles, and we've got wall time for
a frame from this new tool, so perf counters would let me
measure... maybe something like cycles spent in shader including stalls
(think an optimization like GCM where shader-db analysis is unsuitable)
but avoiding the rest of the noise introduced from CPU side costs and
scheduling of jobs onto the GPU?

Running my current perf analysis overnight feels a lot easier than
trying to add configuration to capture specific GPU perf counters to the
tool.  :)

> Also, it would be nice to have a way to extract "slow frames" somehow
> (maybe out of scope for this tool, but related?).. ie. when framerate
> suddenly drops, those are the frames we probably want to look at more
> closely..

Renderdoc lets you capture a series of frames, so I guess you could do
that and pick out your slow one?


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

[Eric Anholt]

Elie Tournier  writes:

> Hi there,
>
> Great topic. For the past few days, I was looking at a CI for Mesa:
> https://gitlab.freedesktop.org/hopetech/tracie
> OK, it's in a very very alpha stage. ;)

I did one of those things using apitrace diff-images in piglit:

https://gitlab.freedesktop.org/mesa/piglit/tree/master/tests/apitrace

https://github.com/anholt/trace-db

It was bad.  diff-images is too picky and you end up needing to bless
new images constantly.  I have decided to not pursue this line of
testing any further because it was so unproductive.

What I *am* interested in trying with traces for correctness testing is
using a single driver to replay trace keyframes multiple times and make
sure the image is invariant.  This could catch a large class of UB in
real world applications without needing continuous human intervention.

> @eric Out of curiosity, did you looked at apitrace or did you go
> straight with renderdoc?

Since I was only looking at perf, I didn't use apitrace (I'd tried to
use it for perf in the past and it was absolutely dominated by trace
loading).  frameretrace would have made apitrace interesting to use for
this, but José blocked merging that.  That makes apitrace pretty dead
from my perspective.

Also, renderdoc's android capture is really nice to use.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] renderdoc-traces: like shader-db for runtime

[Eric Anholt]

Hey folks, I wanted to show you this follow-on to shader-db I've been
working on:

https://gitlab.freedesktop.org/anholt/renderdoc-traces

For x86 development I've got a collection of ad-hoc scripts to capture
FPS numbers from various moderately interesting open source apps so I
could compare-perf them.  I was only looking at specific apps when they
seemed relevant, so it would be easy to miss regressions.

Starting work on freedreno, one of the first questions I ran into was
"does this change to the command stream make the driver faster?".  I
don't have my old set of apps on my debian ARM systems, and even less so
for Chrome OS.  Ultimately, users will be judging us based on web
browser and android app performance, not whatever I've got laying around
on my debian system.  And, I'd love to fix that "I ignore apps unless I
think of them" thing.

So, I've used renderdoc to capture some traces from Android apps.  With
an unlocked phone, it's pretty easy.  Tossing those in a repo (not
shared here), I can then run driver changes past them to see what
happens.  See
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1134 for some
results.

Where is this repo going from here?

- I add a runner for doing frame-to-frame consistency tests.  We could
  catch UB in a lot of circumstances by replaying a few times and making
  sure that results are consistent.  Comparing frames between drivers
  might also be interesting, though for that you would need human
  validation since pixel values and pixels lit will change on many
  shader optimization changes.

- Need to collect more workloads for the public repo:

  - I've tried to capture webgl on Chrome and Firefox on Linux with no
luck. WebGL on ff is supposed to work under apitrace, maybe I could
do that and then replay on top of renderdoc to capture.

  - Mozilla folks tell me that firefox's WebRender display lists can be
captured in browser and then replayed from the WR repo under
apitrace or rendredoc.

  - I tried capturing Mozilla's new Pathfinder (think SVG renderer), but
it wouldn't play the demo under renderdoc.

  Do you have some apps that should be represented here?

- Add microbenchmarks?  Looks like it would be pretty easy to grab
  piglit drawoverhead results, not using renderdoc.  Capturing from
  arbitrary apps expands the scope of the repo in a way I'm not sure I'm
  excited about (Do we do different configs in those apps?  Then we need
  config infrastructure.  Ugh).

- I should probably add an estimate of "does this overall improve or
  hurt perf?"  Yay doing more stats.

- I'd love to drop scipy.  I only need it for stats.t.ppf, but it
  prevents me from running run.py directly on my targets.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: fix _mesa_max_texture_levels for GL_TEXTURE_EXTERNAL_OES

[Eric Anholt]

Marek Olšák  writes:

> From: Marek Olšák 
>
> This helps fix:
> piglit/bin/ext_image_dma_buf_import-sample_yuv -fmt=NV12 -auto
>
> Fixes: d88f3392fff7c6342f3840c4bd8195a1296c2372

Reviewed-by: Eric Anholt 

Apologies, I had only tested with the CTS.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/7] gallium: Add helper to convert PIPE blending to shader_enum style

[Eric Anholt]

Alyssa Rosenzweig  writes:

> Complementing the new API-agnostic shader_enum blending style, we add
> helpers to translate between the two forms. Ideally, we could just use
> PIPE blending directly, but that makes Vulkan support challenging.
>
> Signed-off-by: Alyssa Rosenzweig 
> Cc: Eric Anholt 
> Cc: Kenneth Graunke 

Patch 2-3 are:

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/7] compiler: Add enums for blend state

[Eric Anholt]

Alyssa Rosenzweig  writes:

> We add enums corresponding to (GLES) blend state to shader_enums.h,
> complementing the existing advanced blending enums in the file. This
> allows us to represent blending state in a driver-agnostic, API-agnostic
> way to permit lowering.
>
> Signed-off-by: Alyssa Rosenzweig 
> Cc: Eric Anholt 
> Cc: Kenneth Graunke 
> ---
>  src/compiler/shader_enums.h | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/src/compiler/shader_enums.h b/src/compiler/shader_enums.h
> index ac293af4519..47b1ca01dd6 100644
> --- a/src/compiler/shader_enums.h
> +++ b/src/compiler/shader_enums.h
> @@ -753,6 +753,27 @@ enum gl_advanced_blend_mode
> BLEND_ALL= 0x7fff,
>  };
>  
> +enum blend_func
> +{
> +   BLEND_FUNC_ADD,
> +   BLEND_FUNC_SUBTRACT,
> +   BLEND_FUNC_REVERSE_SUBTRACT,
> +   BLEND_FUNC_MIN,
> +   BLEND_FUNC_MAX,
> +};
> +
> +enum blend_factor
> +{
> +   BLEND_FACTOR_ZERO,
> +   BLEND_FACTOR_SRC_COLOR,
> +   BLEND_FACTOR_DST_COLOR,
> +   BLEND_FACTOR_SRC_ALPHA,
> +   BLEND_FACTOR_DST_ALPHA,
> +   BLEND_FACTOR_CONSTANT_COLOR,
> +   BLEND_FACTOR_CONSTANT_ALPHA,
> +   BLEND_FACTOR_SRC_ALPHA_SATURATE,
> +};

Interesting, I wouldn't have split blend_factor from inverting the
factor.  I'm fine with it, though.

Acked-by: Eric Anholt 


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/7] nir: Add nir_lower_blend pass

[Eric Anholt]

Alyssa Rosenzweig  writes:

>> Logic ops seem... challenging to emulate in the shader.  That shader
>> would need the destination colors in the framebuffer storage format, and
>> I'm not sure that's always possible (maybe?). 
>
> Alright, that's good to know.
>
> I will note that in Midgard, the native hardware ops are to load/store
> the actual framebuffer storage format. As seen later in the series, I
> lower load/store_output to a series of ops converting to/from float and
> the actual format. It's an open-question whether we want actual
> nir_intrinsics for this so the lowering happens in common NIR code and
> then we get fun logic ops and such.
>
>> It might also be fun to add support for GL_AMD_blend_minmax_factor and
>> GL_SGIX_blend_alpha_minmax.  Looking at this lowering pass, it seems
>> like most of the work would be adding tests.
>
> Probably!
>
>> Having all of the lowering related to blending in one place seems like a
>> good idea.
>
> Probably, yes. Also since GLSL IR is, well ;)
>
>> > +/* These structs encapsulates the blend state such that it can be lowered
>> encapsulate
>> > + * cleanly */
>> 
>> */ on its own line.  There's at least one more instance of this below.
>
> Is there, uh, a thing I can stick in my vimrc to get this right?
>
>> Alas, case should be at the same indentation level as switch.
>
> Good to know, thank you.
>
>> Since factor is an enum, I think it's better to not have the default
>> case.  If there's no default case, the compiler will issue a warning if
>> a new enum is added but not handled.
>> 
>> Either way, the break is definitely not necessary.
>
> +1
>
>> { goes on it's own line.
>
> --Wait, that's a rule I actually follow, how'd I mess it up here? :P
>
>> Why?  Without a vectorizer (or even with a vectorizer), it seems like
>> this will generate much worse code.  I guess it's only a few
>> instructions once per shader, so it may not matter... but it's a little
>> surprising especially after going to extra effort to get the blend color
>> as a vector.
>
> Honestly? Since that's how vc4 (scalar) did it and for v1 of this series I was
> more eager to get something passing tests than particularly good. In my
> original implementation (before joining upstream), I did it like this
> and then used nir_opt_vectorize to get it back to something reasonable.
> That's one strategy still. The other option is to try to generate vector
> out of the gate, but that's hard to get right when RGB/alpha can be
> separate (but don't have to be), etc. The logic needed would approach
> just, well, having ALU vectorization... might as well merge the
> vectorize pass at that point...
>
> Suggestions welcome :)

It does seem like we'll want vector some day for panfrost, but make
tests work first and fix perf later (knowing that it's fixable) is fine
with me.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] panfrosti/ci: Initial commit

[Eric Anholt]

Alyssa Rosenzweig  writes:

>> We start by building a container in Docker that contains a suitable
>> rootfs and kernel for the DUT, deqp and all dependencies for building
>> Mesa itself.
>
> Out of curiosity, what's the performance impact of this? If there are no
> changes to the kernel or to deqp (but mesa had a commit somewhere in
> Panfrost space), do we have to rebuild the former two? Does ccache maybe
> pick that up? I'm trying to get a sense for how long it takes between
> pushing a commit and getting a CI answer, and maybe if that can be
> shortened.
>
>> the expectations that are stored
>> in git.
>
> Might it be better to track this outside so we don't pollute mesa with
> changes to that largely autogenerated file? Or I guess that's
> problematic since then we lose branch information / etc.

Hopefully just current expected fails get stored in git.

> Is there an automated way to do this based on the results of LAVA/CI?
>> +  git clone --depth 1 https://github.com/KhronosGroup/VK-GL-CTS.git .   
>> && \
>
> Is this the right repo? I recall getting deqp source from Google's
> servers (Chromium git). I suppose it's the same.

VK-GL-CTS is the official conformance suite, and it includes dEQP.  You
need to use a release tag, or you'll have extra garbage tests expecting
nonstandardized behavior being run.  Same for dEQP master.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gpu/docs: Clarify what userspace means for gl

[Eric Anholt]

"Zhou, David(ChunMing)"  writes:

> Will linux be only mesa-linux? I thought linux is an  open linux.
> Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? 
> reject?
> 2. one hw feature that opengl/amdvlk developers work on that but no mesa
> developers work on, cannot upstream as well?

I believe these questions are already covered by

"+Other userspace is only admissible if exposing a given feature through OpenGL
or
+OpenGL ES would result in a technically unsound design, incomplete driver or
+an implementation which isn't useful in real world usage."

If OpenGL needs the interface, then you need a Mesa implementation.
It's time for you to work with the community to build that or get it
built.  Or, in AMD's case, work with the Mesa developers that you
already employ.

If OpenGL doesn't need it, but Vulkan needs it, then we don't have a
clear policy in place, and this patch doesn't change that.  I would
personally say that AMDVLK doesn't qualify given that as far as I know
there is not open review of proposed patches to the project as they're
being developed.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support

[Eric Anholt]

Marek Olšák  writes:

> On Tue, Apr 23, 2019 at 4:39 PM Mathias Fröhlich 
> wrote:
>
>> Hi,
>>
>> On Tuesday, 23 April 2019 22:23:45 CEST Marek Olšák wrote:
>> > On Tue, Apr 23, 2019 at 4:05 PM Mathias Fröhlich <
>> mathias.froehl...@gmx.net>
>> > wrote:
>> >
>> > > Hi Marek,
>> > >
>> > > On Tuesday, 23 April 2019 20:22:15 CEST Marek Olšák wrote:
>> > > > I'd like to remove swrast from devices. It doesn't work
>> (eglInitialize
>> > > > fails) and I don't think I like swrast there. Any objections?
>> > >
>> > > Yes, how do you guarantee that at least one device can be returned
>> > > in any case? Even if no drm device is found?
>> > > The egl device query extension guarantees that there is at least one
>> > > device available.
>> > > Beside that swrast may make sense for itself, that is the reason
>> > > the swrast device is there.
>> > >
>> >
>> > If no device can be returned, the extension won't be exposed.
>> Yes, I was triggering this solution back in the days. There was (is?) no
>> infrastructure to enable
>> or disable an egl extension just past initialization or at runtime.
>> Finally Emil took the route to add swrast.
>>
>> The longer I saw the swrast device the better It appeared to me.
>> ... from the users point of view.
>>
>> >OR
>> > If there is at least 1 drm device, swrast won't be in the list.
>> >
>> > From my perspective, radeonsi is always in the list and I wouldn't like
>> > swrast to be in the list if radeonsi is in the list.
>>
>> I see - at least I think. But really the swrast device is good as is. I
>> see plenty use cases for that.
>> Having that only present when there is no hardware device makes it less
>> useful.
>>
>
> How is swrast good? How is swrast useful if you have a supported GPU?

EGL has the possibility of finally displacing OSMesa if we can expose
swrast devices.  People doing regression testing of higher-level
software stacks (xserver, servo, etc.) need a consistent rasterizer they
can use regardless of the hardware a developer might happen to have on
their desktop.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Add an ASSERTED macro to use in place of MAYBE_UNUSED?

[Eric Anholt]

Jason Ekstrand  writes:

> All,
>
> I've seen discussions come up several times lately about whether you should
> use MAYBE_UNUSED or UNUSED in what scenario and why do we have two of them
> anyway.  That got me thinking a bit.  Maybe what we actually want instead
> of MAYBE_UNUSED is something like this:
>
> #ifdef NDEBUG
> #define ASSERTED UNUSED
> #else
> #define ASSERTED
> #endif
>
> That way, if you only need a parameter for asserts, you can declare it
> ASSERTED and it won't warn in release builds will still throw a warning if
> you do a debug build which doesn't use it.  Of course, there are other
> times when something is validly MAYBE_UNUSED such as auto-generated code or
> the genX code we use on Intel.  However, this provides additional meaning
> and means the compiler warnings are still useful even after you've
> relegated a value to assert-only.
>
> Thoughts?  I'm also open to a better name; that's the best I could do in 5
> minutes.

We should delete one or the other of the current ones and not have
different names to need to know for the same underlying function
attribute.  I'd prefer deleting MAYBE_UNUSED (UNUSED is less typing and
the name of the underlying attribute), but would go either way.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/6] st/dri: handle emulated YUV texture sampling in query_dma_buf_modifiers

[Eric Anholt]

Lucas Stach  writes:

> The Mesa state tracker will emulate YUV texture sampling for drivers that
> don't support it natively by using multiple R8/RG88 samplers. Teach
> dri2_query_dma_buf_modifiers about this special case.
> This allows clients like GStreamer glupload or Kodi to properly query
> the supported dma-buf import formats, without the need to take a special
> code path for the emulated OES_external texture handling.
>
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/state_trackers/dri/dri2.c | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index f139bd6722b9..4243a00cb38d 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -1358,19 +1358,30 @@ dri2_query_dma_buf_modifiers(__DRIscreen *_screen, 
> int fourcc, int max,
> const struct dri2_format_mapping *map = 
> dri2_get_mapping_by_fourcc(fourcc);
> enum pipe_format format;
>  
> -   if (!map)
> +   if (!map || !pscreen->query_dmabuf_modifiers)
>return false;
>  
> format = map->pipe_format;
>  
> -   if (pscreen->query_dmabuf_modifiers != NULL &&
> -   (pscreen->is_format_supported(pscreen, format, screen->target, 0, 0,
> +   if ((pscreen->is_format_supported(pscreen, format, screen->target, 0, 0,
>   PIPE_BIND_RENDER_TARGET) ||
>  pscreen->is_format_supported(pscreen, format, screen->target, 0, 0,
>   PIPE_BIND_SAMPLER_VIEW))) {
>pscreen->query_dmabuf_modifiers(pscreen, format, max, modifiers,
>external_only, count);
>return true;
> +   } else if (util_format_is_yuv(format) &&
> +  pscreen->is_format_supported(pscreen, PIPE_FORMAT_R8_UNORM,
> +   screen->target, 0, 0,
> +   PIPE_BIND_SAMPLER_VIEW)) {
> +  /* YUV format sampling can be emulated by the Mesa state tracker by
> +   * using multiple R8/RG88 samplers if the driver doesn't support those
> +   * formats natively, so we need a special case here to give a mostly
> +   * accurate answer to the modifiers query.
> +   */
> +  pscreen->query_dmabuf_modifiers(pscreen, PIPE_FORMAT_R8_UNORM, max,
> +  modifiers, external_only, count);
> +  return true;

I think this will report image_external YUV emulation formats even when
the caller specified !external_only.  Add external_only to the condition
here?


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/6] st/dri: fix dri2_from_planar for multiplanar images

[Eric Anholt]

Lucas Stach  writes:

> From: Philipp Zabel 
>
> Fix the gbm_dri_bo_get_handle_for_plane use case by allowing plane > 0
> in dri2_from_planar for images with multiple planes in separate chained
> texture resources.

This looks like a partial fix to me -- the dup will leave the child
image with the whole image's format and dri_components, when it should
be based on the format of the plane, right?

I think this path should probably be weaned off of dup_image.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/6] st/dri: fix dri2_query_image for multiplanar images

[Eric Anholt]

Lucas Stach  writes:

> From: Philipp Zabel 
>
> Images with multiple planes in separate chained texture resources should
> report the correct number of planes.
>
> Signed-off-by: Philipp Zabel 
> ---
>  src/gallium/state_trackers/dri/dri2.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index 510b7f8d04a7..4c8ea485cc70 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -1083,7 +1083,9 @@ static GLboolean
>  dri2_query_image(__DRIimage *image, int attrib, int *value)
>  {
> struct winsys_handle whandle;
> +   struct pipe_resource *tex;
> unsigned usage;
> +   int i;
>  
> if (image->use & __DRI_IMAGE_USE_BACKBUFFER)
>usage = PIPE_HANDLE_USAGE_EXPLICIT_FLUSH;
> @@ -1157,7 +1159,9 @@ dri2_query_image(__DRIimage *image, int attrib, int 
> *value)
>}
>return GL_TRUE;
> case __DRI_IMAGE_ATTRIB_NUM_PLANES:
> -  *value = 1;
> +  for (i = 0, tex = image->texture; i < 4 && tex; tex = tex->next)
> + i++;
> +  *value = i;
>return GL_TRUE;

What's the "< 4" limit for?  Other than that, patch 1-2 are:

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/6] st/dri: allow to create image for formats that only support SV or RT binding

[Eric Anholt]

Michel Dänzer  writes:

> On 2019-04-15 12:57 p.m., Lucas Stach wrote:
>> Am Montag, den 15.04.2019, 12:04 +0200 schrieb Michel Dänzer:
>>> On 2019-04-12 7:33 p.m., Lucas Stach wrote:
 Unconditionally requesting both bindings can lead to premature
 failure to create a valid image.

>> Signed-off-by: Lucas Stach 
 ---
  src/gallium/state_trackers/dri/dri2.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

 diff --git a/src/gallium/state_trackers/dri/dri2.c 
 b/src/gallium/state_trackers/dri/dri2.c
 index efb43c0d7973..510b7f8d04a7 100644
 --- a/src/gallium/state_trackers/dri/dri2.c
 +++ b/src/gallium/state_trackers/dri/dri2.c
 @@ -987,14 +987,23 @@ dri2_create_image_common(__DRIscreen *_screen,
  {
 const struct dri2_format_mapping *map = 
 dri2_get_mapping_by_format(format);
 struct dri_screen *screen = dri_screen(_screen);
 +   struct pipe_screen *pscreen = screen->base.screen;
 __DRIimage *img;
 struct pipe_resource templ;
 -   unsigned tex_usage;
 +   unsigned tex_usage = 0;
  
 if (!map)
    return NULL;
  
 -   tex_usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
 +   if (pscreen->is_format_supported(pscreen, map->pipe_format, 
 screen->target,
 +0, 0, PIPE_BIND_RENDER_TARGET))
 +  tex_usage |= PIPE_BIND_RENDER_TARGET;
 +   if (pscreen->is_format_supported(pscreen, map->pipe_format, 
 screen->target,
 +0, 0, PIPE_BIND_SAMPLER_VIEW))
 +  tex_usage |= PIPE_BIND_SAMPLER_VIEW;
 +
 +   if (!tex_usage)
 +  return NULL;
  
 if (use & __DRI_IMAGE_USE_SCANOUT)
    tex_usage |= PIPE_BIND_SCANOUT;

>>>
>>> Since there are no __DRI_IMAGE_USE_* flags for rendering & sampling, the
>>> expectation does seem to be that both are supported. What happens if an
>>> image is created for a format which only supports sampling, then the
>>> caller attempts rendering to it?
>> 
>> While I agree that the missing flags is a problem, I don't think the
>> expectation that createImage must create something which is both render
>> and sampler compatible holds anymore.
>
> I don't mean "expectation" as in that of any particular application. I
> mean that because the caller cannot yet express that it only wants to
> sample from / render to the image, dri2_create_image_common must assume
> that the image will be used for both.

If it can be used for both, this patch does.  If the format would be
unsupported unless one of the flags is dropped, then it drops that
flag.  This seems right to me.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/6] st/dri: allow to create image for formats that only support SV or RT binding

[Eric Anholt]

Michel Dänzer  writes:

> On 2019-04-12 7:33 p.m., Lucas Stach wrote:
>> Unconditionally requesting both bindings can lead to premature
>> failure to create a valid image.
>> 
>> Signed-off-by: Lucas Stach 
>> ---
>>  src/gallium/state_trackers/dri/dri2.c | 13 +++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>> 
>> diff --git a/src/gallium/state_trackers/dri/dri2.c 
>> b/src/gallium/state_trackers/dri/dri2.c
>> index efb43c0d7973..510b7f8d04a7 100644
>> --- a/src/gallium/state_trackers/dri/dri2.c
>> +++ b/src/gallium/state_trackers/dri/dri2.c
>> @@ -987,14 +987,23 @@ dri2_create_image_common(__DRIscreen *_screen,
>>  {
>> const struct dri2_format_mapping *map = 
>> dri2_get_mapping_by_format(format);
>> struct dri_screen *screen = dri_screen(_screen);
>> +   struct pipe_screen *pscreen = screen->base.screen;
>> __DRIimage *img;
>> struct pipe_resource templ;
>> -   unsigned tex_usage;
>> +   unsigned tex_usage = 0;
>>  
>> if (!map)
>>return NULL;
>>  
>> -   tex_usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
>> +   if (pscreen->is_format_supported(pscreen, map->pipe_format, 
>> screen->target,
>> +0, 0, PIPE_BIND_RENDER_TARGET))
>> +  tex_usage |= PIPE_BIND_RENDER_TARGET;
>> +   if (pscreen->is_format_supported(pscreen, map->pipe_format, 
>> screen->target,
>> +0, 0, PIPE_BIND_SAMPLER_VIEW))
>> +  tex_usage |= PIPE_BIND_SAMPLER_VIEW;
>> +
>> +   if (!tex_usage)
>> +  return NULL;
>>  
>> if (use & __DRI_IMAGE_USE_SCANOUT)
>>tex_usage |= PIPE_BIND_SCANOUT;
>> 
>
> Since there are no __DRI_IMAGE_USE_* flags for rendering & sampling, the
> expectation does seem to be that both are supported. What happens if an
> image is created for a format which only supports sampling, then the
> caller attempts rendering to it?

From OES_EGL_image.txt:

If the GL is unable to specify a texture object using the supplied
eglImageOES  (if, for example,  refers to a multisampled
eglImageOES), the error INVALID_OPERATION is generated.

...

If the GL is unable to create a renderbuffer using the specified
eglImageOES, the error INVALID_OPERATION is generated.  If 
does not refer to a valid eglImageOES object, the error
INVALID_VALUE is generated.

and st_cb_eglimage.c is checking the screen for sampler / rendertarget
support for the images that it looks up.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] panfrost: Track BO lifetime with jobs and reference counts

[Eric Anholt]

Alyssa Rosenzweig  writes:

>> > diff --git a/src/gallium/drivers/panfrost/pan_job.c
>> > b/src/gallium/drivers/panfrost/pan_job.c
>> > index 66a8b0d4b07..6c68575158f 100644
>> > --- a/src/gallium/drivers/panfrost/pan_job.c
>> > +++ b/src/gallium/drivers/panfrost/pan_job.c
>> > @@ -27,6 +27,13 @@
>> >  #include "util/hash_table.h"
>> >  #include "util/ralloc.h"
>> >  
>> > +static void
>> > +remove_from_ht(struct hash_table *ht, void *key)
>> > +{
>> > +struct hash_entry *entry = _mesa_hash_table_search(ht, key);
>> > +_mesa_hash_table_remove(ht, entry);
>> > +}
>> > +
>> 
>> This is the same as _mesa_hash_table_remove_key(), no?
>
> Maybe? I copypasted this from v3d, but maybe we're both duplicating
> code.

hash_table_remove_key() came after my stuff and we didn't refactor the
whole tree for it.

>> Did you mean to leave this #if'ed out?
>
> Yes, job flushing is a lot more complicated / depends on a lot more
> code; I just wanted the stub here for now.
>
>> Why not use pipe_reference instead of open-coding? That helper contains
>> some neat debug-helpers etc...
>
> pipe_reference kind of scares me... Most of the abstractions here are
> based heavily on v3d's; I figure if anholt had a good reason to do it,
> that's good enough for me..

My BO refcounting came from my pre-gallium intel bufmgr stuff.
pipe_reference seems like fine thing to use.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] nir: Add "viewport vector" system values

[Eric Anholt]

Alyssa Rosenzweig  writes:

> While a partial set of viewport system values exist, these are scalar
> values, which is a poor fit for viewport transformations on vector ISAs
> like Midgard (where the vec3 values for scale and offset each need to be
> coherent in a vec4 uniform slot to take advantage of vectorized
> transform math). This patch adds vec3 scale/offset fields corresponding
> to the 3D Gallium viewport / glViewport+depth
>
> Signed-off-by: Alyssa Rosenzweig 
> Cc: Eric Anholt 

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa gallium: use compute shaders for vaapi blit

[Eric Anholt]

Ilia Mirkin  writes:

> Shouldn't this sort of decision be left up to the driver? If the
> driver would like to use CS for blits, fine, but why not let it blit
> in the most optimal way possible and force it to use a compute shader?

Yeah, commit messages require an explanation of why a change is being
made.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] panfrost: Cache index buffer bounds

[Eric Anholt]

Alyssa Rosenzweig  writes:

>> Can you reuse u_vbuf_get_minmax_index()?
>
> From a preliminary read, it didn't look like that did caching?

It doesn't, but the inside of your caching function should probably be
using it.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] panfrost: Cache index buffer bounds

[Eric Anholt]

Alyssa Rosenzweig  writes:

> This code is probably a wholesale duplication of the corresponding code
> in mesa/src/vbo/vbo_minmax_indices.c; we should investigate reusing
> that.

Can you reuse u_vbuf_get_minmax_index()?


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] drm-shim for faking GEM drivers using simulators or noop.

[Eric Anholt]

I've just put up a new repo that I'm hoping to use to enable automatic
shader-db results for various drivers on Gitlab CI merge requests (and
maybe with some more work, delete the simulator backends of vc4 and v3d).

https://gitlab.freedesktop.org/anholt/drm-shim

I've copied a bit of Mesa stuff out for convenience, but that ends up
actually being most of the code in the repo since it's not really that
much work.  Alternatively, I have a branch of most of it, inside of
Mesa, if we wanted to just add it in as one of the tools.

Does anyone have any strong feelings about where it should go?
mesa/mesa, mesa/drm-shim, or anholt/drm-shim?


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/u_transfer_helper: do not call resource_create(..) directly

[Eric Anholt]

Rob Clark  writes:

> On Thu, Mar 14, 2019 at 3:35 PM Eric Anholt  wrote:
>>
>> Rob Clark  writes:
>>
>> > On Fri, Mar 1, 2019 at 10:54 AM Christian Gmeiner
>> >  wrote:
>> >>
>> >> Use u_transfer_helper_resource_create(..) instead which uses the
>> >> resource_create(..) function specified in u_transfer_vtbl.
>> >>
>> >> Signed-off-by: Christian Gmeiner 
>> >> ---
>> >>  src/gallium/auxiliary/util/u_transfer_helper.c | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/src/gallium/auxiliary/util/u_transfer_helper.c 
>> >> b/src/gallium/auxiliary/util/u_transfer_helper.c
>> >> index 14c4d56392d..a5c3c026e71 100644
>> >> --- a/src/gallium/auxiliary/util/u_transfer_helper.c
>> >> +++ b/src/gallium/auxiliary/util/u_transfer_helper.c
>> >> @@ -182,7 +182,7 @@ transfer_map_msaa(struct pipe_context *pctx,
>> >>   .depth0 = 1,
>> >>   .array_size = 1,
>> >> };
>> >> -   trans->ss = pscreen->resource_create(pscreen, );
>> >> +   trans->ss = u_transfer_helper_resource_create(pscreen, );
>> >
>> >
>> > So I *think* the thinking here was to use pscreen->resource_create()
>> > in case there are multiple things the transfer-helper has to deal
>> > with, like MSAA+RGTC..
>> >
>> > (I can't guarantee that actually works.. but that was the reasoning..)
>>
>> So, I believe that pscreen->resource_create should be set to
>> u_transfer_helper_resource_create if you're using u_transfer_helper.
>> freedreno, v3d, iris, panfrost all do this.  vc4 doesn't but that's just
>> a bug that doesn't matter becuase it doesn't do rgtc or z32fs8.
>>
>> If you've wrapped something around pscreen->resource_create's call of
>> u_transfer_helper_resource_create for some reason, then I think you'd
>> still want to have that called from the MSAA map path.
>
> Ahh, good point.. so I guess this change should be fine.  Although
> also not entirely clear about what it is fixing?

What I'm saying is I think the unpatched code is actually best, though.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/u_transfer_helper: do not call resource_create(..) directly

[Eric Anholt]

Rob Clark  writes:

> On Fri, Mar 1, 2019 at 10:54 AM Christian Gmeiner
>  wrote:
>>
>> Use u_transfer_helper_resource_create(..) instead which uses the
>> resource_create(..) function specified in u_transfer_vtbl.
>>
>> Signed-off-by: Christian Gmeiner 
>> ---
>>  src/gallium/auxiliary/util/u_transfer_helper.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_transfer_helper.c 
>> b/src/gallium/auxiliary/util/u_transfer_helper.c
>> index 14c4d56392d..a5c3c026e71 100644
>> --- a/src/gallium/auxiliary/util/u_transfer_helper.c
>> +++ b/src/gallium/auxiliary/util/u_transfer_helper.c
>> @@ -182,7 +182,7 @@ transfer_map_msaa(struct pipe_context *pctx,
>>   .depth0 = 1,
>>   .array_size = 1,
>> };
>> -   trans->ss = pscreen->resource_create(pscreen, );
>> +   trans->ss = u_transfer_helper_resource_create(pscreen, );
>
>
> So I *think* the thinking here was to use pscreen->resource_create()
> in case there are multiple things the transfer-helper has to deal
> with, like MSAA+RGTC..
>
> (I can't guarantee that actually works.. but that was the reasoning..)

So, I believe that pscreen->resource_create should be set to
u_transfer_helper_resource_create if you're using u_transfer_helper.
freedreno, v3d, iris, panfrost all do this.  vc4 doesn't but that's just
a bug that doesn't matter becuase it doesn't do rgtc or z32fs8.

If you've wrapped something around pscreen->resource_create's call of
u_transfer_helper_resource_create for some reason, then I think you'd
still want to have that called from the MSAA map path.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] util: Add a drm_find_modifier helper

[Eric Anholt]

Alyssa Rosenzweig  writes:

> This function is replicated across vc4/v3d/freedreno and is needed in
> Panfrost; let's make this shared code.
>
> Signed-off-by: Alyssa Rosenzweig 
> ---
>  src/util/u_drm.h | 46 ++
>  1 file changed, 46 insertions(+)
>  create mode 100644 src/util/u_drm.h
>
> diff --git a/src/util/u_drm.h b/src/util/u_drm.h
> new file mode 100644
> index 000..d543c9a7543
> --- /dev/null
> +++ b/src/util/u_drm.h
> @@ -0,0 +1,46 @@
> +/*
> + * Copyright © 2014 Broadcom
> + * Copyright (C) 2012 Rob Clark 
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#ifndef U_DRM_H
> +#define U_DRM_H
> +
> +#include 

Maybe add a #include  since you also use bool.

Other than that, the series is:

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: init hash keys with memset(), not designated initializers

[Eric Anholt]

Ilia Mirkin  writes:

> I believe the distinction here is between initializing all the fields
> and using them individually (thus leaving the padding uninitialized),
> vs using the fields to create a structure to hash as a sequence of
> bytes. For the latter, you really need all the memory initialized, not
> just the "valid" parts of the structure. In at least my mind, it's
> fairly well-established that compilers don't always initialize all of
> a structure's underlying bytes, but I also don't have a specific
> instance of that situation I can point to.
>
> For most usage, foo = {0} is fine since you're not hashing the bytes
> but rather accessing the fields directly. But for hashing, you really
> want all the bits initialized.

Gah.  The commit message even said it was about padding, and I failed to
read.  Sorry for the noise, this does seem right.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: init hash keys with memset(), not designated initializers

[Eric Anholt]

Brian Paul  writes:

> On 03/11/2019 04:47 PM, Eric Anholt wrote:
>> Brian Paul  writes:
>> 
>>> Since the compiler may not zero-out padding in the object.
>>> Add a couple comments about this to prevent misunderstandings in
>>> the future.
>>>
>>> Fixes: 67d96816ff5 ("st/mesa: move, clean-up shader variant key 
>>> decls/inits")
>>> ---
>>>   src/mesa/state_tracker/st_atom_shader.c |  9 +++--
>>>   src/mesa/state_tracker/st_program.c | 13 ++---
>>>   2 files changed, 17 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/src/mesa/state_tracker/st_atom_shader.c 
>>> b/src/mesa/state_tracker/st_atom_shader.c
>>> index ac7a1a5..a4475e2 100644
>>> --- a/src/mesa/state_tracker/st_atom_shader.c
>>> +++ b/src/mesa/state_tracker/st_atom_shader.c
>>> @@ -112,7 +112,10 @@ st_update_fp( struct st_context *st )
>>>  !stfp->variants->key.bitmap) {
>>> shader = stfp->variants->driver_shader;
>>>  } else {
>>> -  struct st_fp_variant_key key = {0};
>>> +  struct st_fp_variant_key key;
>>> +
>>> +  /* use memset, not an initializer to be sure all memory is zeroed */
>>> +  memset(, 0, sizeof(key));
>> 
>> Wait, what?  We rely on this form of initialization all over, what's
>> changed?
>
> The question is do all compilers, when presented with
>
> struct st_fp_variant_key key = {0};

You seem to be saying that not all compilers do, but throughout the
compiler we're relying on all compilers doing so.  Can we get some more
information about what compiler you're fixing here?


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: init hash keys with memset(), not designated initializers

[Eric Anholt]

Brian Paul  writes:

> Since the compiler may not zero-out padding in the object.
> Add a couple comments about this to prevent misunderstandings in
> the future.
>
> Fixes: 67d96816ff5 ("st/mesa: move, clean-up shader variant key decls/inits")
> ---
>  src/mesa/state_tracker/st_atom_shader.c |  9 +++--
>  src/mesa/state_tracker/st_program.c | 13 ++---
>  2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_atom_shader.c 
> b/src/mesa/state_tracker/st_atom_shader.c
> index ac7a1a5..a4475e2 100644
> --- a/src/mesa/state_tracker/st_atom_shader.c
> +++ b/src/mesa/state_tracker/st_atom_shader.c
> @@ -112,7 +112,10 @@ st_update_fp( struct st_context *st )
> !stfp->variants->key.bitmap) {
>shader = stfp->variants->driver_shader;
> } else {
> -  struct st_fp_variant_key key = {0};
> +  struct st_fp_variant_key key;
> +
> +  /* use memset, not an initializer to be sure all memory is zeroed */
> +  memset(, 0, sizeof(key));

Wait, what?  We rely on this form of initialization all over, what's
changed?


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] docs: try to improve the Meson documentation

[Eric Anholt]

Eric Engestrom  writes:

> On 2019-03-08 at 03:42, Brian Paul  wrote:
>> Add new Introduction and Advanced Usage sections.
>> Spell out a few more details, like "ninja install".
>> Improve the layout around example commands.
>> Fix grammatical errors and tighten up the text.
>> Explain the --prefix option.
>
> Thanks! I left a couple comments below, but this is:
> Reviewed-by: Eric Engestrom 
>
>> ---
>>  docs/contents.html |   2 +-
>>  docs/meson.html| 138 
>> +++--
>>  2 files changed, 104 insertions(+), 36 deletions(-)
>> 
>> diff --git a/docs/contents.html b/docs/contents.html
>> index 6364776..619ac3d 100644
>> --- a/docs/contents.html
>> +++ b/docs/contents.html
>> @@ -42,8 +42,8 @@
>>  Downloading / Unpacking
>>  Compiling / Installing
>>
>> -Autoconf
>>  Meson
>> +Autoconf 
>> (deprecated)
>>
>>  
>>  Precompiled Libraries
>> diff --git a/docs/meson.html b/docs/meson.html
>> index f21479c..f9ae669 100644
>> --- a/docs/meson.html
>> +++ b/docs/meson.html
>> @@ -17,65 +17,98 @@
>>  Compilation and Installation using Meson
>>  
>>  
>> +  Introduction
>>Basic Usage
>> +  Advanced Usage
>>Cross-compilation and 32-bit 
>> builds
>>  
>>  
>> -1. Basic Usage
>> +1. Introduction
>>  
>> -The Meson build system is generally considered stable and ready
>> -for production
>> +For general information about Meson see the
>> +http://mesonbuild.com/;>Meson website.
>>  
>> -The meson build is tested on Linux, macOS, Cygwin and Haiku, 
>> FreeBSD,
>> +Mesa's Meson build system is generally considered stable 
>> and ready
>> +for production.
>> +
>> +The Meson build of Mesa is tested on Linux, macOS, Cygwin and 
>> Haiku, FreeBSD,
>>  DragonflyBSD, NetBSD, and should work on OpenBSD.
>>  
>> +If Meson is not already installed on your system, you can typically
>> +install it with your package installer.  For example:
>> +
>> +sudo apt-get install meson   # Ubuntu
>> +
>> +or
>> +
>> +sudo dnf install meson   # Fedora
>> +
>> +
>>  Mesa requires Meson >= 0.45.0 to build.
>>  
>>  Some older versions of meson do not check that they are too old and will 
>> error
>>  out in odd ways.
>>  
>>  
>> +You'll also need https://ninja-build.org/;>Ninja.
>> +If it's not already installed, use apt-get or dnf to install
>> +the ninja-build package.
>> +
>> +
>> +2. Basic Usage
>> +
>>  
>>  The meson program is used to configure the source directory and 
>> generates
>>  either a ninja build file or Visual Studio® build files. The latter 
>> must
>> -be enabled via the --backend switch, as ninja is the 
>> default backend on all
>> -operating systems. Meson only supports out-of-tree builds, and must be 
>> passed a
>> +be enabled via the --backend switch, as ninja is the 
>> default
>> +backend on all
>> +operating systems.
>> +
>> +
>> +
>> +Meson only supports out-of-tree builds, and must be passed a
>>  directory to put built and generated sources into. We'll call that 
>> directory
>> -"build" for examples.
>> +"build" here.
>>  
>>  
>> +Basic configuration is done with:
>> +
>>  
>> -meson build/
>> +meson build/
>>  
>>  
>>  
>> -To see a description of your options you can run meson 
>> configure
>> -along with a build directory to view the selected options for. This will 
>> show
>> -your meson global arguments and project arguments, along with their defaults
>> -and your local settings.
>> +This will create the build directory.
>> +If any dependencies are missing, you can install them, or try to remove
>> +the dependency with a Meson configuration option (see below).
>> +
>> +
>> +
>> +To review the options which Meson chose, run:
>>  
>> +
>> +meson configure build/
>> +
>>  
>>  
>> -Meson does not currently support listing options before configure a build
>> -directory, but this feature is being discussed upstream.
>> +Meson does not currently support listing configuration options before
>> +running "meson build/" but this feature is being discussed upstream.
>>  For now, we have a bin/meson-options.py script that prints
>>  the options for you.
>>  If that script doesn't work for some reason, you can always look in the
>>  meson_options.txt file at the root of the project.
>>  
>>  
>> -
>> -meson configure build/
>> -
>> -
>>  
>> -With additional arguments meson configure is used to change
>> -options on already configured build directory. All options passed to this
>> -command are in the form -D "command"="value".
>> +With additional arguments meson configure can be used to change
>> +options for a previously configured build directory.
>> +All options passed to this command are in the form
>> +-D "command"="value".
>
> I know you didn't write this bit, but can I suggest s/command/option/ ?
>
>> +For example:
>>  
>>  
>>  
>> -meson configure build/ -Dprefix=/tmp/install -Dglx=true
>> +meson configure build/ -Dprefix=/tmp/install -Dglx=true
>>  
>>  
>>  
>> @@ -88,33 +121,68 @@ and brackets to represent an empty list 

Re: [Mesa-dev] [PATCH] gallium/u_transfer_helper: do not call resource_create(..) directly

[Eric Anholt]

Christian Gmeiner  writes:

> Use u_transfer_helper_resource_create(..) instead which uses the
> resource_create(..) function specified in u_transfer_vtbl.

I would need to run this through the CTS, as the stacking in
u_transfer_helper is fragile.  What's fixed for you by this patch?


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: Add PIPE_BARRIER_UPDATE_BUFFER and UPDATE_TEXTURE bits.

[Eric Anholt]

Kenneth Graunke  writes:

> The glMemoryBarrier() function makes shader memory stores ordered with
> respect to things specified by the given bits.  Until now, st/mesa has
> ignored GL_TEXTURE_UPDATE_BARRIER_BIT and GL_BUFFER_UPDATE_BARRIER_BIT,
> saying that drivers should implicitly perform the needed flushing.
>
> This seems like a pretty big assumption to make.  Instead, this commit
> opts to translate them to new PIPE_BARRIER bits, and adjusts existing
> drivers to continue ignoring them (preserving the current behavior).
>
> The i965 driver performs actions on these memory barriers.  Shader
> memory stores go through a "data cache" which is separate from the
> render cache and other read caches (like the texture cache).  All
> memory barriers need to flush the data cache (to ensure shader memory
> stores are visible), and possibly invalidate read caches (to ensure
> stale data is no longer visible).  The driver implicitly flushes for
> most caches, but not for data cache, since ARB_shader_image_load_store
> introduced MemoryBarrier() precisely to order these explicitly.
>
> I would like to follow i965's approach in iris, flushing the data cache
> on any MemoryBarrier() call, so I need st/mesa to actually call the
> pipe->memory_barrier() callback.

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver

[Eric Anholt]

Alyssa Rosenzweig  writes:

>> Alyssa: do you see any problem if we change to submit only one atom per
>> ioctl?
>
> I don't think so; aesthetically I don't like the extra kernel traffic,
> but that's not a real concern, and it sounds like that's the correct
> approach anyway.
>
> A big reason we submit together on non-DRM is so we can get the kernel
> to deal with dependency tracking; if we have proper syncobjs/fences,
> that doesn't matter I don't think.
>
>> Guess syncobj refs are akin to GEM handles and fences to dmabuf buffers from
>> the userspace POV?
>
> *tries to figure out what the difference between GEM handles and dmabuf
> buffers*

GEM handles: per-DRM-fd small integer references to your BOs.
Non-refcounted (GEM_CLOSE frees that number).

dmabuf: fd reference to a BO.  May be imported/exported to/from a GEM
handle using the prime interfaces.  Watch out for how it'll hand you
back the same handle for a reimport of a buffer you already have a GEM
handle to!  The fd can be passed over unix domain sockets, which is how
we move references to buffers between processes.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver

[Eric Anholt]

Kristian Høgsberg  writes:

> On Mon, Mar 4, 2019 at 6:29 PM Dave Airlie  wrote:
>>
>> On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg  wrote:
>> >
>> > On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig  
>> > wrote:
>> > >
>> > > > Why aren't we using regular dma-buf fences here? The submit ioctl
>> > > > should be able to take a number of in fences to wait on and return an
>> > > > out fence if requested.
>> > >
>> > > Ah-ha, that sounds like the "proper" approach for mainline. Much of this
>> > > was (incorrectly) inherited from the Arm driver. Thank you for the
>> > > pointer.
>> >
>> > I'm not sure - I mean, the submit should take in/out fences, but the
>> > atom mechanism here sounds more like it's for declaring the
>> > dependencies between multiple batches in a renderpass/frame to allow
>> > the kernel to shcedule them? The sync fd may be a little to heavy
>> > handed for that, and if you want to express that kind of dependency to
>> > allow the kernel to reschedule, maybe we need both?
>>
>> You should more likely be using syncobjects, not fences.
>>
>> You can convert syncobjs to fences, but fences consume an fd which you
>> only really want if inter-device.
>
> Fence fd's are also required for passing through protocol for explicit
> synchronization.

Yeah, but you can get a syncobj from a sync_file fence fd and export a
syncobj's fence to a sync_file.  I've been doing that successfully in
v3d and vc4 for our dependencies in the driver so you don't need
multiple fence types as input/output from the submit ioctl.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/util: Fix off-by-one in box intersection

[Eric Anholt]

Boris Brezillon  writes:

> From: Daniel Stone 
>
> pipe_boxes are x/y + width/height, rather than x0/y0 -> x1/y1. This
> means that (x+width) is not included in the box.
>
> The box intersection check was seemingly written for inclusive regions,
> and would falsely assert that adjacent boxes would overlap.
>
> Fix the off-by-one by being one pixel less greedy.
>
> Signed-off-by: Daniel Stone 
> Signed-off-by: Boris Brezillon 
> ---
>  src/gallium/auxiliary/util/u_box.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_box.h 
> b/src/gallium/auxiliary/util/u_box.h
> index b3f478e7bfc4..ead7189ecaf8 100644
> --- a/src/gallium/auxiliary/util/u_box.h
> +++ b/src/gallium/auxiliary/util/u_box.h
> @@ -161,15 +161,15 @@ u_box_test_intersection_2d(const struct pipe_box *a,
> unsigned i;
> int a_l[2], a_r[2], b_l[2], b_r[2];
>  
> -   a_l[0] = MIN2(a->x, a->x + a->width);
> -   a_r[0] = MAX2(a->x, a->x + a->width);
> -   a_l[1] = MIN2(a->y, a->y + a->height);
> -   a_r[1] = MAX2(a->y, a->y + a->height);
> +   a_l[0] = MIN2(a->x, a->x + a->width - 1);
> +   a_r[0] = MAX2(a->x, a->x + a->width - 1);
> +   a_l[1] = MIN2(a->y, a->y + a->height - 1);
> +   a_r[1] = MAX2(a->y, a->y + a->height - 1);
>  
> -   b_l[0] = MIN2(b->x, b->x + b->width);
> -   b_r[0] = MAX2(b->x, b->x + b->width);
> -   b_l[1] = MIN2(b->y, b->y + b->height);
> -   b_r[1] = MAX2(b->y, b->y + b->height);
> +   b_l[0] = MIN2(b->x, b->x + b->width - 1);
> +   b_r[0] = MAX2(b->x, b->x + b->width - 1);
> +   b_l[1] = MIN2(b->y, b->y + b->height - 1);
> +   b_r[1] = MAX2(b->y, b->y + b->height - 1);
>  
> for (i = 0; i < 2; ++i) {
>if (a_l[i] > b_r[i] || a_r[i] < b_l[i])

All this min/maxing is about trying to find the bounds if width/height
is negative (indicating a flip in blits), right?  So, when width/height
are negative, I think you end up expanding the range instead of
shrinking it like you intended.

(I think the negative width/height thing is a serious misfeature and we
should just insist that pipe_boxes don't have it and fix up blits to
pass the flip state separately)

FWIW, I do definitely think this function should be fixed. It's called
u_box_test_intersection, not u_box_test_intersection_or_adjacency.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] gallium: Implement APPLE_object_purgeable (iris, freedeno, vc4)

[Eric Anholt]

Chris Wilson  writes:

> Quoting Eric Anholt (2019-02-27 02:19:32)
>> Overall, I'm hesitatant to land support for actually doing anything with
>> APPLE_object_purgeable when there are no functional tests of it.  I
>> don't mean to actually have tests that force purging, but at least
>> making sure that we don't accidentally break rendering by having marked
>> things purgeable at all.
>
> For test design you are thinking of a few of the more common operations
> with a purgeable/unpurgeable cycle in between? For each of the purgeable
> objects (i.e. every object type). And from a robustness pov, run through
> with GL_UNDEFINED_APPLE in between, so the objects are discarded before
> attempting to reuse (and gracefully failing).

For example, for the vc4 issue, submitting a draw, marking one of the
buffers involved purgeable, then read back the result of the draw to the
unrelated buffer.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] gallium: Implement APPLE_object_purgeable (iris, freedeno, vc4)

[Eric Anholt]

Chris Wilson  writes:

> A few of the GEM drivers provide matching ioctls to allow control of
> their bo caches. Hook these up to APPLE_object_purgeable to allow
> clients to discard video memory under pressure where they are able to
> fallback to restoring content themselves, e.g. from their own (presumably
> compressed, on disk) caches.
>
> v2: Refactor the repeated resource purging.
>
> Cc: Eric Anholt 
> Cc: Kenneth Graunke 
> Cc: Rob Clark 
> ---
>  .../drivers/freedreno/freedreno_resource.c|  10 ++
>  .../drivers/freedreno/freedreno_screen.c  |   1 +
>  src/gallium/drivers/iris/iris_resource.c  |  10 ++
>  src/gallium/drivers/iris/iris_screen.c|   1 +
>  src/gallium/drivers/vc4/vc4_bufmgr.c  |  15 ++
>  src/gallium/drivers/vc4/vc4_bufmgr.h  |   3 +
>  src/gallium/drivers/vc4/vc4_resource.c|  10 ++
>  src/gallium/drivers/vc4/vc4_screen.c  |   3 +
>  src/gallium/include/pipe/p_defines.h  |   1 +
>  src/gallium/include/pipe/p_screen.h   |  20 +++
>  src/mesa/Makefile.sources |   2 +
>  src/mesa/meson.build  |   2 +
>  src/mesa/state_tracker/st_cb_objectpurge.c| 141 ++
>  src/mesa/state_tracker/st_cb_objectpurge.h|  38 +
>  src/mesa/state_tracker/st_context.c   |   2 +
>  src/mesa/state_tracker/st_extensions.c|   1 +
>  16 files changed, 260 insertions(+)
>  create mode 100644 src/mesa/state_tracker/st_cb_objectpurge.c
>  create mode 100644 src/mesa/state_tracker/st_cb_objectpurge.h

u_screen.c needs an update so that other drivers get the right defaults.

> diff --git a/src/gallium/drivers/vc4/vc4_resource.c 
> b/src/gallium/drivers/vc4/vc4_resource.c
> index c12187d7872..d844c5d888a 100644
> --- a/src/gallium/drivers/vc4/vc4_resource.c
> +++ b/src/gallium/drivers/vc4/vc4_resource.c
> @@ -269,6 +269,15 @@ vc4_texture_subdata(struct pipe_context *pctx,
>box);
>  }
>  
> +static boolean
> +vc4_resource_madvise(struct pipe_screen *pscreen,
> + struct pipe_resource *prsc,
> + boolean dontneed)
> +{
> +struct vc4_resource *rsc = vc4_resource(prsc);
> +return vc4_bo_madvise(rsc->bo, dontneed);
> +}

I think you'd need to flush any readers/writers of the resource.
Otherwise, if outstanding prior rendering using the BO got flushed, the
whole job would -EINVAL instead of rendering.


> +static GLenum
> +st_render_object_purgeable(struct gl_context *ctx,
> +   struct gl_renderbuffer *obj,
> +   GLenum option)
> +{
> +   struct st_renderbuffer *stobj = st_renderbuffer(obj);
> +   return st_resource_purgeable(ctx, stobj->texture, option);
> +}

If you purge a renderbuffer that's a single level of a texture object
with miplevels, I don't think we can madvise the whole resource.

Also be careful with purging just depth of packed depth/stencil.


Overall, I'm hesitatant to land support for actually doing anything with
APPLE_object_purgeable when there are no functional tests of it.  I
don't mean to actually have tests that force purging, but at least
making sure that we don't accidentally break rendering by having marked
things purgeable at all.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nir: add nir_instr_type_tex support to nir_lower_phis_to_scalar()

[Eric Anholt]

Timothy Arceri  writes:

> shader-db results i965 (SKL):
>
> total instructions in shared programs: 13219105 -> 13024761 (-1.47%)
> instructions in affected programs: 1169457 -> 975113 (-16.62%)
> helped: 599
> HURT: 154
>
> total cycles in shared programs: 333968972 -> 324822073 (-2.74%)
> cycles in affected programs: 130032440 -> 120885541 (-7.03%)
> helped: 590
> HURT: 216
>
> total spills in shared programs: 57947 -> 29130 (-49.73%)
> spills in affected programs: 53364 -> 24547 (-54.00%)
> helped: 351
> HURT: 0
>
> total fills in shared programs: 51310 -> 25468 (-50.36%)
> fills in affected programs: 44882 -> 19040 (-57.58%)
> helped: 351
> HURT: 0
> ---
>  src/compiler/nir/nir_lower_phis_to_scalar.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/compiler/nir/nir_lower_phis_to_scalar.c 
> b/src/compiler/nir/nir_lower_phis_to_scalar.c
> index 16001f73685..f6f702bca15 100644
> --- a/src/compiler/nir/nir_lower_phis_to_scalar.c
> +++ b/src/compiler/nir/nir_lower_phis_to_scalar.c
> @@ -74,6 +74,7 @@ is_phi_src_scalarizable(nir_phi_src *src,
>/* A phi is scalarizable if we're going to lower it */
>return should_lower_phi(nir_instr_as_phi(src_instr), state);
>  
> +   case nir_instr_type_tex:
> case nir_instr_type_load_const:
> case nir_instr_type_ssa_undef:
>/* These are trivially scalarizable */

Sounds promising, but I would definitely not describe instr_type_tex as
"trivially scalarizable" -- could you explain what's going on with this
patch?


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] vc4: Fix copy-and-paste fail in backport of NEON asm fixes.

[Eric Anholt]

One of the cpu pointers wasn't marked as read-write, causing gcc to complain:

../src/gallium/drivers/vc4/vc4_tiling_lt.c:181:17: error: output operand 
constraint lacks ‘=’
 __asm__ volatile (

Cc: Emil Velikov 
---

This patch is for the 18.3 branch only

 src/gallium/drivers/vc4/vc4_tiling_lt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/vc4/vc4_tiling_lt.c 
b/src/gallium/drivers/vc4/vc4_tiling_lt.c
index 324a6334668b..167161fdff54 100644
--- a/src/gallium/drivers/vc4/vc4_tiling_lt.c
+++ b/src/gallium/drivers/vc4/vc4_tiling_lt.c
@@ -194,7 +194,7 @@ vc4_store_utile(void *gpu, void *cpu, uint32_t cpu_stride, 
uint32_t cpp)
  * d0-d7.
  */
 "vstm %[gpu], {q0, q1, q2, q3}\n"
-: [cpu] "r"(cpu)
+: [cpu] "+r"(cpu)
 : [gpu] "r"(gpu),
   [cpu_stride]  "r"(cpu_stride)
 : "q0", "q1", "q2", "q3");
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] Mesa 18.3.3 release candidate

[Eric Anholt]

Carsten Haitzler  writes:

> On Mon, 04 Feb 2019 16:31:57 -0800 Eric Anholt  said:
>
>> Carsten Haitzler  writes:
>> 
>> > On Fri, 1 Feb 2019 11:08:07 + Emil Velikov 
>> > said:
>> >
>> >> Hi Carsten,
>> >> 
>> >> On 2019/01/31, Carsten Haitzler wrote:
>> >> > On Wed, 30 Jan 2019 18:33:35 + Emil Velikov
>> >> >  said:
>> >> > 
>> >> > You might want to hold off on this. My bugfix was actually patched out 
>> >> > by
>> >> > partly removing some of it. The void ptr math should never have been
>> >> > there and wasn't in the final patch.
>> >> > 
>> >> > I'm talking about:
>> >> > 
>> >> > +void *cpu2 = cpu + 8;
>> >> > 
>> >> > In 300d3ae8b1445b5060f92c77c0f577f4b7b2c7d6
>> >> > 
>> >> > At least with gcc8 mesa is a dud on Raspberry Pi (can't upload/downlaod
>> >> > textures without crashing) without the fixes. I moved the secondary ptr
>> >> > math into the ASM chunk because the C compiler seemed to just mess up
>> >> > cpu2 ptr content/value for me on gcc8 (it also kept the parameter
>> >> > inputs/outputs cleaner and consistent with other ASM chunks). Keeping
>> >> > this as void ptr math alone is just wrong and asking for trouble and as
>> >> > it unfixed a fix I already had in submitted patches.
>> >> > 
>> >> > Being at FOSDEM I now no longer have access to my OS image with all of
>> >> > this set up to test and won't until next week. I can't dig in and 
>> >> > verify.
>> >> > Without my fixes at all it's a dead man walking with gcc8, and thus Arch
>> >> > Linux is broken entirely on Rpi without it (and has been for a while
>> >> > now).
>> 
>> FWIW, my testing was done on gcc 8.30 on raspberry pi.
>
> I finally have time and am back with my Pi box. This was gcc 8.2.0 that I was
> using.
>
>> I skipped the part of moving the C expression into the asm because it
>> didn't make sense, and appeared in the series before the part that
>> actually fixed the asm clobbers bug, so it (like the .fpu neon part)
>> looked like random hacks.
>
> I did explicitly break just and only that change out. 0004 in the series was
> just that. The log explained compiler bugs prevent calculating the address in 
> C
> (it ends up junk) so moved it to the asm block. That required changing the 
> cpu2
> refs all to be a register instead and add this register to the clobber list, 
> so
> of course the patch was more than just a 2 liner, but it was straightforward.

I'm quite skeptical that it's a compiler bug instead of a bug on our
end.  If we have a bug in our constraints, I want to fix that bug rather
than papering over it such that we just don't tickle it on your
particular compiler/flags combination.  Even if it's a compiler bug, we
should figure it out and report it.

If you don't have the time to figure out the root cause, let's see if I
can.  What compiler flags are you seeing used in your build?  I've been
using piglit's texsubimage to test with various compiler flags to try to
reproduce your issue, and haven't managed to with a debug,
debugoptimized or release build in meson on Mesa master.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] panfrost: Resolve alignment issue on 32-bit

[Eric Anholt]

Alyssa Rosenzweig  writes:

> Signed-off-by: Alyssa Rosenzweig 
> ---
>  src/gallium/drivers/panfrost/pan_blending.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_blending.c 
> b/src/gallium/drivers/panfrost/pan_blending.c
> index 058fb6bda84..a19d048123b 100644
> --- a/src/gallium/drivers/panfrost/pan_blending.c
> +++ b/src/gallium/drivers/panfrost/pan_blending.c
> @@ -333,9 +333,10 @@ panfrost_make_constant(unsigned *factors, unsigned 
> num_factors, const struct pip
>  }
>  }
>  
> -/* We have the constant -- success! */
> +/* We have the constant -- success! Copy it in indirectly (to prevent
> + * alignment issues on some platforms) */
>  
> -*out = constant;
> +memcpy(out, , sizeof(float));
>  return true;

You've got a float *out that's unaligned?  I would recommend a void
pointer if you're breaking the alignment rules.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] kmsro: Silence warning if missing

[Eric Anholt]

Alyssa Rosenzweig  writes:

> Regardless of whether the build uses kmsro, kmsro is the default driver
> descriptor when the static loader is used. Thus, in an edge case where
> the static loader is used, no static targets are loaded, and kmsro is
> not compiled, a spurious warning is printed. There's no harm in
> executing the stub function in this case, but it's not "an error" to not
> have kmsro in the build; the driver missing warning should not printed
> kmsro.
>
> Signed-off-by: Alyssa Rosenzweig 
> Reported-by: Karol Herbst 

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] kmsro: Move DRM entrypoints to shared block

[Eric Anholt]

Alyssa Rosenzweig  writes:

> As kmsro allows an essentially mix-and-match hodgepodge of display
> drivers and renderonly GPUs, it doesn't make sense to couple the display
> driver entrypoint definition with the driver. Instead, we move *all*
> kmsro entrypoints to a shared kmsro block at the end (avoiding clutter
> and distraction since this list may snowball in the future).
>
> v2: Alphabetize driver list.

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] panfrost: Use u_pipe_screen_get_param_defaults

[Eric Anholt]

Alyssa Rosenzweig  writes:

> Switching to the defaults function cleans up pan_screen.h markedly and
> futureproofs for when new PIPE_CAPs are added.
>
> Signed-off-by: Alyssa Rosenzweig 
> ---
>  src/gallium/drivers/panfrost/pan_screen.c | 157 +-
>  1 file changed, 6 insertions(+), 151 deletions(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_screen.c 
> b/src/gallium/drivers/panfrost/pan_screen.c
> index 0e745583940..0fe90db0b0a 100644
> --- a/src/gallium/drivers/panfrost/pan_screen.c
> +++ b/src/gallium/drivers/panfrost/pan_screen.c

> @@ -288,111 +221,33 @@ panfrost_get_param(struct pipe_screen *screen, enum 
> pipe_cap param)
>  return 1;
>  
>  case PIPE_CAP_VIDEO_MEMORY: {
> -/* XXX: Do we want to return the full amount fo system 
> memory ? */
>  uint64_t system_memory;
>  
>  if (!os_get_total_physical_memory(_memory))
>  return 0;
>  
> -if (sizeof(void *) == 4)
> -/* Cap to 2 GB on 32 bits system. We do this because 
> panfrost does
> - * eat application memory, which is quite limited on 
> 32 bits. App
> - * shouldn't expect too much available memory. */
> -system_memory = MIN2(system_memory, 2048 << 20);
> -

This hunk looks out of place in what is otherwise a refactor.

Other than that,

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] kmsro: Move DRM entrypoints to shared block

[Eric Anholt]

Alyssa Rosenzweig  writes:

> As kmsro allows an essentially mix-and-match hodgepodge of display
> drivers and renderonly GPUs, it doesn't make sense to couple the display
> driver entrypoint definition with the driver. Instead, we move *all*
> kmsro entrypoints to a shared kmsro block at the end (avoiding clutter
> and distraction since this list may snowball in the future).
>
> Signed-off-by: Alyssa Rosenzweig 
> ---
>  src/gallium/targets/dri/target.c | 18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/targets/dri/target.c 
> b/src/gallium/targets/dri/target.c
> index 17484ced979..5bd34600f2e 100644
> --- a/src/gallium/targets/dri/target.c
> +++ b/src/gallium/targets/dri/target.c
> @@ -77,21 +77,11 @@ DEFINE_LOADER_DRM_ENTRYPOINT(v3d)
>  
>  #if defined(GALLIUM_VC4)
>  DEFINE_LOADER_DRM_ENTRYPOINT(vc4)
> -#if defined(GALLIUM_KMSRO)
> -DEFINE_LOADER_DRM_ENTRYPOINT(hx8357d)
> -DEFINE_LOADER_DRM_ENTRYPOINT(pl111)
> -#endif
>  #endif
>  
>  #if defined(GALLIUM_PANFROST)
>  DEFINE_LOADER_DRM_ENTRYPOINT(panfrost)
> -#if defined(GALLIUM_KMSRO)
> -DEFINE_LOADER_DRM_ENTRYPOINT(rockchip)
> -DEFINE_LOADER_DRM_ENTRYPOINT(meson)
>  #endif
> -#endif
> -
> -
>  
>  #if defined(GALLIUM_ETNAVIV)
>  DEFINE_LOADER_DRM_ENTRYPOINT(imx_drm)
> @@ -101,3 +91,11 @@ DEFINE_LOADER_DRM_ENTRYPOINT(etnaviv)
>  #if defined(GALLIUM_TEGRA)
>  DEFINE_LOADER_DRM_ENTRYPOINT(tegra);
>  #endif
> +
> +#if defined(GALLIUM_KMSRO)
> +DEFINE_LOADER_DRM_ENTRYPOINT(hx8357d)
> +DEFINE_LOADER_DRM_ENTRYPOINT(pl111)
> +DEFINE_LOADER_DRM_ENTRYPOINT(rockchip)
> +DEFINE_LOADER_DRM_ENTRYPOINT(meson)
> +#endif

Alphabetic sort?  Other than that,

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Remove panfrost from default driver list

[Eric Anholt]

Alyssa Rosenzweig  writes:

> Until the kernel side matures and the full driver is upstreamed, to
> avoid end-user surprises, Panfrost should only be built for the
> adventurous.
>
> Signed-off-by: Alyssa Rosenzweig 

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] Mesa 18.3.3 release candidate

[Eric Anholt]

Carsten Haitzler  writes:

> On Fri, 1 Feb 2019 11:08:07 + Emil Velikov  
> said:
>
>> Hi Carsten,
>> 
>> On 2019/01/31, Carsten Haitzler wrote:
>> > On Wed, 30 Jan 2019 18:33:35 + Emil Velikov 
>> > said:
>> > 
>> > You might want to hold off on this. My bugfix was actually patched out by
>> > partly removing some of it. The void ptr math should never have been there
>> > and wasn't in the final patch.
>> > 
>> > I'm talking about:
>> > 
>> > +void *cpu2 = cpu + 8;
>> > 
>> > In 300d3ae8b1445b5060f92c77c0f577f4b7b2c7d6
>> > 
>> > At least with gcc8 mesa is a dud on Raspberry Pi (can't upload/downlaod
>> > textures without crashing) without the fixes. I moved the secondary ptr 
>> > math
>> > into the ASM chunk because the C compiler seemed to just mess up cpu2 ptr
>> > content/value for me on gcc8 (it also kept the parameter inputs/outputs
>> > cleaner and consistent with other ASM chunks). Keeping this as void ptr
>> > math alone is just wrong and asking for trouble and as it unfixed a fix I
>> > already had in submitted patches.
>> > 
>> > Being at FOSDEM I now no longer have access to my OS image with all of this
>> > set up to test and won't until next week. I can't dig in and verify.
>> > Without my fixes at all it's a dead man walking with gcc8, and thus Arch
>> > Linux is broken entirely on Rpi without it (and has been for a while now).

FWIW, my testing was done on gcc 8.30 on raspberry pi.

I skipped the part of moving the C expression into the asm because it
didn't make sense, and appeared in the series before the part that
actually fixed the asm clobbers bug, so it (like the .fpu neon part)
looked like random hacks.

>> Thus from stable POV, we're safe, since nothing has regressed per se. We will
>> apply the extra patches for the next release.
>> 
>> Thanks
>> Emil
>> 
>> P.S. How did you submit the patches - I cannot see them neither on mesa-dev
>> mailing list nor gitlab MR.
>
> i mailed them to eric as he was listed as the maintainer.

I suggested an MR but said I'd accept mail, since raster didn't seem to
want to use normal channels.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] panfrost: Implement Midgard shader toolchain

[Eric Anholt]

Alyssa Rosenzweig  writes:

>> Looks like you leak the constants?  You could pass ctx->ssa_constants
>> instead of NULL and the allocation would be automatically freed.
>
> Hm, alright. Is there documentation anywhere on how memctx works in
> general?

Top of src/util/ralloc.h?

>> > +nir_foreach_variable(var, >uniforms) {
>> > +if (glsl_get_base_type(var->type) == GLSL_TYPE_SAMPLER) 
>> > continue;
>> > +
>> > +unsigned length = glsl_get_aoa_size(var->type);
>> > +
>> > +if (!length) {
>> > +length = glsl_get_length(var->type);
>> > +}
>> > +
>> > +if (!length) {
>> > +length = glsl_get_matrix_columns(var->type);
>> > +}
>> 
>> This seems suspicious -- I don't have anything like this for my uniforms.
>
> Suspicious indeed... what is the correct way to map, then, without
> allocating a uniform for samplers and other not-real-uniform-uniforms?
> The hardware just wants a vec4 index; NIR mirrors the GLSL; poof?
>
> I think I had troubles there, but I can't recall exactly.

Counting uniforms/attributes is all a confusing mess.  I can confirm
that what I do in v3d works, I just can't explain how without going and
re-studying it.

>> All of this is suggestions for future work.  I'm mostly glad to see the
>> driver coming into the tree at last.  Both patches are:
>> 
>> Acked-by: Eric Anholt 
>
> Thank you! As I mentioned in the other email (to Rob), is there anything
> particular blocking a push into master?

Basically the only thing I have any concern about is allowing
end-user/distro builds of a panfrost_dri.so that doesn't actually work
(so, some day when panfrost.ko shows up upstream, suddenly the loader
starts trying to load this panfrost_dri.so and things break).  For V3D I
had the build disabled on ARM until I had the kernel ABI settled (since
I was doing dev on x86 using a simulator), but I don't have a good
solution if you're doing all your work on ARMs.  Maybe keep it out of
the list of drivers available in meson for now, since you're clearly
carrying out-of-tree code anyway?


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver

[Eric Anholt]

Alyssa Rosenzweig  writes:

>> There's u_pipe_screen_get_param_defaults() that you really want to be
>> using to avoid regressions when people add new pipe caps.  You can get
>> rid of a lot of your switch statement that way, too.
>
> Oh, good to know. Is that newer? I'm pretty sure that whole block was
> copied from vc4 at some point ;)
>
>> We should probably be sticking the kmsro entrypoints in a shared group,
>> since there's nothing specific for the KMS .  Looks like we haven't been
>> doing that, though.
>
> Yeah, I had the same thought, but I didn't want to disrupt other drivers
> yet (since that delays merge due to pinging more people).
>
>> These are both things we can change later.  I'm mostly excited to see
>> you finally in-tree!
>
> ^_^
>
> Should either of the above issues be resolved in a v2 now, or just a
> follow-up patch after merging?

Follow-up, imo.  New drivers have a long awkward period where they
wouldn't pass review the way we would for incremental development, but
continuing to work out-of-tree means rebase pain and losing git history.

(If you have git history out of tree that you'd like to retain when
merging in, I'm happy to try helping with that.  I've done fun git
surgery before)


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] panfrost: Implement Midgard shader toolchain

[Eric Anholt]

2, bany_fnequal4, fbany_neq);
> +ALU_CASE(2, ball_iequal4, iball_eq);
> +ALU_CASE(2, bany_inequal4, ibany_neq);

Looks like instead of encoding components here you could use
nir_op_info->num_inputs?

> +nir_foreach_variable(var, >uniforms) {
> +if (glsl_get_base_type(var->type) == GLSL_TYPE_SAMPLER) 
> continue;
> +
> +unsigned length = glsl_get_aoa_size(var->type);
> +
> +if (!length) {
> +length = glsl_get_length(var->type);
> +}
> +
> +if (!length) {
> +length = glsl_get_matrix_columns(var->type);
> +}

This seems suspicious -- I don't have anything like this for my uniforms.

> +if (ctx->stage == MESA_SHADER_VERTEX) {
> +ctx->varying_nir_to_mdg = _mesa_hash_table_u64_create(NULL);
> +
> +/* First, collect the special varyings */
> +nir_foreach_variable(var, >outputs) {
> +if (var->data.location == VARYING_SLOT_POS) {
> +/* Set position first, always. It takes up 
> two
> + * spots, the latter one is de facto unused 
> (at
> + * least from the shader's perspective), we
> + * just need to skip over the spot*/
> +
> +
> _mesa_hash_table_u64_insert(ctx->varying_nir_to_mdg, 
> var->data.driver_location + 1, (void *) ((uintptr_t) (0 + 1)));
> +ctx->varying_count = 
> MAX2(ctx->varying_count, 2);
> +} else if (var->data.location == VARYING_SLOT_PSIZ) {
> +/* Set point size second (third, see above) 
> */
> +
> _mesa_hash_table_u64_insert(ctx->varying_nir_to_mdg, 
> var->data.driver_location + 1, (void *) ((uintptr_t) (2 + 1)));
> +ctx->varying_count = 
> MAX2(ctx->varying_count, 3);
> +
> +program->writes_point_size = true;
> +}
> +}

Using info.outputs_written might be nicer here.

> +
> +/* Lower vars -- not I/O -- before epilogue */
> +
> +NIR_PASS_V(nir, nir_lower_var_copies);
> +NIR_PASS_V(nir, nir_lower_vars_to_ssa);
> +NIR_PASS_V(nir, nir_split_var_copies);
> +NIR_PASS_V(nir, nir_lower_var_copies);
> +NIR_PASS_V(nir, nir_lower_global_vars_to_local);
> +NIR_PASS_V(nir, nir_lower_var_copies);
> +NIR_PASS_V(nir, nir_lower_vars_to_ssa);
> +NIR_PASS_V(nir, nir_lower_io, nir_var_all, glsl_type_size, 0);

I'm skeptical that this many lower_var_copies() is needed :)

> diff --git a/src/gallium/drivers/panfrost/midgard/midgard_nir_algebraic.py 
> b/src/gallium/drivers/panfrost/midgard/midgard_nir_algebraic.py
> new file mode 100644
> index 00..1727b7
> --- /dev/null
> +++ b/src/gallium/drivers/panfrost/midgard/midgard_nir_algebraic.py

> +algebraic = [
> +(('b2i32', a), ('iand@32', "a@32", 1)),
> +(('isign', a), ('imin', ('imax', a, -1), 1)),

I need to steal your isign.

> +(('fge', a, b), ('flt', b, a)),
> +
> +# XXX: We have hw ops for this, just unknown atm..
> +#(('fsign@32', a), ('i2f32@32', ('isign', ('f2i32@32', ('fmul', a, 
> 0x4380)
> +#(('fsign', a), ('fcsel', ('fge', a, 0), 1.0, ('fcsel', ('flt', a, 0.0), 
> -1.0, 0.0)))
> +(('fsign', a), ('bcsel', ('fge', a, 0), 1.0, -1.0)),

Looks like your fsign never returns 0.0 like it should?


All of this is suggestions for future work.  I'm mostly glad to see the
driver coming into the tree at last.  Both patches are:

Acked-by: Eric Anholt 


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev