Re: Lavapipe license

[Jose Fonseca]

What I've seen done elsewhere is to collate all licenses.  Last time I
checked all components (re)used in mesa had permissive licenses (and this
was done by design.)Even if one ends up including a license of a
component that's not actually used, one is erring on the safe side.

If one stumbles across any restrictive licenses then one would
definitely want to ensure it wasn't actually used (I think this happened in
the past, for example, with code used just for build time, or something
along those lines.)

If one really wanted a precise list of components, the most accurate way
would be to use some sort of file-system tracing tool while running meson
that listed all files touched when building, but it's probably overkill.
Though I'm pretty sure src/glx/ is not used for lavapipe,

Jose


On Tue, Feb 13, 2024 at 10:08 AM George Karpathios 
wrote:

> Hi everyone,
>
> I'd like to bundle Lavapipe's binary that I've built (also contains LLVM
> thanks to static linking) with a commercial application and I'm confused
> regarding which licenses I should include into the product. Reading in
> https://docs.mesa3d.org/license.html, "Different copyrights and licenses
> apply to different components" and "In general, consult the source files
> for license terms." makes me think that I should search into every
> component that Lavapipe uses (how can I figure these out precisely?), is
> that correct? For example, do I need the licenses for LLVM, Main Mesa code,
> Gallium, llvmpipe and more? Additionally, looking inside Lavapipe's source
> files under src/gallium/frontends/lavapipe, I see various license texts
> from RedHat, Intel, AMD, Valve, VMware etc.
>
> I feel a bit overwhelmed as to what's the proper thing to do, so if anyone
> could help me learn how to figure situations like this out, I would be
> really grateful. Thanks in advance.
>
> Best regards,
> George
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

Re: Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")

[Jose Fonseca]

> So far, we've been trying to build those components in terms of the
Vulkan API itself with calls jumping back into the dispatch table to try
and get inside the driver. This is working but it's getting more and more
fragile the more tools we add to that box. A lot of what I want to do with
gallium2 or whatever we're calling it is to fix our layering problems so
that calls go in one direction and we can untangle the jumble. I'm still
not sure what I want that to look like but I think I want it to look a lot
like Vulkan, just with a handier interface.

That resonates with my experience.  For example, Galllium draw module does
some of this too -- it provides its own internal interfaces for drivers,
but it also loops back into Gallium top interface to set FS and rasterizer
state -- and that has *always* been a source of grief.  Having control flow
proceeding through layers in one direction only seems an important
principle to observe.  It's fine if the lower interface is the same
interface (e.g., Gallium to Gallium, or Vulkan to Vulkan as you allude),
but they shouldn't be the same exact entry-points/modules (ie, no
reentrancy/recursion.)

It's also worth considering that Vulkan extensibility could come in hand
too in what you want to achieve.  For example, Mesa Vulkan drivers could
have their own VK_MESA_internal_ extensions that could be used by the
shared Vulkan code to do lower level things.

Jose


On Wed, Jan 24, 2024 at 3:26 PM Faith Ekstrand  wrote:

> Jose,
>
> Thanks for your thoughts!
>
> On Wed, Jan 24, 2024 at 4:30 AM Jose Fonseca 
> wrote:
> >
> > I don't know much about the current Vulkan driver internals to have or
> provide an informed opinion on the path forward, but I'd like to share my
> backwards looking perspective.
> >
> > Looking back, Gallium was two things effectively:
> > (1) an abstraction layer, that's watertight (as in upper layers
> shouldn't reach through to lower layers)
> > (2) an ecosystem of reusable components (draw, util, tgsi, etc.)
> >
> > (1) was of course important -- and the discipline it imposed is what
> enabled to great simplifications -- but it also became a straight-jacket,
> as GPUs didn't stand still, and sooner or later the
> see-every-hardware-as-the-same lenses stop reflecting reality.
> >
> > If I had to pick one, I'd say that (2) is far more useful and
> practical.Take components like gallium's draw and other util modules. A
> driver can choose to use them or not.  One could fork them within Mesa
> source tree, and only the drivers that opt-in into the fork would need to
> be tested/adapted/etc
> >
> > On the flip side, Vulkan API is already a pretty low level HW
> abstraction.  It's also very flexible and extensible, so it's hard to
> provide a watertight abstraction underneath it without either taking the
> lowest common denominator, or having lots of optional bits of functionality
> governed by a myriad of caps like you alluded to.
>
> There is a third thing that isn't really recognized in your description:
>
> (3) A common "language" to talk about GPUs and data structures that
> represent that language
>
> This is precisely what the Vulkan runtime today doesn't have. Classic
> meta sucked because we were trying to implement GL in GL. u_blitter,
> on the other hand, is pretty fantastic because Gallium provides a much
> more sane interface to write those common components in terms of.
>
> So far, we've been trying to build those components in terms of the
> Vulkan API itself with calls jumping back into the dispatch table to
> try and get inside the driver. This is working but it's getting more
> and more fragile the more tools we add to that box. A lot of what I
> want to do with gallium2 or whatever we're calling it is to fix our
> layering problems so that calls go in one direction and we can
> untangle the jumble. I'm still not sure what I want that to look like
> but I think I want it to look a lot like Vulkan, just with a handier
> interface.
>
> ~Faith
>
> > Not sure how useful this is in practice to you, but the lesson from my
> POV is that opt-in reusable and shared libraries are always time well spent
> as they can bend and adapt with the times, whereas no opt-out watertight
> abstractions inherently have a shelf life.
> >
> > Jose
> >
> > On Fri, Jan 19, 2024 at 5:30 PM Faith Ekstrand 
> wrote:
> >>
> >> Yeah, this one's gonna hit Phoronix...
> >>
> >> When we started writing Vulkan drivers back in the day, there was this
> >> notion that Vulkan was a low-level API that directly targets hardware.
> >> Vulkan drivers were these super thin things that just blasted packets
> >> straight into the hardware. What little code w

Re: Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")

[Jose Fonseca]

I don't know much about the current Vulkan driver internals to have or
provide an informed opinion on the path forward, but I'd like to share my
backwards looking perspective.

Looking back, Gallium was two things effectively:
(1) an abstraction layer, that's watertight (as in upper layers shouldn't
reach through to lower layers)
(2) an ecosystem of reusable components (draw, util, tgsi, etc.)

(1) was of course important -- and the discipline it imposed is what
enabled to great simplifications -- but it also became a straight-jacket,
as GPUs didn't stand still, and sooner or later the
see-every-hardware-as-the-same lenses stop reflecting reality.

If I had to pick one, I'd say that (2) is far more useful and practical.
Take components like gallium's draw and other util modules. A driver can
choose to use them or not.  One could fork them within Mesa source tree,
and only the drivers that opt-in into the fork would need to be
tested/adapted/etc

On the flip side, Vulkan API is already a pretty low level HW abstraction.
It's also very flexible and extensible, so it's hard to provide a
watertight abstraction underneath it without either taking the lowest
common denominator, or having lots of optional bits of functionality
governed by a myriad of caps like you alluded to.

Not sure how useful this is in practice to you, but the lesson from my POV
is that *opt-in* reusable and shared libraries are always time well spent
as they can bend and adapt with the times, whereas *no opt-out* watertight
abstractions inherently have a shelf life.

Jose

On Fri, Jan 19, 2024 at 5:30 PM Faith Ekstrand  wrote:

> Yeah, this one's gonna hit Phoronix...
>
> When we started writing Vulkan drivers back in the day, there was this
> notion that Vulkan was a low-level API that directly targets hardware.
> Vulkan drivers were these super thin things that just blasted packets
> straight into the hardware. What little code was common was small and
> pretty easy to just copy+paste around. It was a nice thought...
>
> What's happened in the intervening 8 years is that Vulkan has grown. A lot.
>
> We already have several places where we're doing significant layering.
> It started with sharing the WSI code and some Python for generating
> dispatch tables. Later we added common synchronization code and a few
> vkFoo2 wrappers. Then render passes and...
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024
>
> That's been my project the last couple weeks: A common VkPipeline
> implementation built on top of an ESO-like interface. The big
> deviation this MR makes from prior art is that I make no attempt at
> pretending it's a layered implementation. The vtable for shader
> objects looks like ESO but takes its own path when it's useful to do
> so. For instance, shader creation always consumes NIR and a handful of
> lowering passes are run for you. It's no st_glsl_to_nir but it is a
> bit opinionated. Also, a few of the bits that are missing from ESO
> such as robustness have been added to the interface.
>
> In my mind, this marks a pretty fundamental shift in how the Vulkan
> runtime works, at least in my mind. Previously, everything was
> designed to be a toolbox where you can kind of pick and choose what
> you want to use. Also, everything at least tried to act like a layer
> where you still implemented Vulkan but you could leave out bits like
> render passes if you implemented the new thing and were okay with the
> layer. With the ESO code, you implement something that isn't Vulkan
> entrypoints and the actual entrypoints live in the runtime. This lets
> us expand and adjust the interface as needed for our purposes as well
> as sanitize certain things even in the modern API.
>
> The result is that NVK is starting to feel like a gallium driver. 
>
> So here's the question: do we like this? Do we want to push in this
> direction? Should we start making more things work more this way? I'm
> not looking for MRs just yet nor do I have more reworks directly
> planned. I'm more looking for thoughts and opinions as to how the
> various Vulkan driver teams feel about this. We'll leave the detailed
> planning for the Mesa issue tracker.
>
> It's worth noting that, even though I said we've tried to keep things
> layerish, there are other parts of the runtime that look like this.
> The synchronization code is a good example. The vk_sync interface is
> pretty significantly different from the Vulkan objects it's used to
> implement. That's worked out pretty well, IMO. With as complicated as
> something like pipelines or synchronization are, trying to keep the
> illusion of a layer just isn't practical.
>
> So, do we like this? Should we be pushing more towards drivers being a
> backed of the runtime instead of a user of it?
>
> Now, before anyone asks, no, I don't really want to build a multi-API
> abstraction with a Vulkan state tracker. If we were doing this 5 years
> ago and Zink didn't already exist, one might be able to make an
> 

Re: Advice on modifying Lavapipe to isolate JIT compilation in separate process

[Jose Fonseca]

Perhaps I'm getting confused with the terminology, but I don't think moving 
compilation to a separate process helps here.  IIUC, compilation (as in LLVM IR 
-> x86 code) can happen anywhere, the problem is loading the JITed code (ie, 
make writeable memory executable.)

As mentioned, there are many places this can be done.

If Venus does not suite your needs, the easiest way to achieve this would be to:
- back all buffer/texture memory with shared memory, visible to the 2nd process
- modify gallivm to tell LLVM either spit out .so files, or to use shared memory
- modify gallivm_jit_function to return a wrapper that marshals the call into 
the 2nd process:
  - either a generic C wrapper which can introspect the LLVM IR Function 
arguments
  - or hand written C wrappers for every function prototype returned by 
gallivm_jit_function

- there are also a few places where JIT code refers to host process memory 
addresses explicitly (e.g, util_format_xxx helper functions) which need to be 
handled separately (e.g, by passing these addresses in a structure which can be 
rewritten to match the 2nd process)

Jose


From: mesa-dev  on behalf of Dave 
Airlie 
Sent: Thursday, April 27, 2023 08:39
To: Josh Gargus 
Cc: mesa-dev@lists.freedesktop.org 
Subject: Re: Advice on modifying Lavapipe to isolate JIT compilation in 
separate process

!! External Email

On Thu, 27 Apr 2023 at 15:18, Josh Gargus  wrote:
>
> Thanks for your advice!  I hadn't looked at Venus, but that seems like a very 
> promising place to start.
>
> The other approach feels more approachable now too; it feels like there are 
> less "unknown unknowns", although there are plenty of known unknowns to 
> investigate (address independence was one that was already bugging be before 
> I wrote to this list).

I think it shouldn't be too horrible to work out, another option might
be to abuse the cache somehow, but I think that still needs writable +
executable which probably doesn't help, but stuff should be address
independent as I do write x86 asm programs to the cache and read them
back out, only relocating around the global symbols.

>
> It seems like Venus is the more straightforward approach, so I'm inclined to 
> just go with it.  However, it seems like there would be a performance hit 
> compared to only doing JIT compilation in a separate process.  Do you have a 
> rough sense of the performance hit of serializing everything over Venus?  The 
> answer will depend on the workload, I know.

Yeah I think you'll definitely see a large perf hit than just moving
compilation out to a separate process, I'm not sure of the raw venus
overhead numbers here, someone else might have more information
available.

Dave.

!! External Email: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender.

Re: Increase memory size of Lavapipe device?

[Jose Fonseca]

Sounds good, but on 32-bits processes it's better lavapipe doesn't exceed 2GB, 
to leave enough VA for the process/kernel.

Also, LP_MAX_TEXTURE_SIZE (individual resource size) needs to stay at 2GB.

Jose


From: mesa-dev  on behalf of Mike 
Blumenkrantz 
Sent: Tuesday, April 11, 2023 14:37
To: George Karpathios 
Cc: mesa-dev@lists.freedesktop.org 
Subject: Re: Increase memory size of Lavapipe device?

Hm that should probably query the total available memory on the system. You can 
submit an MR to make that change if you're interested?


Mike

On Tue, Apr 11, 2023 at 9:35 AM George Karpathios 
mailto:gkar...@gmail.com>> wrote:
Hi list,

I'd like to ask how I can increase the memory of the Lavapipe device over 2GB 
that vulkaninfo reports. I didn't find any configuration options or environment 
variables available. Should I just manually change the size property at 
lvp_device.c:1441 and rebuild or is it more complicated? Thanks in advance.

Best regards,
George

Re: Mesa3D crash reporting

[Jose Fonseca]

This is on Windows + WSL?  Or native Windows?

Either way, to record OpenGL calls you should look into 
https://apitrace.github.io/  .  No source code modification necessary.

It should record all calls up to (and including) the call that triggered the 
crash.   But if llvmpipe works better, I recommend recording the calls with it 
so developers have the full trace past the crash.

Once you have that, you should be able to provide the trace in an bug report so 
D3D12 driver developers can look into it.

Jose


From: mesa-dev  on behalf of bishop 
bishop 
Sent: Wednesday, April 5, 2023 10:10
To: mesa-dev@lists.freedesktop.org 
Subject: Mesa3D crash reporting

Hi everyone,
   we integrated Mesa3D to our software (CAD application) and we have pretty 
often crashes with the D3D12 driver. Only LLVM pipe driver seems to be stable 
enough. It is virtually impossible to extract OpenGL calls manually as we are 
using external library which wraps OpenGL calls and we don't have access to its 
source code. Is it possible to somehow instruct Mesa3D to record all the OpenGL 
calls with the input to those calls (including the buffers, shaders, etc.)? The 
best would be if Mesa3D can output directly a c++ code with the OpenGL calls 
which can be started up to the point of the crash.

We are using Mesa3D 22.3.3 but also the latest 23.0.1 crashes in the same file 
with nullptr access.

Lubomir Kovac

Re: Migration to ORC JIT for llvmpipe to run on RISC-V

[Jose Fonseca]

My reading of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17801 
also is that adding a meson option is indeed the only thing required to get 
this going.

I don't know if the submitter, Alex Fan, is or plans to work on the MR, nor 
anyone else.  From what you described, I think the best way is for you to 
comment on the MR, offer to help, and get it done if Alex isn't working on it, 
or does not reply.

Jose


From: mesa-dev  on behalf of 
abel.berna...@gmail.com 
Sent: Wednesday, March 1, 2023 16:10
To: mesa-dev@lists.freedesktop.org 
Subject: Migration to ORC JIT for llvmpipe to run on RISC-V

!! External Email
Dear mesa developers,

I am trying to run mesa with llvmpipe on a RISC-V platform, without success. 
This is needed in order to get some performance figures for the RISC-V Graphics 
SIG.

By default llvmpipe is using MCJIT and crashes on 
lp_build_create_jit_compiler_for_module because MCJit does not support RISC-V.

Seems like MCJIT is deprecated and it is not going to accept new architectures, 
so llvmpipe will never run on RISC-V unless ported to ORC JIT. I see there is 
already a merge request for migrating llvmpipe from the deprecated MCJIT to the 
new ORC JIT:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17801

My understanding is that the code is good for merging in a disabled state 
(rather than enabled by default). However the merge is gated by the fact that a 
meson build option is still missing.

Do the mesa developers need help with this? I could try to add the missing 
option myself if that helps, as this task is critical for supporting basic 
graphics on RISC-V. Let me know what RISC-V can do to help.

Regards.

!! External Email: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender.

Re: LLVM-pipe: most powerful instructions set ;)

[Jose Fonseca]

Trying to combine two OpenGL implementations it's technically difficult.  
Furthermore one might thing combining two implementations gives the best of 
both, but easily gives the worst of both worlds, because there's overhead 
moving data between them.

Image the worst case scenario: draw on driver A, copy data to driver B, draw on 
driver B, copy data to driver A.  One might devise a heuristic to avoid 
switching so often, but the end result would end being the bulk of the 
rendering beind done on the most capable drvier (llvmpipe in this case), so not 
much better than always using llvmpipe.


This is why technologies like NVIDIA SLI which divide the work across multiple 
identical GPUs tend to split the work in a granular fashion, like whole frames 
(GPU 1 draws frame 2*N, GPU 2 draws frame 2*N + 1).

Furthermore, mixing different implementations easily leads to artifacts, like 
depth fighting, overlapped geometry or gaps between, because 3D APIs 
specification have somewhat  lax rules about rasterization, and float 
conversion.

Honestly, it's more effective to buy a more modern device.

Jose



From: mesa-dev  on behalf of 
t...@profit-grand.ru 
Sent: Tuesday, November 15, 2022 12:48
To: mesa-dev@lists.freedesktop.org 
Subject: LLVM-pipe: most powerful instructions set ;)

!! External Email

First, thanks for saving my day. Software renderer works way faster than
no renderer at all :)

But there are an "instruction set" which is way faster than the MMX or
SSE sets: it's an existing OpenGL 2.0 driver which is not sufficient in
most cases, because at least 3.0 is required nowadays.

Of course, it's not literally an instruction set, but a source of
additional computing power for basic operations (assuming advanced
operations are not supported by the GPU, making LLVM-pipe necessary for
such systems).

So, the actual question is:

Can LLVM-pipe somehow support (today or in future versions) a "bridge
mode", relying on a different OpenGL driver for basic operations
(supported by some ancient GPU) and closing a gap between that driver
and the required OpenGL version it's usual way, by the state-of-art
software renderer?

It's also somewhat related to my OGLOED driver idea (see my Github), the
difference is "bridge mode" is local, OGLOED is not. But there are some
diagrams which can help understanding my question :)


!! External Email: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender.

Re: Enable OpenGL software rendering on macOS

[Jose Fonseca]

I'm not sure exactly what Homebrew provides, and I'm not able to investigate it 
now.

Yes, using Mesa software rendering to fill the void left by Opengl deprecation 
makes some sense.   But note is still software rendering, not GPU accelerated.  
And one needs to consider the x86 -> arm.

You could consider somehow integrating jogl with osmesa -- offscreen rendering 
-Mesa -- which builds and runs pretty much anywhere Mesa builds -- thereby 
bypassing the headaches of integrating with mac specifics technologies such as 
CGL and Cocoa

There are also other alternatives with considering, such as 
https://moltengl.com/moltengl/


Jose

Get Outlook for Android<https://aka.ms/AAb9ysg>

From: Martin Pernollet 
Sent: Monday, May 2, 2022 1:31:43 AM
To: Jose Fonseca 
Cc: mesa-dev@lists.freedesktop.org 
Subject: Re: Enable OpenGL software rendering on macOS


⚠ External Email

Hi Jose,

Many thanks for your answer.

JOGL classes enabling GL binding macOS all refer to CGL, so yes, I think I want 
to rely on CGL (there is however in JOGL a couple of classes allowing to work 
with X11, but they're used on Linux only).

I can't access the Apple M1 on which I built Mesa right now, but homebrew on 
another macOS provides libGL and not libGLX.


ls /usr/local/Cellar/mesa/21.1.2/lib

dri libGL.dylib libGLESv1_CM.dylib libGLESv2.dylib libglapi.dylib

libGL.1.dylib libGLESv1_CM.1.dylib libGLESv2.2.dylib libglapi.0.dylib pkgconfig


One motivation for enabling Mesa on macOS is actually the deprecated status of 
OpenGL. I would expect this software implementation of GL to simply provide an 
image to be copied to a native window/frame, without having to rely on CGL. 
Hence, one could continue working with simple OpenGL even if macOS doesn't 
provide such API.

Does it sound reasonable?

Martin




Envoyé avec la messagerie sécurisée 
ProtonMail<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotonmail.com%2F=05%7C01%7Cjfonseca%40vmware.com%7Ccf822d69b6584b99c2cf08da2c163472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637870771135623243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=6Z%2F57xR0N3IsaozWf4yw1m26WsR9%2BgZthncH5LSlDqA%3D=0>.

--- Original Message ---
Le vendredi 29 avril 2022 à 16:08, Jose Fonseca  a écrit :

The difficulty with OpenGL on macOS is that all driver interfaces are both 
undocumented and deprecated.


If you want to override the system OpenGL, you can use apitrace code as 
reference.  There are two approaches:

  1.  DYLD_FRAMEWORK_PATH  
https://github.com/apitrace/apitrace/blob/master/cli/cli_trace.cpp<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapitrace%2Fapitrace%2Fblob%2Fmaster%2Fcli%2Fcli_trace.cpp=05%7C01%7Cjfonseca%40vmware.com%7Ccf822d69b6584b99c2cf08da2c163472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637870771135623243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=waB1FKc7Gn18GlUCLfMdD6Nz4wLebDjWx4Yie3JOKHc%3D=0>
  2.  DYLD_INSERT_LIBRARIES 
https://github.com/apitrace/apitrace/tree/dyld-interpose<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapitrace%2Fapitrace%2Ftree%2Fdyld-interpose=05%7C01%7Cjfonseca%40vmware.com%7Ccf822d69b6584b99c2cf08da2c163472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637870771135623243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=BTTHs0fiFhz0NYc3UGY2rd9R25Ak%2FFwZ8paNMOFUBfQ%3D=0>
 (experimental branch)


AFAIK, Mesa build for macOS generates a ibGLX which depends on X11, which is 
probably not what you want.  You want to use Mesa for macOS apps which use CGL 
as opposed to GLX, right?


So, if one wants to have a SW renderer on macOS with llvmpipe without depending 
on X11, then one would need to implement:

  *   a new Gallium 
frontend<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Ftree%2Fmain%2Fsrc%2Fgallium%2Ffrontends=05%7C01%7Cjfonseca%40vmware.com%7Ccf822d69b6584b99c2cf08da2c163472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637870771135623243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=ZwSCisd3BxsnoFrHoB5HiWC4FSNf%2BZoooSIUZtCA8us%3D=0>
 that implements CGL API (equivalent to the WGL frontend that exists for 
Windows)
  *   a new SW renderer 
winsys<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Ftree%2Fmain%2Fsrc%2Fgallium%2Fwinsys=05%7C01%7Cjfonseca%40vmware.com%7Ccf822d69b6584b99c2cf08da2c163472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637870771135623243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=LbCV6VokVNeXv8g3%2BzYI6oZWZ0Esq3GomTfuZC0pV0Y%3D=0>
 th

Re: Enable OpenGL software rendering on macOS

[Jose Fonseca]

The difficulty with OpenGL on macOS is that all driver interfaces are both 
undocumented and deprecated.


If you want to override the system OpenGL, you can use apitrace code as 
reference.  There are two approaches:

  1.  DYLD_FRAMEWORK_PATH  
https://github.com/apitrace/apitrace/blob/master/cli/cli_trace.cpp
  2.  DYLD_INSERT_LIBRARIES 
https://github.com/apitrace/apitrace/tree/dyld-interpose (experimental branch)


AFAIK, Mesa build for macOS generates a ibGLX which depends on X11, which is 
probably not what you want.  You want to use Mesa for macOS apps which use CGL 
as opposed to GLX, right?


So, if one wants to have a SW renderer on macOS with llvmpipe without depending 
on X11, then one would need to implement:

  *   a new Gallium 
frontend
 that implements CGL API (equivalent to the WGL frontend that exists for 
Windows)
  *   a new SW renderer 
winsys 
that draws pixels to Cocoa window somehow (equivalent to the GDI winsys that 
draws to a Windows GDI surface)

It's not a matter of just integrating existing components together -- there's 
lot of new code that would be need here -- I'd reckon 2 months for somebody 
familiar with Mesa/macOS, 6 - 12 months for somebody more novice.  And let's be 
frank, given mac deprecation of OpenGL and migration away from Intel to Arm, 
the usefulness of this in the long term is dubious.


Jose


From: mesa-dev  on behalf of Martin 
Pernollet 
Sent: Friday, April 29, 2022 12:32
To: mesa-dev@lists.freedesktop.org 
Subject: Enable OpenGL software rendering on macOS


⚠ External Email

TLDR : I failed using Mesa software rendering on macOS. I am looking for advice 
to invoke mesa's libGL.dylib without relying on macOS's system GL.


Hi everyone,

I am building (java) software involving Mesa for CPU rendering. I use CPU 
rendering as fallback when JOGL (OpenGL binding for Java) fail to use the GPU 
natively. This is sometime the case for old Linux distributions, this will 
certainly be frequent on macOS in the future due to Apple's OpenGL deprecation.

Mesa CPU rendering is working great on Ubuntu (by enabling 
LIBGL_ALWAYS_SOFTWARE=true) and Windows (by simply loading Mesa's DLL instead 
of system DLL, no need to ask for software mode).

I however thrive to use Mesa's software rendering on macOS for the following 
reasons

  *   Spying dynamic library load sequence shows that whenever Mesa's 
libGL.dylib is loaded, Apple Metal and libGL.dylib are loaded before, even when 
using DYLD tricks to ensure Mesa get loaded before any other library (except 
the Java VM) [1] Someone says that Mesa's macOS implementation relies on system 
GL [4]. I noticed that when enabling LIBGL_ALWAYS_SOFTWARE=true, this activates 
Apple software rendering but not Mesa's software rendering [5]. I wonder how I 
could avoid this and use a pure Mesa's OpenGL implementation in this situation.
  *   When getting out of the java World
 *   Running a pre-built glxgear/glxinfo installed through MacPorts only 
allows using Apple's libGL.dylib but not Mesa's libGL.dylib [2].
 *   Building glxinfo myself by linking explicitely to Mesa's GL + X11 lead 
to an X11 error that I am not able to depict [3].

This has been discussed already on Khronos community [1] but I have no clue how 
to go further. I hope some experts here can help me solve this!

Thanks in advance,

Martin

[1] 
https://community.khronos.org/t/failing-to-load-mesa3d-on-macos-instead-of-macos-provided-opengl-library/108408
[2] 
https://community.khronos.org/t/failing-to-load-mesa3d-on-macos-instead-of-macos-provided-opengl-library/108408/14
[3] 

Re: revenge of CALLOC_STRUCT

[Jose Fonseca]

I believe that as long as the CALLOC_STRUCT continue to get paired with right 
FREE call (or equivalent if these get renamed) either way should work for us.  
Whatever option proposed gets followed, there's a risk these can get out of 
balanced, but the risk seems comparable.


For context, IIRC, the main reason these macros remain useful for VMware is the 
sad state of memory debugging tools on Windows.  AFAICT, best hope of one day 
deprecating this would be use AddressSanitizer, which is supported on MSVC [1], 
but unfortunately not yet on MinGW w/ GCC [2], and we rely upon a lot for 
day-to-day development, using Linux cross-compilation.  Using MinGW w/ Clang 
cross compiler seems be a way to overcome this difficulty, but that too was 
still in somewhat experimental state when I last tried it.


Jose

[1] 
https://devblogs.microsoft.com/cppblog/asan-for-windows-x64-and-debug-build-support/
[2] 
https://stackoverflow.com/questions/67619314/cannot-use-fsanitize-address-in-mingw-compiler

From: Dave Airlie 
Sent: Wednesday, December 22, 2021 22:35
To: mesa-dev ; Jose Fonseca 
; Brian Paul 
Subject: revenge of CALLOC_STRUCT

Hey,

Happy holidays, and as though to consider over the break,

We have the vmware used MALLOC/FREE/CALLOC/CALLOC_STRUCT wrappers used
throughout gallium.

We have ST_CALLOC_STRUCT in use in the mesa state tracker, not used in gallium.

Merging the state tracker into mesa proper, and even prior to this a
few CALLOC_STRUCT have started to leak into src/mesa/*.

Now I don't think we want that, but CALLOC_STRUCT is a genuinely
useful macro on it's own,
I'm considering just defined a calloc_struct instead for the
non-gallium use that goes with malloc/calloc/free.

Any opinions, or should mesa just get u_memory.h support for Xmas?

Dave.

Re: [Mesa-dev] Merge blocked

[Jose Fonseca]

I see.  Got it: just use marge-bot then.

Jose


From: Rob Clark 
Sent: Tuesday, September 21, 2021 16:13
To: Jose Fonseca 
Cc: Gert Wollny ; ML mesa-dev 

Subject: Re: [Mesa-dev] Merge blocked

Please don't merge or push directly, that will interfere with
marge-bot when it's trying to merge someone else's MR

BR,
-R

On Tue, Sep 21, 2021 at 7:56 AM Jose Fonseca  wrote:
>
> Hi Gert,
>
> > I can understand your frustration with the flaky tests,
>
> My frustration comes as much from the Gitlab config as from the flaky tests.
>
> But you have a point: if tests weren't flaky this certainly wouldn't be much 
> of a problem, and filing bugs is probably the best course of action to avoid 
> them.
>
> > but I'm sure you know that having a CI is place helps a lot to not break 
> > most of the code, so merging without having to go through the CI is not 
> > really an option, even if we are all sensible adults.
>
> I don't follow the logic.  Anybody with commit access can push from git 
> command line bypassing any pipeline checks.  We're already relying upon 
> folks' judgment to use it only when it makes sense (e.g, crossporing commits, 
> etc.)  I don't see why having a UI button to automate makes a difference.
>
> Reassigning to marge-bot is easy enough, but IIUC that causes all pipeline 
> stages (even those which were successful) to be repeated.  I feel that's 
> wasteful (not just money, but also energy.)  Allowing one to Rebase + Merge 
> on one click (like GitHub allows) would be more efficient IMHO.
>
> Anyway, for good or worse, I don't commit to Mesa as much as I used to, so 
> this doesn't affect me nearly as much as others.  Even though I believe 
> allowing to merge without pipeline object would be an improvement, if 
> everybody else is happy with the status quo, then don't mind me.
>
> Jose
>
> ____
> From: Gert Wollny 
> Sent: Tuesday, September 21, 2021 15:32
> To: Jose Fonseca ; ML mesa-dev 
> 
> Subject: Re: [Mesa-dev] Merge blocked
>
> Hello Jose,
>
> On Tue, 2021-09-21 at 11:48 +, Jose Fonseca wrote:
> > Why doesn't Gilab allow one to merge manually?
> >
> > See 
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F12940data=04%7C01%7Cjfonseca%40vmware.com%7Cb6fbf5ac91d040c7c77208d97d11be2a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637678337431351753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=4OWuhOPqIIq3XVMR3yk5y1i78usNbQ6XdtEfecIERts%3Dreserved=0:
> >
> >  * Marge-bot failed to merge the PR due to 2 flaky tests, completely
> > unrelated to the commits in question.
>
> I can understand your frustration with the flaky tests, but I'm sure
> you know that having a CI is place helps a lot to not break most of the
> code, so merging without having to go through the CI is not really an
> option, even if we are all sensible adults.
>
> Maybe we all should just file bugs when we see a flaky test, so that
> those get flagged accordingly by the developers responsible for the
> related drivers.
>
> >
> >  * I manually retried the failed tests, and they all passed, but
> > still Gitlab refused to allow to merge: it said I needed to rebase.
> This is, because Marge merged some other MR between the time you
> rebased the last time. Since the pre-merge CI was added and before
> Marge was introduced, this actually happened quite regularly: Press the
> Merge-when-pipeline-succeeds button and fail, because some other merge
> request was already in the pipeline and got merged before your pipeline
> finished.
> However, nowadays you don't need to rebase yourself, once you assign
> the MR to Marge and she will do that for you when she starts to handle
> your merge request.
>
> >  * I rebased, but still Gitlab refused to merge: now it expects the
> > pipelines to be runagain!
> I'm really sorry for your frustration, but if you're sure that the
> merge failed only because if flaky tests, then simply reassigning the
> MR to Marge will do.
>
> > Is it really necessary to go to git command line to get a PR
> > merged!?  (I was forced to do so 2-3 times now, but it's a hassle.)
> No, it is not necessary, because Marge will do that for you, once you
> assign the MR to her.
>
> > Or run pipelines over and over until one eventually succeeds?
> This is only a problem because of the flaky tests, and yes, we should
> do something about this.
>
> > Sorry for the rant, but I didn't notice anybody else complain.  Am I
> > the only bothered here?  Or is there a better way here I don't know
> > of?
> As you sure have understood at this point, the answer is "Assign to
> Marge" ;)
>
> Best regards,
> Gert
>
>

Re: [Mesa-dev] Merge blocked

[Jose Fonseca]

Hi Gert,

> I can understand your frustration with the flaky tests,

My frustration comes as much from the Gitlab config as from the flaky tests.

But you have a point: if tests weren't flaky this certainly wouldn't be much of 
a problem, and filing bugs is probably the best course of action to avoid them.

> but I'm sure you know that having a CI is place helps a lot to not break most 
> of the code, so merging without having to go through the CI is not really an 
> option, even if we are all sensible adults.

I don't follow the logic.  Anybody with commit access can push from git command 
line bypassing any pipeline checks.  We're already relying upon folks' judgment 
to use it only when it makes sense (e.g, crossporing commits, etc.)  I don't 
see why having a UI button to automate makes a difference.

Reassigning to marge-bot is easy enough, but IIUC that causes all pipeline 
stages (even those which were successful) to be repeated.  I feel that's 
wasteful (not just money, but also energy.)  Allowing one to Rebase + Merge on 
one click (like GitHub allows) would be more efficient IMHO.

Anyway, for good or worse, I don't commit to Mesa as much as I used to, so this 
doesn't affect me nearly as much as others.  Even though I believe allowing to 
merge without pipeline object would be an improvement, if everybody else is 
happy with the status quo, then don't mind me.

Jose


From: Gert Wollny 
Sent: Tuesday, September 21, 2021 15:32
To: Jose Fonseca ; ML mesa-dev 

Subject: Re: [Mesa-dev] Merge blocked

Hello Jose,

On Tue, 2021-09-21 at 11:48 +, Jose Fonseca wrote:
> Why doesn't Gilab allow one to merge manually?
>
> See 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F12940data=04%7C01%7Cjfonseca%40vmware.com%7C93aedc8ac8244272385008d97d0c9cfa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637678315394314865%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=pIjQSUjrU7cCePEsmpcZ7qbdCFFhxZn0y3S7qSS8s7s%3Dreserved=0:
>
>  * Marge-bot failed to merge the PR due to 2 flaky tests, completely
> unrelated to the commits in question.

I can understand your frustration with the flaky tests, but I'm sure
you know that having a CI is place helps a lot to not break most of the
code, so merging without having to go through the CI is not really an
option, even if we are all sensible adults.

Maybe we all should just file bugs when we see a flaky test, so that
those get flagged accordingly by the developers responsible for the
related drivers.

>
>  * I manually retried the failed tests, and they all passed, but
> still Gitlab refused to allow to merge: it said I needed to rebase.
This is, because Marge merged some other MR between the time you
rebased the last time. Since the pre-merge CI was added and before
Marge was introduced, this actually happened quite regularly: Press the
Merge-when-pipeline-succeeds button and fail, because some other merge
request was already in the pipeline and got merged before your pipeline
finished.
However, nowadays you don't need to rebase yourself, once you assign
the MR to Marge and she will do that for you when she starts to handle
your merge request.

>  * I rebased, but still Gitlab refused to merge: now it expects the
> pipelines to be runagain!
I'm really sorry for your frustration, but if you're sure that the
merge failed only because if flaky tests, then simply reassigning the
MR to Marge will do.

> Is it really necessary to go to git command line to get a PR
> merged!?  (I was forced to do so 2-3 times now, but it's a hassle.)
No, it is not necessary, because Marge will do that for you, once you
assign the MR to her.

> Or run pipelines over and over until one eventually succeeds?
This is only a problem because of the flaky tests, and yes, we should
do something about this.

> Sorry for the rant, but I didn't notice anybody else complain.  Am I
> the only bothered here?  Or is there a better way here I don't know
> of?
As you sure have understood at this point, the answer is "Assign to
Marge" ;)

Best regards,
Gert

[Mesa-dev] Merge blocked

[Jose Fonseca]

Why doesn't Gilab allow one to merge manually?

See https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12940:


  *   Marge-bot failed to merge the PR due to 2 flaky tests, completely 
unrelated to the commits in question.

  *   I manually retried the failed tests, and they all passed, but still 
Gitlab refused to allow to merge: it said I needed to rebase.

  *   I rebased, but still Gitlab refused to merge: now it expects the 
pipelines to be run again!

  *   I've reassigned to marge-bot. But who knows if history won't repeat.


It seems a waste of developer time and computer resources.

Can't Gitlab be configured to reflect the fact we are all sensible adults here, 
and allow one to manually merge through the UI?

Is it really necessary to go to git command line to get a PR merged!?  (I was 
forced to do so 2-3 times now, but it's a hassle.)  Or run pipelines over and 
over until one eventually succeeds?


Why is something as easy as merging a PR is made so hard and wasteful!?


Sorry for the rant, but I didn't notice anybody else complain.  Am I the only 
bothered here?  Or is there a better way here I don't know of?


Jose

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Jose Fonseca]

I've seen other projects successfully leveraging git submodules for including 
3rd party code without vendoring in the stricter sense.  I don't have direct 
experience doing so myself yet, but I hope one day to move apitrace towards 
this.  (Apitrace bundles lots of 3rd party code, partly for convenience on 
Windows, but also because it's important that everything is statically linked 
when doing LD_PRELOAD / DLL injection, to avoid interfering with the 
applications' own .so/.dlls.)


Regarding the perf event tracing in Mesa, it seems a good idea to me in 
principle FWIW.  Even if for many developers a tracing single source might 
suffice, there are scenarios when tracing the whole system is useful (be it 
multiple processes like browsers & desktop compositors, virtualization 
host/guest, etc.)

For reference, Windows has an event tracing framework (ETW), used by many parts 
of the system, including D3D runtimes, which allow anybody to have a system 
wide view of performance [1].  And in fact, WDDM 1.2 drivers are required to 
hook into ETW [2].

In short, I think it would be nice if Mesa had support for tracing events, 
preferably in a way that allows to plug-in different tracing frameworks, while 
at the same time, allowing to opt out for those who don't need it.

Jose

[1] https://graphics.stanford.edu/~mdfisher/GPUView.html
[2] 
https://docs.microsoft.com/en-us/windows-hardware/drivers/display/user-mode-driver-logging


From: mesa-dev  on behalf of Dylan 
Baker 
Sent: Saturday, February 13, 2021 02:15
To: Rob Clark 
Cc: ML mesa-dev 
Subject: Re: [Mesa-dev] Perfetto CPU/GPU tracing

I can't speak for anyone else, but a giant pile of vendored code that you're 
expected to not update seems like a really bad idea to me.

On Fri, Feb 12, 2021, at 18:09, Rob Clark wrote:
> I'm not really sure that is a fair statement.. the work scales
> according to the API change (which I'm not really sure if it changes
> much other than adding things).. if the API doesn't change, it is not
> really any effort to update two files in mesa git.
>
> As far as bug fixes.. it is a lot of code, but seems like the largest
> part of it is just generated protobuf serialization/deserialization
> code, rather than anything interesting.
>
> And again, I'm not a fan of their approach of "just vendor it".. but
> it is how perfetto is intended to be used, and in this case it seems
> like the best approach, since it is a situation where the protocol is
> the point of abi stability.
>
> BR,
> -R
>
> On Fri, Feb 12, 2021 at 5:51 PM Dylan Baker  wrote:
> >
> > So, we're vendoring something that we know getting bug fixes for will be an 
> > enormous pile of work? That sounds like a really bad idea.
> >
> > On Fri, Feb 12, 2021, at 17:51, Rob Clark wrote:
> > > On Fri, Feb 12, 2021 at 5:35 PM Dylan Baker  wrote:
> > > >
> > > >
> > > >
> > > > On Fri, Feb 12, 2021, at 16:36, Rob Clark wrote:
> > > > > On Thu, Feb 11, 2021 at 5:40 PM John Bates  
> > > > > wrote:
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > > Runtime Characteristics
> > > > > >
> > > > > > ~500KB additional binary size. Even with using only the basic 
> > > > > > features of perfetto, it will increase the binary size of mesa by 
> > > > > > about 500KB.
> > > > >
> > > > > IMHO, that size is negligible.. looking at freedreno, a mesa build
> > > > > *only* enabling freedreno is already ~6MB.. distros typically use
> > > > > "megadriver" (ie. all the drivers linked into a single .so with hard
> > > > > links for the different  ${driver}_dri.so), which on my fedora laptop
> > > > > is ~21M.  Maybe if anything is relevant it is how much of that
> > > > > actually gets paged into RAM from disk, but I think 500K isn't a thing
> > > > > to worry about too much.
> > > > >
> > > > > > Background thread. Perfetto uses a background thread for 
> > > > > > communication with the system tracing daemon (traced) to advertise 
> > > > > > trace data and get notification of trace start/stop.
> > > > >
> > > > > Mesa already tends to have plenty of threads.. some of that depends on
> > > > > the driver, I think currently radeonsi is the threading king, but
> > > > > there are several other drivers working on threaded_context and async
> > > > > compile thread pool.
> > > > >
> > > > > It is worth mentioning that, AFAIU, perfetto can operate in
> > > > > self-server mode, which seems like it would be useful for distros
> > > > > which do not have the system daemon.  I'm not sure if we lose that
> > > > > with percetto?
> > > > >
> > > > > > Runtime overhead when disabled is designed to be optimal with one 
> > > > > > predicted branch, typically a few CPU cycles per event. While 
> > > > > > enabled, the overhead can be around 1 us per event.
> > > > > >
> > > > > > Integration Challenges
> > > > > >
> > > > > > The perfetto SDK is C++ and designed around macros, lambdas, inline 
> > > > > > templates, etc. There are ongoing discussions on providing an 
> 

[Mesa-dev] llvmpipe MSAA (Was: Fwd: [Mesa-users] Issues with removal of classic OSMesa)

[Jose Fonseca]

That's an interesting idea!

llvmpipe rasterization is complicated and very optimized, so changing 
llvmpipe's rasterizer to spit out MSAA coverages is very hard.  I think that a 
good way to approach this is to:

1) continue to do single sample rasterization, but adjust the line coeffs of 
the triangles edges (in llvmpipe rasterizer code known as plane coefficients) 
to do conservative rasterization (ie, so that any fragment that intersects a 
triangle is covered) when MSAA is enabled.  See 
https://developer.nvidia.com/content/dont-be-conservative-conservative-rasterization

2) once inside the fragment shader, compute SampleMaskIn from the unadjusted 
vertex positions, using the desired number of samples (and corresponding sample 
pattern)

None of this would be throwaway work: the SampleMaskIn are correct and could be 
used for full MSAA support in the future too, and the conservative 
rasterization could be a feature on its own right too eventually.

Jose


From: mesa-dev  on behalf of Marek 
Olšák 
Sent: Wednesday, January 6, 2021 05:57
To: Brian Paul 
Cc: mesa-dev@lists.freedesktop.org ; 
mesa-us...@lists.freedesktop.org 
Subject: Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

Hi,

llvmpipe could implement line and polygon smoothing by rasterizing in MSAA and 
passing the coverage to SampleMaskIn in the fragment shader, but doing Z/S 
tests and color writes and everything else single-sampled. Then, FragColor.a *= 
bitcount(SampleMaskIn) / (float)num_samples. It's roughly what OpenGL requires. 
There is at least one other gallium driver that does that.

Marek

On Mon, Jan 4, 2021 at 3:02 PM Brian Paul 
mailto:bri...@vmware.com>> 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 mailto:a.faen...@e-sign.com>>
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 

Re: [Mesa-dev] [AppVeyor] mesa staging/20.3 #20 failed

[Jose Fonseca]

And we'll keep fixing it.  That's the agreement we reached regarding SCons 
build.

What happened was that AppVeyor integration (a git post commit hook which was 
in freedesktop.org) stopped working, so nobody noticed the builds got broken.  
Otherwise, it would be unlikely for master to keep breaking.

We need to be able to run SCons CI pipelines to know things are failing.


Regarding moving away from SCons, it would be nice if we resolved whatever are 
the blocking issues on 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6418 so we could make 
progress there.  I'm no Meson expert, but just like I commented, IMO if what 
Neha proposed works for us and doesn't break other pipelines, why not go ahead 
with it, so we can stop relying on SCons, and polish things later?  It looks 
we're missing the forest for the trees..

Jose


From: Michel Dänzer 
Sent: Thursday, November 26, 2020 11:46
To: Jose Fonseca 
Cc: mesa-dev@lists.freedesktop.org ; Neha 
Bhende 
Subject: Re: [Mesa-dev] [AppVeyor] mesa staging/20.3 #20 failed

On 2020-11-26 12:41 p.m., Jose Fonseca wrote:
> Yes, master builds are currently failing but they won't stay like that
> for long.  Several folks here are on PTO with due to Thanksgiving in US
> but we should get to it afterwards.

As long as the MSVC build isn't tested in pre-merge CI, it'll keep breaking.


--
Earthling Michel Dänzer   |   
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fredhat.com%2Fdata=04%7C01%7Cjfonseca%40vmware.com%7Cb03c6010fd37418aa76708d89200e74e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637419879875347952%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=a7wkbAknH0ZOTUzB8ecH3Da4qZ%2BuQIzTNURN8oJOK%2BY%3Dreserved=0
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [AppVeyor] mesa staging/20.3 #20 failed

[Jose Fonseca]

Yes, master builds are currently failing but they won't stay like that for 
long.  Several folks here are on PTO with due to Thanksgiving in US but we 
should get to it afterwards.

Jose


From: Michel Dänzer 
Sent: Thursday, November 26, 2020 11:05
To: Jose Fonseca 
Cc: mesa-dev@lists.freedesktop.org 
Subject: Re: [Mesa-dev] [AppVeyor] mesa staging/20.3 #20 failed

On 2020-11-25 8:00 p.m., Jose Fonseca wrote:
> FYI, I've just recently re-connected Appveyor, after noticing that
> AppVeyor integration got broken for 6 months, and that Mesa MSVC builds
> got broken for two months.

The best way to prevent this from happening would be to get the MSVC
build job working again in the GitLab CI pipeline. (It was disabled 3
months ago due to runner reliability issues, see
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F6495data=04%7C01%7Cjfonseca%40vmware.com%7C4d7211cb4aa440bd849308d891fb2b03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637419855245558660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=IDMi9Odx5955PQWP4aMlFgNoLEsBQ2n9umP%2FS3cyLqM%3Dreserved=0)


> At any rate, notifications are setup to notify only when build changes
> state (pass <-> fail) so hopefully it won't spam the list, even on
> branches (such as 20.3) where MSVC stays broken.
>
> If that doesn't work I can always drop mesa-dev from the list.

Personally I find the failed master jobs on
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fpipelinesdata=04%7C01%7Cjfonseca%40vmware.com%7C4d7211cb4aa440bd849308d891fb2b03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637419855245558660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=0NHK12d8cacLUqOjBO3RVJnePdxxPQxohP32gd2asI0%3Dreserved=0
 more annoying.


--
Earthling Michel Dänzer   |   
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fredhat.com%2Fdata=04%7C01%7Cjfonseca%40vmware.com%7C4d7211cb4aa440bd849308d891fb2b03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637419855245558660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ygfhn%2BbtPxem0o%2Fsfqt5%2BLZ7V0rO%2FXwR13%2B8UcXWCiE%3Dreserved=0
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [AppVeyor] mesa staging/20.3 #20 failed

[Jose Fonseca]

FYI, I've just recently re-connected Appveyor, after noticing that AppVeyor 
integration got broken for 6 months, and that Mesa MSVC builds got broken for 
two months.

I configured AppVeyor only build master, but it seems that it's not effective, 
unless one modifies appveyor.yml itself.

At any rate, notifications are setup to notify only when build changes state 
(pass <-> fail) so hopefully it won't spam the list, even on branches (such as 
20.3) where MSVC stays broken.

If that doesn't work I can always drop mesa-dev from the list.

Jose


From: mesa-dev  on behalf of AppVeyor 

Sent: Wednesday, November 25, 2020 18:28
To: mesa-dev@lists.freedesktop.org 
Subject: [Mesa-dev] [AppVeyor] mesa staging/20.3 #20 failed

Build mesa 20 
failed

Commit 0cbc19416a by Dylan Baker on 11/25/2020 
6:15 PM:
.pick_status.json: Update to ff9ea469f6b319cb07ee1ebbb687fa19c9d48e1c

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

Re: [Mesa-dev] llvmpipe is OpenGL 4.5 conformant.

[Jose Fonseca]

That's amazing!

Jose


From: mesa-dev  on behalf of Dave 
Airlie 
Sent: Friday, October 30, 2020 20:24
To: mesa-dev 
Subject: [Mesa-dev] llvmpipe is OpenGL 4.5 conformant.

Just to let everyone know, a month ago I submitted the 20.2 llvmpipe
driver for OpenGL 4.5 conformance under the SPI/X.org umbrella, and it
is now official[1].

Thanks to everyone who helped me drive this forward, and to all the
contributors both to llvmpipe and the general Mesa stack that enabled
this.

Big shout out to Roland Scheidegger for helping review the mountain of
patches I produced in this effort.

My next plans involved submitting lavapipe for Vulkan 1.0, it's at 99%
or so CTS, but there are line drawing, sampler accuracy and some snorm
blending failure I have to work out.
I also ran the OpenCL 3.0 conformance suite against clover/llvmpipe
yesterday and have some vague hopes of driving that to some sort of
completion.

(for GL 4.6 only texture anisotropy is really missing, I've got
patches for SPIR-V support, in case someone was feeling adventurous).

Dave.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fconformance%2Fadopters%2Fconformant-products%2Fopengl%23submission_272data=04%7C01%7Cjfonseca%40vmware.com%7C9869322310dc466d3a6108d87d11db3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637396862939633538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=yY6XAmVcXUe2Q8hwaq0umQgsQMK%2FLv%2FxL%2BdqW9fffns%3Dreserved=0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=04%7C01%7Cjfonseca%40vmware.com%7C9869322310dc466d3a6108d87d11db3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637396862939633538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=dVIe0U5NjcG3kl7w1%2F2DpjRrIh9oomg66hOtQgp%2BSqc%3Dreserved=0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] RFC: Memory allocation on Mesa

[Jose Fonseca]

> What are the exact use-cases for Mesa specific allocation data?

In general, the use case is to implement Vulkan allocation callbacks.

Our particular use case is memory accounting: there is a fixed memory budget, 
so we need to keep track (not as an external tool but in the application 
itself) of all the memory consumed by every component.   So components can't 
just call malloc, but instead other memory allocating functions, which ensure 
they stay within their budget.

At any rate, I believe we'll pursue's Brian' u_trackmem.h approach for now.


Jose


From: mesa-dev  on behalf of Tamminen, 
Eero T 
Sent: Tuesday, May 12, 2020 19:08
To: mesa-dev@lists.freedesktop.org 
Subject: Re: [Mesa-dev] RFC: Memory allocation on Mesa

Hi,

On Tue, 2020-05-12 at 14:36 +0000, Jose Fonseca wrote:
> From: mesa-dev  on behalf of
> Tamminen, Eero T 
> I've done a lot of resource usage analysis at former job[1], but I've
> never had needed anything like that.  malloc etc all reside in a
> separate shared library from Mesa, so calls to them always cross
> dynamic library boundary and therefore all of them can be caught with
> the dynamic linker features (LD_PRELOAD, LD_AUDIT...).
>
> True, one can easily intercept all mallocs using that sort of dynamic
> linking tricks, when doing full application interception.  (I even
> have done some of the sort on 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjrfonseca%2Fmemtraildata=02%7C01%7Cjfonseca%40vmware.com%7C7803192c4bf349748ccd08d7f69f8305%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637249037275021774sdata=Ep9otfr5LTrE8w2a3S1E12MhFHkt8Xvawp%2BxLbrciQs%3Dreserved=0
>  ,
> mostly to hunt down memory leaks on LLVM.) But the goal here is to
> intercept the OpenGL/Vulkan driver malloc calls alone.  Not the
> application mallocs.  Which is difficult to segregate when doing
> whole application interception.

Only reason to do this that I can think of would be to report some Mesa
specific metrics to an application at run-time.  But that will need
careful thought on how *applications* are supposed to *use* that data,
otherwise it's just "garbage in, garbage out".

What are the exact use-cases for Mesa specific allocation data?


> For simplicity imagine you have only these shared objects:
>application (not controlled by us)
>libVulkan.so
>libstdcc++.so
>libc.so
>
> Now imagine you're intercepting malloc doing some sort of LD_PRELOAD
> interception, and malloc is called.  How do you know if it's a call
> done by the Vulkan driver, hence should call the callback, or one
> done by the application, hence not call the Vulkan allocation
> callback.
>
> One can look at the caller IP address, but what if the caller is in
> libstdc++ which is used both by Vulkan and the app, is not
> immediately clear which to bill the memory.  One would need to walk
> back the stack completely, which is complicated and not very
> reliable.

Over decade ago it was unreliable, but not anymore.  Even stripped
binaries contain the frame information section (I think it's needed
e.g. for handling C++ exceptions).  So nowadays it's simple to use, and
Glibc has a function for it.

For analysis, you don't do filtering while tracing, as that's too
limiting, you do it in post-processing phase.


If you really need to do run-time per-library filtering, you could do
it based on the backtrace addresses, and whether they fall within the
address range where the library you're interested about is mapped.

For that, you need to overload library loading, so you can catch when
Mesa gets loaded, and find out its (address-space-randomized) load
address range.


> Imagine one guesses wrong -- the malloc interceptor believes the
> malloc call is done by the Vulkan driver, and calls the application
> callback, which then calls malloc again, and the interceptor guesses
> wrong again, therefore an infinite recursion loop.

If you find your own code addresses from the backtrace, STOP. :-)


> Could you be confusing this with trying to catch some Mesa specific
> function, where dynamic linker can catch only calls from application
> to
> Mesa, but not calls within Mesa library itself (as they don't cross
> dynamic library boundary)?
>
> My goal from the beginning is intercepting all mallocs/frees done by
> Mesa OpenGL/Vulkan driver, and only those.

If this is for analysis, I would do it in post-processing phase (with
sp-rtrace).  Just ask post-processor to filter-in allocation backtraces
going through the library I'm interested about.


...
> Yes, indeed Linux has much better tooling for this than
> Windows.  Note that memory debugging on Windows is just one of our
> needs.  The other being able to run Mesa driver on an embedded system
> with fixed amount of memory (a separate budget for 

Re: [Mesa-dev] RFC: Memory allocation on Mesa

[Jose Fonseca]

On 05/11/2020 10:13 AM, Jose Fonseca wrote:
> Hi,
>
> To give everybody a bit of background context, this email comes from
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/2911 .
>
> The short story is that Gallium components (but not Mesa) used to have
> their malloc/free calls intercepted, to satisfy certain needs: 1) memory
> debugging on Windows, 2) memory accounting on embedded systems.  But
> with the unification of Gallium into Mesa, the gallium vs non-gallium
> division got blurred, leading to some mallocs being intercepted but not
> the respective frees, and vice-versa.
>
>
> I admit that trying to intercept mallocs/frees for some components and
> not others is error prone.  We could get this going on again, it's
> doable, but it's possible it would keep come causing troubles, for us or
> others, over and over again.
>
>
> The two needs mentioned above were mostly VMware's needs.  So I've
> reevaluated, and I /think/ that with some trickery we satisfy those two
> needs differently.  (Without wide spread source code changes.)
>
>
> On the other hand, VMware is probably not the only one to have such
> needs.  In fact Vulkan spec added memory callbacks precisely with the
> same use cases as ours, as seen
> https://www.khronos.org/registry/vulkan/specs/1.2/html/chap10.html#memory-host
>  which
> states:
>
> /Vulkan provides applications the opportunity to perform host memory
> allocations on behalf of the Vulkan implementation. If this feature
> is not used, the implementation will perform its own memory
> allocations. Since most memory allocations are off the critical
> path, this is not meant as a performance feature. *Rather, this can
> be useful for certain embedded systems, for debugging purposes (e.g.
> putting a guard page after all host allocations), or for memory
> allocation logging.*/
>
>
> And I know there were people interested in having Mesa drivers on
> embedded devices on the past (the old Tunsten Graphics having even been
> multiple times hired to do so), and I'm pretty sure they exist again.
>
>
>
> Therefore, rather than shying away from memory allocation abstractions
> now, I wonder if now it's not the time to actually double down on them
> and ensure we do so comprehensively throughout the whole mesa, all drivers?
> *
> *
> After all Mesa traditionally always had MALLOC*/CALLOC*/FREE wrappers
> around malloc/free.  As so many other projects do.
>
>
>
> More concretely, I'd like to propose that we:
>
>   * ensure all components use MALLOC*/CALLOC*/FREE and never
> malloc/calloc/free directly (unless interfacing with a 3rd party
> which expects memory to be allocated/freed with malloc/free directly)
>   * Perhaps consider renaming MALLOC -> _mesa_malloc etc while we're at it
>   * introduce a mechanisms to quickly catch any mistaken use of
> malloc/calloc/free, regardless compiler/OS used:
>   o #define malloc/free/calloc as malloc_do_not_use/free_do_not_use
> to trigger compilation errors, except on files which explicely
> opt out of this (source files which need to interface with 3rd
> party, or source files which implement the callbacks)
>   o Add a cookie to MALLOC/CALLOC/FREE memory to ensure it's not
> inadvertently mixed with malloc/calloc/free
>
> The end goal is that we should be able to have a memory allocation
> abstraction which can be used for all the needs above: memory debugging,
> memory accounting, and satisfying Vulkan host memory callbacks.
>
>
> Some might retort: why not just play some tricks with the linker, and
> intercept all malloc/free calls, without actually having to modify any
> source code?
>
> Yes, that's indeed technically feasible.  And is precisely the sort of
> trick I was planing to resort to satisfy VMware needs without having to
> further modify the source code.  But for these tricks to work, it is
> absolutely /imperative/ that one statically links C++ library and STL.
> The problem being that if one doesn't then there's an imbalance: the
> malloc/free/new/delete calls done in inline code on C++ headers will be
> intercepted, where as malloc/free/new/delete calls done in code from the
> shared object which is not inlined will not, causing havoc.  This is OK
> for us VMware (we do it already for many other reasons, including
> avoiding DLL hell.)  But I doubt it will be palatable for everybody
> else, particularly Linux distros, to have everything statically linked.
>
> So effectively, if one really wants to implement Vulkan host memory
> callbacks, the best way is to explicitly use malloc/free abstractions,
> instead of the malloc/free directly.
>
>
> So befo

Re: [Mesa-dev] RFC: Memory allocation on Mesa

[Jose Fonseca]

From: mesa-dev  on behalf of Tamminen, 
Eero T 
Sent: Monday, May 11, 2020 21:19
To: mesa-dev@lists.freedesktop.org 
Subject: Re: [Mesa-dev] RFC: Memory allocation on Mesa

Hi,

On Mon, 2020-05-11 at 16:13 +, Jose Fonseca wrote:
> Some might retort: why not just play some tricks with the linker, and
> intercept all malloc/free calls, without actually having to modify
> any source code?
>
> Yes, that's indeed technically feasible.  And is precisely the sort
> of trick I was planing to resort to satisfy VMware needs without
> having to further modify the source code.  But for these tricks to
> work, it is absolutely imperative that one statically links C++
> library and STL.  The problem being that if one doesn't then there's
> an imbalance: the malloc/free/new/delete calls done in inline code on
> C++ headers will be intercepted, where as malloc/free/new/delete
> calls done in code from the shared object which is not inlined will
> not, causing havoc.  This is OK for us VMware (we do it already for
> many other reasons, including avoiding DLL hell.)  But I doubt it
> will be palatable for everybody else, particularly Linux distros, to
> have everything statically linked.

Huh?

I've done a lot of resource usage analysis at former job[1], but I've
never had needed anything like that.  malloc etc all reside in a
separate shared library from Mesa, so calls to them always cross
dynamic library boundary and therefore all of them can be caught with
the dynamic linker features (LD_PRELOAD, LD_AUDIT...).

True, one can easily intercept all mallocs using that sort of dynamic linking 
tricks, when doing full application interception.  (I even have done some of 
the sort on https://github.com/jrfonseca/memtrail , mostly to hunt down memory 
leaks on LLVM.) But the goal here is to intercept the OpenGL/Vulkan driver 
malloc calls alone.  Not the application mallocs.  Which is difficult to 
segregate when doing whole application interception.

For simplicity imagine you have only these shared objects:

   application (not controlled by us)
   libVulkan.so
   libstdcc++.so
   libc.so

Now imagine you're intercepting malloc doing some sort of LD_PRELOAD 
interception, and malloc is called.  How do you know if it's a call done by the 
Vulkan driver, hence should call the callback, or one done by the application, 
hence not call the Vulkan allocation callback.

One can look at the caller IP address, but what if the caller is in libstdc++ 
which is used both by Vulkan and the app, is not immediately clear which to 
bill the memory.  One would need to walk back the stack completely, which is 
complicated and not very reliable.

Imagine one guesses wrong -- the malloc interceptor believes the malloc call is 
done by the Vulkan driver, and calls the application callback, which then calls 
malloc again, and the interceptor guesses wrong again, therefore an infinite 
recursion loop.

Could you be confusing this with trying to catch some Mesa specific
function, where dynamic linker can catch only calls from application to
Mesa, but not calls within Mesa library itself (as they don't cross
dynamic library boundary)?

My goal from the beginning is intercepting all mallocs/frees done by Mesa 
OpenGL/Vulkan driver, and only those.

Note: at least earlier, new & delete typically called malloc & free (in
addition to calling ctor & dtor), in which case you don't even need to
track them separately.  You see their usage directly from the
allocation callgraph.


- Eero

PS. Your XDot tool was a really nice tool for viewing those call-
graphs. :-)

Thanks! :)

[1] Linux has several ready-made tools for tracking resource
allocations (several Valgrind tools, ElectricFence, Duma etc), and we
added few more at Nokia, with main one being:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmaemo-tools-old%2Fsp-rtracedata=02%7C01%7Cjfonseca%40vmware.com%7Cc77b32234e7c4e59af7f08d7f5e89d09%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637248251736102860sdata=4ZD66qaYmgCBv%2FQqRqamCWh1wYdFxqvuz0sqDZEnC3Y%3Dreserved=0

(Most memorable thing was early Qt/C++ application version doing
~10(!) allocation frees while it was initializing itself, due to
redundantly creating, localizing and removing one user view.)
Yes, indeed Linux has much better tooling for this than Windows.  Note that 
memory debugging on Windows is just one of our needs.  The other being able to 
run Mesa driver on an embedded system with fixed amount of memory (a separate 
budget for Mesa mallocs.)

Jose


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

Re: [Mesa-dev] RFC: Memory allocation on Mesa

[Jose Fonseca]

From: Timur Kristóf 
Sent: Monday, May 11, 2020 18:06
To: Jose Fonseca ; ML mesa-dev 

Cc: erik.faye-l...@collabora.com 
Subject: Re: [Mesa-dev] RFC: Memory allocation on Mesa

On Mon, 2020-05-11 at 16:13 +, Jose Fonseca wrote:
> Some might retort: why not just play some tricks with the linker, and
> intercept all malloc/free calls, without actually having to modify
> any source code?
>
> Yes, that's indeed technically feasible.  And is precisely the sort
> of trick I was planing to resort to satisfy VMware needs without
> having to further modify the source code.  But for these tricks to
> work, it is absolutely imperative that one statically links C++
> library and STL.  The problem being that if one doesn't then there's
> an imbalance: the malloc/free/new/delete calls done in inline code on
> C++ headers will be intercepted, where as malloc/free/new/delete
> calls  done in code from the shared object which is not inlined will
> not, causing havoc.

Wouldn't you face the same issue if you chose to wrap all calls to
malloc and free in mesa, instead of relying on the linker? Any
dynamically linked or 3rd party library, including the C++ standard
library, will have no way of knowing about our wrapped malloc and free.

Timur

Indeed 3rd part libraries aren't tracked either way.   But I wasn't talking 
about 3rd party libraries, but rather Mesa itself.

Mesa is mostly written in C but some C++ code (ever more in fact.)  My point is 
that even if we ignore 3rd party libraries, if one takes the linker approach 
without statically linking, mesa new/delete calls would go unbalanced and the 
consequence would be crashes.

With explicit malloc/free, the consequent at most is untracked mallocs/frees, 
but there should never be any unbalanced mallocs frees, hence no crashes.

To be clear, there are two kinds of problems here:
1. allocate memory with one allocator and free with another -- this is 
catastrophic and will lead to a segfault
2. not intercept every single malloc/free pair -- this is not ideal -- but is 
inescapable to some extent .  One always need some memory reservation to plain 
old malloc/free, but the less the better.

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

Re: [Mesa-dev] RFC: Memory allocation on Mesa

[Jose Fonseca]

You raise a good point about LLVM.  It can easily be the biggest memory 
consumer (at least transiently) for any driver that uses it, so the value of 
implementing Vulkan allocation callbacks without is indeed dubious.

Jose


From: Jason Ekstrand 
Sent: Monday, May 11, 2020 17:29
To: Jose Fonseca 
Cc: ML mesa-dev ; erik.faye-l...@collabora.com 

Subject: Re: [Mesa-dev] RFC: Memory allocation on Mesa

Sorry for the top-post.

Very quick comment:  If part of your objective is to fulfill Vulkan's
requirements, we need a LOT more plumbing than just
MALLOC/CALLOC/FREE.  The Vulkan callbacks aren't set at a global level
when the driver is loaded but are provided to every call that
allocates anything and we're expected to track these sorts of
"domains" that things are allocated from.  The reality, however, is
that the moment you get into the compiler, all bets are off.  This is
also true on other drivers; I don't think anyone has plumbed the
Vulkan allocation callbacks into LLVM. :-)

--Jason

On Mon, May 11, 2020 at 11:13 AM Jose Fonseca  wrote:
>
> Hi,
>
> To give everybody a bit of background context, this email comes from 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fissues%2F2911data=02%7C01%7Cjfonseca%40vmware.com%7C6565468f840241a093ae08d7f5c877d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637248113667594798sdata=hYmA5dMivC0jGjAx9cA9MwF81FjQSoo5plQBvHEDYes%3Dreserved=0
>  .
>
> The short story is that Gallium components (but not Mesa) used to have their 
> malloc/free calls intercepted, to satisfy certain needs: 1) memory debugging 
> on Windows, 2) memory accounting on embedded systems.  But with the 
> unification of Gallium into Mesa, the gallium vs non-gallium division got 
> blurred, leading to some mallocs being intercepted but not the respective 
> frees, and vice-versa.
>
>
> I admit that trying to intercept mallocs/frees for some components and not 
> others is error prone.  We could get this going on again, it's doable, but 
> it's possible it would keep come causing troubles, for us or others, over and 
> over again.
>
>
> The two needs mentioned above were mostly VMware's needs.  So I've 
> reevaluated, and I think that with some trickery we satisfy those two needs 
> differently.  (Without wide spread source code changes.)
>
>
> On the other hand, VMware is probably not the only one to have such needs.  
> In fact Vulkan spec added memory callbacks precisely with the same use cases 
> as ours, as seen 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fregistry%2Fvulkan%2Fspecs%2F1.2%2Fhtml%2Fchap10.html%23memory-hostdata=02%7C01%7Cjfonseca%40vmware.com%7C6565468f840241a093ae08d7f5c877d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637248113667594798sdata=SarQxeuRUMOm%2FZHogUQKo64rh7K7uLn5UOlIRPDe1jM%3Dreserved=0
>  which states:
>
> Vulkan provides applications the opportunity to perform host memory 
> allocations on behalf of the Vulkan implementation. If this feature is not 
> used, the implementation will perform its own memory allocations. Since most 
> memory allocations are off the critical path, this is not meant as a 
> performance feature. Rather, this can be useful for certain embedded systems, 
> for debugging purposes (e.g. putting a guard page after all host 
> allocations), or for memory allocation logging.
>
>
> And I know there were people interested in having Mesa drivers on embedded 
> devices on the past (the old Tunsten Graphics having even been multiple times 
> hired to do so), and I'm pretty sure they exist again.
>
>
>
> Therefore, rather than shying away from memory allocation abstractions now, I 
> wonder if now it's not the time to actually double down on them and ensure we 
> do so comprehensively throughout the whole mesa, all drivers?
>
> After all Mesa traditionally always had MALLOC*/CALLOC*/FREE wrappers around 
> malloc/free.  As so many other projects do.
>
>
>
> More concretely, I'd like to propose that we:
>
> ensure all components use MALLOC*/CALLOC*/FREE and never malloc/calloc/free 
> directly (unless interfacing with a 3rd party which expects memory to be 
> allocated/freed with malloc/free directly)
> Perhaps consider renaming MALLOC -> _mesa_malloc etc while we're at it
> introduce a mechanisms to quickly catch any mistaken use of 
> malloc/calloc/free, regardless compiler/OS used:
>
> #define malloc/free/calloc as malloc_do_not_use/free_do_not_use to trigger 
> compilation errors, except on files which explicely opt out of this (source 
> files which need to interface with 3rd party, or source files which implement 
> the callbacks)
> Add a cookie to MALLOC/CALLOC/FREE memory to ensure 

[Mesa-dev] RFC: Memory allocation on Mesa

[Jose Fonseca]

Hi,

To give everybody a bit of background context, this email comes from 
https://gitlab.freedesktop.org/mesa/mesa/-/issues/2911 .

The short story is that Gallium components (but not Mesa) used to have their 
malloc/free calls intercepted, to satisfy certain needs: 1) memory debugging on 
Windows, 2) memory accounting on embedded systems.  But with the unification of 
Gallium into Mesa, the gallium vs non-gallium division got blurred, leading to 
some mallocs being intercepted but not the respective frees, and vice-versa.


I admit that trying to intercept mallocs/frees for some components and not 
others is error prone.  We could get this going on again, it's doable, but it's 
possible it would keep come causing troubles, for us or others, over and over 
again.


The two needs mentioned above were mostly VMware's needs.  So I've reevaluated, 
and I think that with some trickery we satisfy those two needs differently.  
(Without wide spread source code changes.)


On the other hand, VMware is probably not the only one to have such needs.  In 
fact Vulkan spec added memory callbacks precisely with the same use cases as 
ours, as seen 
https://www.khronos.org/registry/vulkan/specs/1.2/html/chap10.html#memory-host 
which states:

Vulkan provides applications the opportunity to perform host memory allocations 
on behalf of the Vulkan implementation. If this feature is not used, the 
implementation will perform its own memory allocations. Since most memory 
allocations are off the critical path, this is not meant as a performance 
feature. Rather, this can be useful for certain embedded systems, for debugging 
purposes (e.g. putting a guard page after all host allocations), or for memory 
allocation logging.

And I know there were people interested in having Mesa drivers on embedded 
devices on the past (the old Tunsten Graphics having even been multiple times 
hired to do so), and I'm pretty sure they exist again.



Therefore, rather than shying away from memory allocation abstractions now, I 
wonder if now it's not the time to actually double down on them and ensure we 
do so comprehensively throughout the whole mesa, all drivers?

After all Mesa traditionally always had MALLOC*/CALLOC*/FREE wrappers around 
malloc/free.  As so many other projects do.



More concretely, I'd like to propose that we:

  *   ensure all components use MALLOC*/CALLOC*/FREE and never 
malloc/calloc/free directly (unless interfacing with a 3rd party which expects 
memory to be allocated/freed with malloc/free directly)
  *   Perhaps consider renaming MALLOC -> _mesa_malloc etc while we're at it
  *   introduce a mechanisms to quickly catch any mistaken use of 
malloc/calloc/free, regardless compiler/OS used:
 *   #define malloc/free/calloc as malloc_do_not_use/free_do_not_use to 
trigger compilation errors, except on files which explicely opt out of this 
(source files which need to interface with 3rd party, or source files which 
implement the callbacks)
 *   Add a cookie to MALLOC/CALLOC/FREE memory to ensure it's not 
inadvertently mixed with malloc/calloc/free

The end goal is that we should be able to have a memory allocation abstraction 
which can be used for all the needs above: memory debugging, memory accounting, 
and satisfying Vulkan host memory callbacks.


Some might retort: why not just play some tricks with the linker, and intercept 
all malloc/free calls, without actually having to modify any source code?

Yes, that's indeed technically feasible.  And is precisely the sort of trick I 
was planing to resort to satisfy VMware needs without having to further modify 
the source code.  But for these tricks to work, it is absolutely imperative 
that one statically links C++ library and STL.  The problem being that if one 
doesn't then there's an imbalance: the malloc/free/new/delete calls done in 
inline code on C++ headers will be intercepted, where as malloc/free/new/delete 
calls done in code from the shared object which is not inlined will not, 
causing havoc.  This is OK for us VMware (we do it already for many other 
reasons, including avoiding DLL hell.)  But I doubt it will be palatable for 
everybody else, particularly Linux distros, to have everything statically 
linked.

So effectively, if one really wants to implement Vulkan host memory callbacks, 
the best way is to explicitly use malloc/free abstractions, instead of the 
malloc/free directly.


So before we put more time on pursuing either the "all" or "nothing" 
approaches, I'd like to get a feel for where people's preferences are.

Jose

___
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?

[Jose Fonseca]

From: Michel Dänzer 
Sent: Friday, March 27, 2020 15:56
To: Jose Fonseca ; Marek Olšák 
Cc: Neha Bhende ; Kristian Høgsberg ; 
Dylan Baker ; mesa-dev 
Subject: Re: [Mesa-dev] Drop scons for 20.1?

On 2020-03-27 2:29 p.m., Jose Fonseca wrote:
>
> If SCons is such a time sink, then the best we can do is suggest to
> take it off Marge-bot.

That would be something like
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F4352data=02%7C01%7Cjfonseca%40vmware.com%7C786cd1eeae684a45dd3a08d7d26766aa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637209213877300351sdata=c9OoEsfgpIGhwoewerL%2Fb7ZShTr9CVCtLJdcMPLoUVk%3Dreserved=0
 then.

Not quite what I had in mind (I suggested take it off Marge-bot, as opposed to 
take it off completely.)  But lets continue the conversion in the MR.

For the record I also did make a 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4348 for reducing the 
targets as suggested by Marek, which I'd like to get in first.

> The onus of fixing SCons will go back to us, as it always did
> throughout these the past twelve years.

Not for the last year or so, when it's been part of the pre-merge CI
pipeline?
True.  And while I don't recall asking SCons to be added to pre-merge CI (I 
certainly did not), I do appreciate the effort and grief this might have 
caused.  Lets take it out.  As tiring fixing SCons by ourselves might be, is 
still better than being constantly painted as the bad guys and constantly have 
to fend off requests to yank off SCons.

Jose

___
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?

[Jose Fonseca]

In the long term we should reduce the complexity of the project. scons is a 
maintenance burden.
We all agree here.  And we are making progress.  Even a couple of weeks ago I 
had to debug and fix weird Meson behaviour -- 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4186
 Every time I break the scons build and the CI reports it, can I politely ask 
you to fix my MR instead of me doing it? Then at least the real maintenance 
cost would be known to scons supporters, instead of the cost being invisible to 
most.
Sure.  But first I want all the time back I spent fixing scons and msvc builds 
when the cost was invisible to most.  Even after setting up Appveyor people 
ignored the successive build failures.  Even when fix was plain trivial and 
easily avoidable (like replacing non-standard `= {}`  initializers for `= { 0 
}`).   Even when I politely asked to fix it, people ignored.  Not you perhaps, 
but several did.

Honestly, why do you blame me/us?  Mesa had multiple build systems for all its 
life -- all with different state of brokenness.   What really changed these 
days is not actually the Meson-holy-grail, but this new Marge-bot overlord.  
Personally I find it this new process a tad too draconian.

If SCons is such a time sink, then the best we can do is suggest to take it off 
Marge-bot.  The onus of fixing SCons will go back to us, as it always did 
throughout these the past twelve years.

BTW, the grief you and others might be experiencing now, is probably 1/100th of 
what we systematically had throughout these years.  I particularly recall all 
the pain and grief to replicate all the autoconf build logic for code 
generation every time there was a major addition / refactoring in Mesa -- in 
particular all those Python scripts that generated C code are very difficult to 
match, because unlike Autoconf, SCons had fined grained dependencies, so 
missing one dependency meant incremental builds would use stale source code.  
Some times there were more broken builds that good ones.  Even git-bisecting 
was extremely had as result.  Though to be fair, I do recall I also moaned and 
bitch about it too.
In the mean time, I think we can remove all parts of scons that VMWare does NOT 
care about. Do you need haiku-softpipe? Do you need graw-null? Do you need swr? 
glx? There is bunch you don't really need on Windows.
Now that is a more serious proposal.  An excellent one in fact.

The only scons targets we need are libgl-gdi (and its dependencies, including 
llvmpipe) and svga.

Everything else can go as far as we are concerned.  graw was useful at one 
point, but I don't think it's that useful anymore.  Regarding haiku-softpipe 
and swr targets, they were not added to SCons by VMware.  I suppose if the 
stakeholders didn't speak up so far, one can assume they don't care.

Jose


From: Marek Olšák 
Sent: Friday, March 27, 2020 00:56
To: Jose Fonseca 
Cc: Jason Ekstrand ; Rob Clark ; 
Kristian Høgsberg ; mesa-dev 
; Dylan Baker 
Subject: Re: [Mesa-dev] Drop scons for 20.1?

In the long term we should reduce the complexity of the project. scons is a 
maintenance burden. Every time I break the scons build and the CI reports it, 
can I politely ask you to fix my MR instead of me doing it? Then at least the 
real maintenance cost would be known to scons supporters, instead of the cost 
being invisible to most.

In the mean time, I think we can remove all parts of scons that VMWare does NOT 
care about. Do you need haiku-softpipe? Do you need graw-null? Do you need swr? 
glx? There is bunch you don't really need on Windows.

Marek

On Wed, Feb 26, 2020 at 3:44 PM Jose Fonseca 
mailto:jfons...@vmware.com>> wrote:
We already solved some pieces (e.g, how to consume and use Meson, while 
following our internal legal process required for adding new 3rd party 
dependencies), and figured a way to consume Meson build without having to 
migrate lots of internal build logic from Scons to Meson.  But other stuff just 
keeps getting higher priority, and we haven't fully migrated.

Please do understand, SCons just works for us.  We are making progress with 
Meson.  It's just not the highest priority, when time is short, it gets 
deferred.

I don't understand the rush.  If it was trivial and easy we'd obviously would 
have done it.

Jose


From: Jason Ekstrand mailto:ja...@jlekstrand.net>>
Sent: Wednesday, February 26, 2020 04:15
To: Rob Clark mailto:robdcl...@gmail.com>>; Kristian 
Høgsberg mailto:hoegsb...@gmail.com>>
Cc: mesa-dev 
mailto:mesa-dev@lists.freedesktop.org>>; Dylan 
Baker mailto:baker.dyla...@gmail.com>>; Jose Fonseca 
mailto:jfons...@vmware.com>>; Brian Paul 
mailto:bri...@vmware.com>>
Subject: Re: [Mesa-dev] Drop scons for 20.1?

+Jose & Brian

I'm not personally opposed but I also can't remember the last time I had to
fix the scons build. I think it's been years. Maybe that's beca

Re: [Mesa-dev] OpenGL and OpenCL on top of D3D12

[Jose Fonseca]

Hi,

This is very interesting work from my POV.  It's definitely great to have more 
members in Mesa community interested in Windows, and is exciting to see renewed 
interest in OpenGL from Microsoft.  There are always very difficult corner 
cases when translating between one graphics API to another, but given enough 
dedication, I see no reason why one can't achieve an OpenGL implementation on 
top of D3D12 that gets the job well done on virtually all the important uses 
cases.

Regarding the WGL headers, please give us a shout if you notice anything 
obviously wrong in the reversed engineered interfaces.  I've been away from 
Mesa dev lately, but I'll do my best to keep an eye on this work.  It would be 
helpful if you could explicitly CC @jrfonseca on changes specific to WGL 
headers / state tracker.  Thanks.

Jose


From: mesa-dev  on behalf of Gert 
Wollny 
Sent: Tuesday, March 24, 2020 16:38
To: Mesa ML 
Subject: [Mesa-dev] OpenGL and OpenCL on top of D3D12

Dear Mesa developers,

Today, we at Collabora together with Microsoft have announced a new
project based on Mesa: OpenGL and OpenCL on top of Microsoft's D3D12.
You can find the full  announcements here:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.collabora.com%2Fnews-and-blog%2Fnews-and-events%2Fintroducing-opencl-and-opengl-on-directx.htmldata=02%7C01%7Cjfonseca%40vmware.com%7C1fbe982d5e534ff7eb6308d7d011dac7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637206647447892216sdata=TGEvmkS73dffnLz%2BEgHSmN3QQ%2FTRPRoza%2ByySEc4s88%3Dreserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevblogs.microsoft.com%2Fdirectx%2Fin-the-works-opencl-and-opengl-mapping-layers-to-directxdata=02%7C01%7Cjfonseca%40vmware.com%7C1fbe982d5e534ff7eb6308d7d011dac7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637206647447892216sdata=qDVwOUZjteHtCaWmkbSiyka7Fc1ZJyTCMXS7q8pN0Ec%3Dreserved=0

How does this affect Mesa?

First of all, we intend to contribute this work into upstream Mesa.

The OpenGL work is similar to what Zink does with Vulkan, and will use
some comparable approaches for the emulation of features, hence there
will be some obvious opportunities for code-sharing with Zink.

The OpenCL support is not using the Clover runtime, but instead is a
standalone runtime that shares the NIR-to-DXIL compiler that we
contribute to Mesa and that is also used by above OpenGL layer.

As we are using spirv-to-nir in our OpenCL compiler, we have
implemented some missing OpenCL-specific features there as well. In
addition, we are also carrying some out-of-tree changes from other mesa
contributors, where we also contribute reviews of in order to help them
land.

Our work also includes contributing, improving, and maintaining the CI
for Windows, to be run on a variety of supported Windows targets.
Currently, Collabora is providing a Windows GitLab CI runner in order
to run our builds. We are looking into integrating this into fd.o's
general fleet of shared runners.

A high-performance DXGI libgl-target/winsys is also in the works, so we
can render directly into Windows' compositor surfaces. In theory, and
as a benefit to the wider Mesa community, other hardware driver could
be ported to support rendering into those surfaces as well.

As part of this work and thanks to Microsoft's support, the WGL header
files are being re-licensed as MIT, so we can reuse these original
headers rather than a reverse-engineered copy. Patches for this will
follow soon.

A dump of the code in its current state can be found here:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fkusma%2Fmesa%2F-%2Ftree%2Fmsclc-d3d12data=02%7C01%7Cjfonseca%40vmware.com%7C1fbe982d5e534ff7eb6308d7d011dac7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637206647447892216sdata=iozk7RT5jnXweFeM8dlcizCvs020obG0aPZHReVAMlw%3Dreserved=0
and we intend to upstream this code by breaking it into independent
MRs shortly.

We hope you're all as excited about this as we are!

Gert Wollny, on behalf of the Microsoft development team (Bill
Kristiansen and Jesse Natalie) and the Collabora development team
(Boris Brezillon, Daniel Stone, Elie Tournier, Erik Faye-Lund, Louis-
Francis Ratté-Boulianne)


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cjfonseca%40vmware.com%7C1fbe982d5e534ff7eb6308d7d011dac7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637206647447892216sdata=RLRF0ByyMp9HU0EdplrenaAU6s1ew9oIQtrn%2BOd8Ym4%3Dreserved=0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Meson links with duplicate symbols

[Jose Fonseca]

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4186


From: Jose Fonseca 
Sent: Tuesday, March 10, 2020 17:20
To: ML mesa-dev 
Cc: Neha Bhende ; Dylan Baker 
Subject: Re: Meson links with duplicate symbols

I figured out enough of Meson to workout a fix.  I'll post it for review 
tomorrow (after I figure out what's the exact process for a MR.)

Jose


From: Jose Fonseca
Sent: Friday, March 6, 2020 15:08
To: ML mesa-dev ; Dylan Baker 

Cc: Neha Bhende 
Subject: Meson links with duplicate symbols

While reviewing my colleagues efforts to consume Meson for Windows I stumbled 
across two issues.

First is that even though we added the "WARNING: Scons support is in the 
process of being deprecated on on windows platforms (including mingw). If you 
haven't already please try using meson for windows builds. Be sure to report 
any issues you run into" to scons, we didn't update mesa/docs/install.html with 
instructions on how to build Meson w/ Mingw for windows, so it's not obvious to 
a newbie how to do it.  It took me quite a while to reverse engineer the stuff 
in .gitlab-ci/... till I figured out the way to do it.  I think that adding 
example command lines would go a long way.

Second and most important is that Meson is actually linking with duplicate 
symbols.  This was being hidden because meson doesn't use whole linking for 
everything, whereas SCons does.  It's easy to repro:

$ git diff
diff --git a/src/gallium/targets/libgl-gdi/meson.build 
b/src/gallium/targets/libgl-gdi/meson.build
index cd4e02d1fa9..fb8a42439c8 100644
--- a/src/gallium/targets/libgl-gdi/meson.build
+++ b/src/gallium/targets/libgl-gdi/meson.build
@@ -33,10 +33,8 @@ libopengl32 = shared_library(
   include_directories : [
 inc_common, inc_wgl, inc_gallium_winsys_sw, inc_gallium_drivers,
   ],
-  link_whole : [libwgl],
-  link_with : [
-libgallium, libglsl, libmesa_gallium, libwsgdi, libglapi_static, libglapi
-  ],
+  link_whole : [libwgl, libgallium, libglsl, libmesa_gallium, libwsgdi, 
libglapi_static, libglapi],
+  link_with : [],
   dependencies : [
 dep_ws2_32, idep_nir, idep_mesautil, driver_swrast, driver_swr,
   ],
$ meson --cross .gitlab-ci/x86_64-w64-mingw32 . build/meson-windows-x86_64-debug
$ ninja -C build/meson-windows-x86_64-debug/
ninja: Entering directory `build/meson-windows-x86_64-debug/'
[2/2] Linking target src/gallium/targets/libgl-gdi/opengl32.dll.
FAILED: src/gallium/targets/libgl-gdi/opengl32.dll
x86_64-w64-mingw32-g++  -o src/gallium/targets/libgl-gdi/opengl32.dll 
'src/gallium/targets/libgl-gdi/c96d1e6@@opengl32@sha/libgl_gdi.c.obj' 
-Wl,--allow-shlib-undefined -shared 
../../src/gallium/targets/libgl-gdi/../../state_trackers/wgl/opengl32.def 
-Wl,--start-group -Wl,--out-implib=src/gallium/targets/libgl-gdi/opengl32.dll.a 
-Wl,--whole-archive src/gallium/state_trackers/wgl/libwgl.a 
src/gallium/auxiliary/libgallium.a src/compiler/glsl/libglsl.a 
src/mesa/libmesa_gallium.a src/gallium/winsys/sw/gdi/libwsgdi.a 
src/mapi/glapi/libglapi_static.a -Wl,--no-whole-archive -Wl,--nxcompat 
-Wl,--dynamicbase -static-libgcc -static-libstdc++ src/compiler/nir/libnir.a 
src/compiler/libcompiler.a src/util/libmesa_util.a 
src/util/format/libmesa_format.a subprojects/zlib-1.2.11/libz.dll.a 
src/gallium/drivers/softpipe/libsoftpipe.a src/compiler/glsl/glcpp/libglcpp.a 
src/mesa/libmesa_common.a src/mesa/libmesa_sse41.a -lws2_32 -pthread -lm 
-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid 
-lcomdlg32 -ladvapi32 -Wl,--end-group
src/mesa/libmesa_common.a(main_shaderapi.c.obj): In function 
`_mesa_get_shader_include_cursor':
/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/mesa/main/shaderapi.c:3185:
 multiple definition of `_mesa_get_shader_include_cursor'
src/compiler/glsl/glcpp/libglcpp.a(pp_standalone_scaffolding.c.obj):/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/compiler/glsl/glcpp/pp_standalone_scaffolding.c:49:
 first defined here
src/mesa/libmesa_common.a(main_shaderapi.c.obj): In function 
`_mesa_set_shader_include_cursor':
/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/mesa/main/shaderapi.c:3191:
 multiple definition of `_mesa_set_shader_include_cursor'
src/compiler/glsl/glcpp/libglcpp.a(pp_standalone_scaffolding.c.obj):/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/compiler/glsl/glcpp/pp_standalone_scaffolding.c:57:
 first defined here
src/mesa/libmesa_common.a(main_shaderapi.c.obj): In function 
`_mesa_lookup_shader_include':
/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/mesa/main/shaderapi.c:3404:
 multiple definition of `_mesa_lookup_shader_include'
src/compiler/glsl/glcpp/libglcpp.a(pp_standalone_scaffolding.c.obj):/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/compiler/

Re: [Mesa-dev] Meson links with duplicate symbols

[Jose Fonseca]

I figured out enough of Meson to workout a fix.  I'll post it for review 
tomorrow (after I figure out what's the exact process for a MR.)

Jose


From: Jose Fonseca
Sent: Friday, March 6, 2020 15:08
To: ML mesa-dev ; Dylan Baker 

Cc: Neha Bhende 
Subject: Meson links with duplicate symbols

While reviewing my colleagues efforts to consume Meson for Windows I stumbled 
across two issues.

First is that even though we added the "WARNING: Scons support is in the 
process of being deprecated on on windows platforms (including mingw). If you 
haven't already please try using meson for windows builds. Be sure to report 
any issues you run into" to scons, we didn't update mesa/docs/install.html with 
instructions on how to build Meson w/ Mingw for windows, so it's not obvious to 
a newbie how to do it.  It took me quite a while to reverse engineer the stuff 
in .gitlab-ci/... till I figured out the way to do it.  I think that adding 
example command lines would go a long way.

Second and most important is that Meson is actually linking with duplicate 
symbols.  This was being hidden because meson doesn't use whole linking for 
everything, whereas SCons does.  It's easy to repro:

$ git diff
diff --git a/src/gallium/targets/libgl-gdi/meson.build 
b/src/gallium/targets/libgl-gdi/meson.build
index cd4e02d1fa9..fb8a42439c8 100644
--- a/src/gallium/targets/libgl-gdi/meson.build
+++ b/src/gallium/targets/libgl-gdi/meson.build
@@ -33,10 +33,8 @@ libopengl32 = shared_library(
   include_directories : [
 inc_common, inc_wgl, inc_gallium_winsys_sw, inc_gallium_drivers,
   ],
-  link_whole : [libwgl],
-  link_with : [
-libgallium, libglsl, libmesa_gallium, libwsgdi, libglapi_static, libglapi
-  ],
+  link_whole : [libwgl, libgallium, libglsl, libmesa_gallium, libwsgdi, 
libglapi_static, libglapi],
+  link_with : [],
   dependencies : [
 dep_ws2_32, idep_nir, idep_mesautil, driver_swrast, driver_swr,
   ],
$ meson --cross .gitlab-ci/x86_64-w64-mingw32 . build/meson-windows-x86_64-debug
$ ninja -C build/meson-windows-x86_64-debug/
ninja: Entering directory `build/meson-windows-x86_64-debug/'
[2/2] Linking target src/gallium/targets/libgl-gdi/opengl32.dll.
FAILED: src/gallium/targets/libgl-gdi/opengl32.dll
x86_64-w64-mingw32-g++  -o src/gallium/targets/libgl-gdi/opengl32.dll 
'src/gallium/targets/libgl-gdi/c96d1e6@@opengl32@sha/libgl_gdi.c.obj' 
-Wl,--allow-shlib-undefined -shared 
../../src/gallium/targets/libgl-gdi/../../state_trackers/wgl/opengl32.def 
-Wl,--start-group -Wl,--out-implib=src/gallium/targets/libgl-gdi/opengl32.dll.a 
-Wl,--whole-archive src/gallium/state_trackers/wgl/libwgl.a 
src/gallium/auxiliary/libgallium.a src/compiler/glsl/libglsl.a 
src/mesa/libmesa_gallium.a src/gallium/winsys/sw/gdi/libwsgdi.a 
src/mapi/glapi/libglapi_static.a -Wl,--no-whole-archive -Wl,--nxcompat 
-Wl,--dynamicbase -static-libgcc -static-libstdc++ src/compiler/nir/libnir.a 
src/compiler/libcompiler.a src/util/libmesa_util.a 
src/util/format/libmesa_format.a subprojects/zlib-1.2.11/libz.dll.a 
src/gallium/drivers/softpipe/libsoftpipe.a src/compiler/glsl/glcpp/libglcpp.a 
src/mesa/libmesa_common.a src/mesa/libmesa_sse41.a -lws2_32 -pthread -lm 
-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid 
-lcomdlg32 -ladvapi32 -Wl,--end-group
src/mesa/libmesa_common.a(main_shaderapi.c.obj): In function 
`_mesa_get_shader_include_cursor':
/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/mesa/main/shaderapi.c:3185:
 multiple definition of `_mesa_get_shader_include_cursor'
src/compiler/glsl/glcpp/libglcpp.a(pp_standalone_scaffolding.c.obj):/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/compiler/glsl/glcpp/pp_standalone_scaffolding.c:49:
 first defined here
src/mesa/libmesa_common.a(main_shaderapi.c.obj): In function 
`_mesa_set_shader_include_cursor':
/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/mesa/main/shaderapi.c:3191:
 multiple definition of `_mesa_set_shader_include_cursor'
src/compiler/glsl/glcpp/libglcpp.a(pp_standalone_scaffolding.c.obj):/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/compiler/glsl/glcpp/pp_standalone_scaffolding.c:57:
 first defined here
src/mesa/libmesa_common.a(main_shaderapi.c.obj): In function 
`_mesa_lookup_shader_include':
/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/mesa/main/shaderapi.c:3404:
 multiple definition of `_mesa_lookup_shader_include'
src/compiler/glsl/glcpp/libglcpp.a(pp_standalone_scaffolding.c.obj):/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/compiler/glsl/glcpp/pp_standalone_scaffolding.c:41:
 first defined here
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

I think this is wrong.  We shouldn't be relying on carefully crafting the order 
of linker arguments to pick the ri

[Mesa-dev] Meson links with duplicate symbols

[Jose Fonseca]

While reviewing my colleagues efforts to consume Meson for Windows I stumbled 
across two issues.

First is that even though we added the "WARNING: Scons support is in the 
process of being deprecated on on windows platforms (including mingw). If you 
haven't already please try using meson for windows builds. Be sure to report 
any issues you run into" to scons, we didn't update mesa/docs/install.html with 
instructions on how to build Meson w/ Mingw for windows, so it's not obvious to 
a newbie how to do it.  It took me quite a while to reverse engineer the stuff 
in .gitlab-ci/... till I figured out the way to do it.  I think that adding 
example command lines would go a long way.

Second and most important is that Meson is actually linking with duplicate 
symbols.  This was being hidden because meson doesn't use whole linking for 
everything, whereas SCons does.  It's easy to repro:

$ git diff
diff --git a/src/gallium/targets/libgl-gdi/meson.build 
b/src/gallium/targets/libgl-gdi/meson.build
index cd4e02d1fa9..fb8a42439c8 100644
--- a/src/gallium/targets/libgl-gdi/meson.build
+++ b/src/gallium/targets/libgl-gdi/meson.build
@@ -33,10 +33,8 @@ libopengl32 = shared_library(
   include_directories : [
 inc_common, inc_wgl, inc_gallium_winsys_sw, inc_gallium_drivers,
   ],
-  link_whole : [libwgl],
-  link_with : [
-libgallium, libglsl, libmesa_gallium, libwsgdi, libglapi_static, libglapi
-  ],
+  link_whole : [libwgl, libgallium, libglsl, libmesa_gallium, libwsgdi, 
libglapi_static, libglapi],
+  link_with : [],
   dependencies : [
 dep_ws2_32, idep_nir, idep_mesautil, driver_swrast, driver_swr,
   ],
$ meson --cross .gitlab-ci/x86_64-w64-mingw32 . build/meson-windows-x86_64-debug
$ ninja -C build/meson-windows-x86_64-debug/
ninja: Entering directory `build/meson-windows-x86_64-debug/'
[2/2] Linking target src/gallium/targets/libgl-gdi/opengl32.dll.
FAILED: src/gallium/targets/libgl-gdi/opengl32.dll
x86_64-w64-mingw32-g++  -o src/gallium/targets/libgl-gdi/opengl32.dll 
'src/gallium/targets/libgl-gdi/c96d1e6@@opengl32@sha/libgl_gdi.c.obj' 
-Wl,--allow-shlib-undefined -shared 
../../src/gallium/targets/libgl-gdi/../../state_trackers/wgl/opengl32.def 
-Wl,--start-group -Wl,--out-implib=src/gallium/targets/libgl-gdi/opengl32.dll.a 
-Wl,--whole-archive src/gallium/state_trackers/wgl/libwgl.a 
src/gallium/auxiliary/libgallium.a src/compiler/glsl/libglsl.a 
src/mesa/libmesa_gallium.a src/gallium/winsys/sw/gdi/libwsgdi.a 
src/mapi/glapi/libglapi_static.a -Wl,--no-whole-archive -Wl,--nxcompat 
-Wl,--dynamicbase -static-libgcc -static-libstdc++ src/compiler/nir/libnir.a 
src/compiler/libcompiler.a src/util/libmesa_util.a 
src/util/format/libmesa_format.a subprojects/zlib-1.2.11/libz.dll.a 
src/gallium/drivers/softpipe/libsoftpipe.a src/compiler/glsl/glcpp/libglcpp.a 
src/mesa/libmesa_common.a src/mesa/libmesa_sse41.a -lws2_32 -pthread -lm 
-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid 
-lcomdlg32 -ladvapi32 -Wl,--end-group
src/mesa/libmesa_common.a(main_shaderapi.c.obj): In function 
`_mesa_get_shader_include_cursor':
/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/mesa/main/shaderapi.c:3185:
 multiple definition of `_mesa_get_shader_include_cursor'
src/compiler/glsl/glcpp/libglcpp.a(pp_standalone_scaffolding.c.obj):/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/compiler/glsl/glcpp/pp_standalone_scaffolding.c:49:
 first defined here
src/mesa/libmesa_common.a(main_shaderapi.c.obj): In function 
`_mesa_set_shader_include_cursor':
/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/mesa/main/shaderapi.c:3191:
 multiple definition of `_mesa_set_shader_include_cursor'
src/compiler/glsl/glcpp/libglcpp.a(pp_standalone_scaffolding.c.obj):/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/compiler/glsl/glcpp/pp_standalone_scaffolding.c:57:
 first defined here
src/mesa/libmesa_common.a(main_shaderapi.c.obj): In function 
`_mesa_lookup_shader_include':
/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/mesa/main/shaderapi.c:3404:
 multiple definition of `_mesa_lookup_shader_include'
src/compiler/glsl/glcpp/libglcpp.a(pp_standalone_scaffolding.c.obj):/home/jfonseca/work/vmware/opengl/mesa/build/meson-windows-x86_64-debug/../../src/compiler/glsl/glcpp/pp_standalone_scaffolding.c:41:
 first defined here
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

I think this is wrong.  We shouldn't be relying on carefully crafting the order 
of linker arguments to pick the right symbol.  There should be one and one 
instance of every symbol.

I suppose the pp_standalone_scaffolding module should only be used when glsl is 
built as a command line tool no?

Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

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

[Jose Fonseca]

We already solved some pieces (e.g, how to consume and use Meson, while 
following our internal legal process required for adding new 3rd party 
dependencies), and figured a way to consume Meson build without having to 
migrate lots of internal build logic from Scons to Meson.  But other stuff just 
keeps getting higher priority, and we haven't fully migrated.

Please do understand, SCons just works for us.  We are making progress with 
Meson.  It's just not the highest priority, when time is short, it gets 
deferred.

I don't understand the rush.  If it was trivial and easy we'd obviously would 
have done it.

Jose


From: Jason Ekstrand 
Sent: Wednesday, February 26, 2020 04:15
To: Rob Clark ; Kristian Høgsberg 
Cc: mesa-dev ; Dylan Baker 
; Jose Fonseca ; Brian Paul 

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

+Jose & Brian

I'm not personally opposed but I also can't remember the last time I had to
fix the scons build. I think it's been years. Maybe that's because I don't
work on GL anymore? In any case, I don't know that it's really costing us
that much given that basically none of the drivers actually build with it.
But fat meh, I guess.

--Jason

On February 25, 2020 21:56:30 Rob Clark  wrote:

> It looks like we have 4 scons build jobs in CI.. I'm not sure how much
> that costs us, but I guess those cycles could be put to better use?
> So even ignoring the developer-cycles issue (ie. someone making
> changes that effects scons build, and has to setup a scons build env
> to fix breakage of their MR) I guess there is at least an argument to
> remove scons from CI.  Whether it is worth keeping a dead build system
> after it is removed from CI is an issue that I'm ambivalent about.
>
> BR,
> -R
>
> 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?
>>
>> Kristian
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cjfonseca%40vmware.com%7Cc8b86d6f312c48d77f3c08d7ba72774f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637182873108493719sdata=oKvqrkRoo6%2FqGW5BWbe1exIcBF%2BI%2BblcWIIVo3iW9J0%3Dreserved=0
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cjfonseca%40vmware.com%7Cc8b86d6f312c48d77f3c08d7ba72774f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637182873108493719sdata=oKvqrkRoo6%2FqGW5BWbe1exIcBF%2BI%2BblcWIIVo3iW9J0%3Dreserved=0



___
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?

[Jose Fonseca]

> but it bothers me how we keep not making a decision on this. If we'd said, 
> "let's keep it and support it", that would something.

I'm surprised there's any doubt.

SCons works great for us.   Meson gives no immediate benefit for us other than 
headaches.  If we cared about nothing but ourselves, we'd keep SCons 
indefinitely, until it became a pain.

The only reason we don't stubbornly put the foot down is that we understand 
that having one single build system would be beneficial the whole community, 
and of course we appreciate all the work Dylan and others did to get Meson to 
work on Windows, so we'd like to get there one day.

That said, I don't understand why the rest of the Mesa community putting a gun 
against our head to abandon SCons.

Aren't we maintaining the SCons build?  Since when in Mesa community are some 
entitled to start remove code that still works, is used, and maintained by 
others

Jose


From: Kristian Høgsberg 
Sent: Wednesday, February 26, 2020 18:37
To: Jason Ekstrand 
Cc: Rob Clark ; mesa-dev ; 
Dylan Baker ; Jose Fonseca ; 
Brian Paul 
Subject: Re: [Mesa-dev] Drop scons for 20.1?

On Tue, Feb 25, 2020 at 8:15 PM Jason Ekstrand  wrote:
>
> +Jose & Brian
>
> I'm not personally opposed but I also can't remember the last time I had to
> fix the scons build. I think it's been years. Maybe that's because I don't
> work on GL anymore? In any case, I don't know that it's really costing us
> that much given that basically none of the drivers actually build with it.
> But fat meh, I guess.

Maybe it is a bit meh... I did the MR to remove SCons and it's smaller
that I thought it would be:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F3955data=02%7C01%7Cjfonseca%40vmware.com%7C6b2e8f2abc98458d18ad08d7baeb0443%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637183390863817583sdata=96lM4flW9ja6fJG95nlNdmftNiYpajxpg0Il850%2FDLk%3Dreserved=0

but it bothers me how we keep not making a decision on this. If we'd
said, "let's keep it and support it", that would something. But
whenever it comes up, Dylan maybe fixes something on the windows
build, we talk about trying to switch Windows to meson and then...
nothing.

Also, we've had this unfortunate split between Linux and Windows build
systems where autotools suck on Windows and nobody on Unix ever had a
reason to use SCons.  With meson we've picked something that's a
legitimate improvement on both sides, get's us back to one build
system and done more than due dilligence to make it work on Windows
and we're not taking the last step because... meh?

Kristian

> --Jason
>
> On February 25, 2020 21:56:30 Rob Clark  wrote:
>
> > It looks like we have 4 scons build jobs in CI.. I'm not sure how much
> > that costs us, but I guess those cycles could be put to better use?
> > So even ignoring the developer-cycles issue (ie. someone making
> > changes that effects scons build, and has to setup a scons build env
> > to fix breakage of their MR) I guess there is at least an argument to
> > remove scons from CI.  Whether it is worth keeping a dead build system
> > after it is removed from CI is an issue that I'm ambivalent about.
> >
> > BR,
> > -R
> >
> > 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?
> >>
> >> Kristian
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cjfonseca%40vmware.com%7C6b2e8f2abc98458d18ad08d7baeb0443%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637183390863817583sdata=d40ceGVLhyahNydLEZ55P7hgjqeLtIOMKN6J0NPmfwE%3Dreserved=0
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cjfonseca%40vmware.com%7C6b2e8f2abc98458d18ad08d7baeb0443%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637183390863817583sdata=d40ceGVLhyahNydLEZ55P7hgjqeLtIOMKN6J0NPmfwE%3Dreserved=0
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] size of LP_MAX_VBUF_SIZE

[Jose Fonseca]

I tried to track down that define in git history, but there weren't many clues. 
 That define seems to go all the way back to softpipe (see `#define 
SP_MAX_VBUF_SIZE4096` on src/gallium/drivers/softpipe/sp_prim_vbuf.c added 
on 
https://gitlab.freedesktop.org/mesa/mesa/commit/2d37e78e636e5e1e7d5d00230e50a00f7a71e868
 .  At that time before softpipe had 64K, i915 had 16K and then softpipe got 
4K, which llvmpipe eventually inherited.

I believe it's as Roland said -- probably smaller sizes were empirically shown 
to be better.  I recall that a lot of effort had went on making SW TNL fast 
around that time, for Intel Poulsbo IIRC (because the GPU was so under-powered 
that using the CPU for VS allowed for everything to run faster!)  The issue was 
not just the final vertex buffer size, but also forcing a small batch of 
vertices through the draw pipeline, which was quite deep, at least then, where 
every stage of the pipeline would sweep over all the vertices, and most of the 
stages were hand written C.

I think that nowadays, at least with llvmpipe, the draw pipeline is less deep, 
as a lot of what were discrete pipeline stages (e.g, clipping and final 
emission) are actually compiled in into the JITted VS.  So I'd imagine llvmpipe 
(or anything that uses draw w/ LLVM) should now be able to sustain much larger 
batches without trashing the caches.

IIRC, mesademos' ipers/engine/fire (don't recall exactly which) were the sort 
of thing people used to fine tune this sort of thing.  There are probably 
better benchmarks nowadays though.

Jose


From: Roland Scheidegger 
Sent: Thursday, February 20, 2020 17:27
To: Dave Airlie ; mesa-dev 
Cc: Jose Fonseca 
Subject: Re: size of LP_MAX_VBUF_SIZE

Am 20.02.20 um 02:45 schrieb Dave Airlie:
> Hey,
>
> Anyone know why LP_MAX_VBUF_SIZE is only 4K?
>
> Tess submits > 100K verts to the draw pipeline, which start to split
> them, due to the 4K size of the above it splits 50 vertices per vbuf,
> however it then calls draw_reset_vertex_ids which iterates over all
> 100K vertices each time.
>
> I might try fixing the reset, but I wondered why this was only sending
> 50 vertices at a time to the rasterizer.
>
> Dave.
>

Dave,

I don't recall, I think this even predates me working on llvmpipe...
That said, I think in general splitting into smaller chunks is done so
things are more cache friendly (though the limit is so low it would fit
into l1 cache even back then...). And probably the overhead of invoking
things multiple times just wasn't all that large compared to the
execution time of the vs (and the setup code in llvmpipe).
I don't know if that was actually measured though at some point, and it
is quite possible the average vertex size got quite a bit larger since
then (hence max vertices per split lower), as everything was geared
towards quite simple apps back then.

So I think increasing the limit is probably quite fine, but splitting
still needs to work correctly.

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

Re: [Mesa-dev] [PATCH] util/atomic: Fix p_atomic_add for unlocked and msvc paths

[Jose Fonseca]

Reviewed-by: Jose Fonseca 


From: srol...@vmware.com 
Sent: Monday, December 9, 2019 17:49
To: Jose Fonseca ; ja...@jlekstrand.net 
; mesa-dev@lists.freedesktop.org 

Cc: Roland Scheidegger 
Subject: [PATCH] util/atomic: Fix p_atomic_add for unlocked and msvc paths

From: Roland Scheidegger 

Braces mismatch (flagged by CI, untested).

Fixes: 385d13f26d2 "util/atomic: Add a _return variant of p_atomic_add"
---
 src/util/u_atomic.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h
index 9cbc6dd1eaa..1ad87c8feb1 100644
--- a/src/util/u_atomic.h
+++ b/src/util/u_atomic.h
@@ -89,7 +89,7 @@
 #define p_atomic_dec_zero(_v) (p_atomic_dec_return(_v) == 0)
 #define p_atomic_inc(_v) ((void) p_atomic_inc_return(_v))
 #define p_atomic_dec(_v) ((void) p_atomic_dec_return(_v))
-#define p_atomic_add(_v, _i) ((void) p_atomic_add_return((_v), (_i))
+#define p_atomic_add(_v, _i) ((void) p_atomic_add_return((_v), (_i)))
 #define p_atomic_inc_return(_v) (++(*(_v)))
 #define p_atomic_dec_return(_v) (--(*(_v)))
 #define p_atomic_add_return(_v, _i) (*(_v) = *(_v) + (_i))
@@ -146,7 +146,7 @@
  (assert(!"should not get here"), 0))

 #define p_atomic_add(_v, _i) \
-   ((void) p_atomic_add_return((_v), (_i))
+   ((void) p_atomic_add_return((_v), (_i)))

 #define p_atomic_add_return(_v, _i) (\
sizeof *(_v) == sizeof(char)? _InterlockedExchangeAdd8 ((char *)   
(_v), (_i)) : \
--
2.17.1

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

[Mesa-dev] [PATCH] scons: Fix force_scons parsing.

[Jose Fonseca]

- Use parsed options instead of using ARGUMENTS directly.
- Handle case mingw cross compilation.
---
 SConstruct | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/SConstruct b/SConstruct
index 61a915f7deb..f905189dd9e 100644
--- a/SConstruct
+++ b/SConstruct
@@ -71,9 +71,8 @@ Help(opts.GenerateHelpText(env))
 ###
 # Print a deprecation warning for using scons on non-windows
 
-if common.host_platform != 'windows':
-force = ARGUMENTS['force_scons']
-if force.lower() not in {'false', 'off', 'none', '0', 'n'}:
+if common.host_platform != 'windows' and env['platform'] != 'windows':
+if env['force_scons']:
 print("WARNING: Scons is deprecated for non-windows platforms 
(including cygwin) "
   "please use meson instead.", file=sys.stderr)
 else:
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH] gallivm: Fix saturated signed psub/padd intrinsics on llvm 8

[Jose Fonseca]

Looks good.

Reviewed-by: Jose Fonseca 


From: srol...@vmware.com 
Sent: Thursday, October 17, 2019 03:20
To: Jose Fonseca ; airl...@freedesktop.org 
; mesa-dev@lists.freedesktop.org 

Cc: Roland Scheidegger ; mesa-sta...@lists.freedesktop.org 

Subject: [PATCH] gallivm: Fix saturated signed psub/padd intrinsics on llvm 8

From: Roland Scheidegger 

LLVM 8 did remove both the signed and unsigned sse2/avx intrinsics in
the end, and provide arch-independent llvm intrinsics instead.
Fixes a crash when using snorm framebuffers (tested with piglit
arb_color_buffer_float-render GL_RGBA8_SNORM -auto).

CC: 
---
 src/gallium/auxiliary/gallivm/lp_bld_arit.c | 28 -
 1 file changed, 10 insertions(+), 18 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c 
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index 6b7ce9aacf9..53ee00e6767 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
@@ -465,7 +465,7 @@ lp_build_add(struct lp_build_context *bld,
 return bld->one;

   if (!type.floating && !type.fixed) {
- if (LLVM_VERSION_MAJOR >= 9) {
+ if (LLVM_VERSION_MAJOR >= 8) {
 char intrin[32];
 intrinsic = type.sign ? "llvm.sadd.sat" : "llvm.uadd.sat";
 lp_format_intrinsic(intrin, sizeof intrin, intrinsic, 
bld->vec_type);
@@ -474,11 +474,9 @@ lp_build_add(struct lp_build_context *bld,
  if (type.width * type.length == 128) {
 if (util_cpu_caps.has_sse2) {
if (type.width == 8)
- intrinsic = type.sign ? "llvm.x86.sse2.padds.b" :
- LLVM_VERSION_MAJOR < 8 ? 
"llvm.x86.sse2.paddus.b" : NULL;
+ intrinsic = type.sign ? "llvm.x86.sse2.padds.b" : 
"llvm.x86.sse2.paddus.b";
if (type.width == 16)
- intrinsic = type.sign ? "llvm.x86.sse2.padds.w" :
- LLVM_VERSION_MAJOR < 8 ? 
"llvm.x86.sse2.paddus.w" : NULL;
+ intrinsic = type.sign ? "llvm.x86.sse2.padds.w" : 
"llvm.x86.sse2.paddus.w";
 } else if (util_cpu_caps.has_altivec) {
if (type.width == 8)
   intrinsic = type.sign ? "llvm.ppc.altivec.vaddsbs" : 
"llvm.ppc.altivec.vaddubs";
@@ -489,11 +487,9 @@ lp_build_add(struct lp_build_context *bld,
  if (type.width * type.length == 256) {
 if (util_cpu_caps.has_avx2) {
if (type.width == 8)
-  intrinsic = type.sign ? "llvm.x86.avx2.padds.b" :
-  LLVM_VERSION_MAJOR < 8 ? 
"llvm.x86.avx2.paddus.b" : NULL;
+  intrinsic = type.sign ? "llvm.x86.avx2.padds.b" : 
"llvm.x86.avx2.paddus.b";
if (type.width == 16)
-  intrinsic = type.sign ? "llvm.x86.avx2.padds.w" :
-  LLVM_VERSION_MAJOR < 8 ? 
"llvm.x86.avx2.paddus.w" : NULL;
+  intrinsic = type.sign ? "llvm.x86.avx2.padds.w" : 
"llvm.x86.avx2.paddus.w";
 }
  }
   }
@@ -793,7 +789,7 @@ lp_build_sub(struct lp_build_context *bld,
 return bld->zero;

   if (!type.floating && !type.fixed) {
- if (LLVM_VERSION_MAJOR >= 9) {
+ if (LLVM_VERSION_MAJOR >= 8) {
 char intrin[32];
 intrinsic = type.sign ? "llvm.ssub.sat" : "llvm.usub.sat";
 lp_format_intrinsic(intrin, sizeof intrin, intrinsic, 
bld->vec_type);
@@ -802,11 +798,9 @@ lp_build_sub(struct lp_build_context *bld,
  if (type.width * type.length == 128) {
 if (util_cpu_caps.has_sse2) {
if (type.width == 8)
-  intrinsic = type.sign ? "llvm.x86.sse2.psubs.b" :
-  LLVM_VERSION_MAJOR < 8 ? 
"llvm.x86.sse2.psubus.b" : NULL;
+  intrinsic = type.sign ? "llvm.x86.sse2.psubs.b" : 
"llvm.x86.sse2.psubus.b";
if (type.width == 16)
-  intrinsic = type.sign ? "llvm.x86.sse2.psubs.w" :
-  LLVM_VERSION_MAJOR < 8 ? 
"llvm.x86.sse2.psubus.w" : NULL;
+  intrinsic = type.sign ? "llvm.x86.sse2.psubs.w" : 
"llvm.x86.sse2.psubus.w";
 } else if (util_cpu_caps.has_altivec) {
if (type.width == 8)
   intrinsic = type.sign ? "llvm.ppc.altivec.vsubsbs" : 
"llvm.ppc.altivec.vsububs";
@@ -817,11 +811,9 @@ lp_build_sub(struct lp_build_context *bld,
  if (t

Re: [Mesa-dev] [PATCH] llvmpipe: increase max texture size to 2GB

[Jose Fonseca]

Sounds great.

Reviewed-by: Jose Fonseca 

BTW, it's not really difficult to do gather with unsigned offsets: add 
0x8000 to the base, subtract 0x800 to the offsets, and use the signed 
gather.   If the cost of doing so is significant, we could do this just for 
large textures, by adding a bit per texture to the shader key.

Jose



From: srol...@vmware.com 
Sent: Thursday, October 10, 2019 19:18
To: Jose Fonseca ; mesa-dev@lists.freedesktop.org 

Cc: Roland Scheidegger 
Subject: [PATCH] llvmpipe: increase max texture size to 2GB

From: Roland Scheidegger 

The 1GB limit was arbitrary, increase this to 2GB (which is the max
possible without code changes).
---
 src/gallium/drivers/llvmpipe/lp_limits.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_limits.h 
b/src/gallium/drivers/llvmpipe/lp_limits.h
index c2808162c78..569179ecdf4 100644
--- a/src/gallium/drivers/llvmpipe/lp_limits.h
+++ b/src/gallium/drivers/llvmpipe/lp_limits.h
@@ -43,7 +43,11 @@
 /**
  * Max texture sizes
  */
-#define LP_MAX_TEXTURE_SIZE (1 * 1024 * 1024 * 1024ULL)  /* 1GB for now */
+/**
+ * 2GB is the actual max currently (we always use 32bit offsets, and both
+ * llvm GEP as well as avx2 gather use signed offsets).
+ */
+#define LP_MAX_TEXTURE_SIZE (2 * 1024 * 1024 * 1024ULL)
 #define LP_MAX_TEXTURE_2D_LEVELS 14  /* 8K x 8K for now */
 #define LP_MAX_TEXTURE_3D_LEVELS 12  /* 2K x 2K x 2K for now */
 #define LP_MAX_TEXTURE_CUBE_LEVELS 14  /* 8K x 8K for now */
--
2.17.1

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

Re: [Mesa-dev] [PATCH] llvmpipe: fix CALLOC vs. free mismatches

[Jose Fonseca]

Reviewed-by: Jose Fonseca 


From: srol...@vmware.com 
Sent: Friday, September 6, 2019 03:13
To: Jose Fonseca ; airl...@redhat.com 
; mesa-dev@lists.freedesktop.org 

Cc: Roland Scheidegger 
Subject: [PATCH] llvmpipe: fix CALLOC vs. free mismatches

From: Roland Scheidegger 

Should fix some issues we're seeing. And use REALLOC instead of realloc.
---
 src/gallium/drivers/llvmpipe/lp_cs_tpool.c | 6 +++---
 src/gallium/drivers/llvmpipe/lp_state_cs.c | 3 ++-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_cs_tpool.c 
b/src/gallium/drivers/llvmpipe/lp_cs_tpool.c
index 04495727e1c..6f1b4e2ee55 100644
--- a/src/gallium/drivers/llvmpipe/lp_cs_tpool.c
+++ b/src/gallium/drivers/llvmpipe/lp_cs_tpool.c
@@ -65,7 +65,7 @@ lp_cs_tpool_worker(void *data)
  cnd_broadcast(>finish);
}
mtx_unlock(>m);
-   free(lmem.local_mem_ptr);
+   FREE(lmem.local_mem_ptr);
return 0;
 }

@@ -105,7 +105,7 @@ lp_cs_tpool_destroy(struct lp_cs_tpool *pool)

cnd_destroy(>new_work);
mtx_destroy(>m);
-   free(pool);
+   FREE(pool);
 }

 struct lp_cs_tpool_task *
@@ -148,6 +148,6 @@ lp_cs_tpool_wait_for_task(struct lp_cs_tpool *pool,
mtx_unlock(>m);

cnd_destroy(>finish);
-   free(task);
+   FREE(task);
*task_handle = NULL;
 }
diff --git a/src/gallium/drivers/llvmpipe/lp_state_cs.c 
b/src/gallium/drivers/llvmpipe/lp_state_cs.c
index 1645a185cb2..a26cbf4df22 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_cs.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_cs.c
@@ -1123,8 +1123,9 @@ cs_exec_fn(void *init_data, int iter_idx, struct 
lp_cs_local_mem *lmem)
memset(_data, 0, sizeof(thread_data));

if (lmem->local_size < job_info->req_local_mem) {
+  lmem->local_mem_ptr = REALLOC(lmem->local_mem_ptr, lmem->local_size,
+job_info->req_local_mem);
   lmem->local_size = job_info->req_local_mem;
-  lmem->local_mem_ptr = realloc(lmem->local_mem_ptr, lmem->local_size);
}
thread_data.shared = lmem->local_mem_ptr;

--
2.17.1

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

Re: [Mesa-dev] [PATCH] gallivm: use fallback code for mul_hi with llvm >= 7.0

[Jose Fonseca]

This change is

  Reviewed-by: Jose Fonseca 

Regarding follow up change, do you think the LLVM pattern is sane/doable?

If not we should try ask them to reconsider relying strictly upon pattern 
matching.  I get the feeling upstream LLVM is throwing the baby with the water 
with these changes.  I do understand the advantages of moving away from vendor 
specific intrinsics, but I think that for things which have no natural 
representation on LLVM base IR, they should add a vendor-agnostic intrinsic, 
for example a new "llvm.mulhi.*"  set of instrinsics, as narrow pattern 
matching is bound to produce performance cliffs nobody will notice.

Jose


From: srol...@vmware.com 
Sent: Wednesday, August 28, 2019 20:37
To: mesa-dev@lists.freedesktop.org ; Jose 
Fonseca ; airl...@freedesktop.org 
Cc: Roland Scheidegger 
Subject: [PATCH] gallivm: use fallback code for mul_hi with llvm >= 7.0

From: Roland Scheidegger 

LLVM 7.0 ditched the pmulu intrinsics.
This is only a trivial patch to use the fallback code instead.
It'll likely produce atrocious code since the pattern doesn't match what
llvm itself uses in its autoupgrade paths, hence the pattern won't be
recognized.

Should fix https://bugs.freedesktop.org/show_bug.cgi?id=111496
---
 src/gallium/auxiliary/gallivm/lp_bld_arit.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c 
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index c4931c0b230..f1866c6625f 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
@@ -1169,8 +1169,13 @@ lp_build_mul_32_lohi_cpu(struct lp_build_context *bld,
 * https://llvm.org/bugs/show_bug.cgi?id=30845
 * So, whip up our own code, albeit only for length 4 and 8 (which
 * should be good enough)...
+* FIXME: For llvm >= 7.0 we should match the autoupgrade pattern
+* (bitcast/and/mul/shuffle for unsigned, bitcast/shl/ashr/mul/shuffle
+* for signed), which the fallback code does not, without this llvm
+* will likely still produce atrocious code.
 */
-   if ((bld->type.length == 4 || bld->type.length == 8) &&
+   if (HAVE_LLVM < 0x0700 &&
+   (bld->type.length == 4 || bld->type.length == 8) &&
((util_cpu_caps.has_sse2 && (bld->type.sign == 0)) ||
 util_cpu_caps.has_sse4_1)) {
   const char *intrinsic = NULL;
--
2.17.1

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

Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration

[Jose Fonseca]

On 29/08/2019 01:12, Dave Airlie wrote:
> On Tue, 27 Aug 2019 at 20:30, Jose Fonseca  wrote:
>>
>> FYI, I've followed Eric Engestroms' instructions for better Mesa <-> 
>> AppVeyor integration.  (Thanks Eric.)
>>
>> I haven't tested, but hopefully this new integration method should now 
>> trigger Appveyor builds on pull requests too, which should come handy.
>>
>> I'm still keeping the old webhook method integration around (with a 
>> different name.)  So the list might receive duplicate notifications.  I'll 
>> disable this when we're satisfied the new method works well.
>>
>> For the record, these Appveyor runs are running on a separate Appveyor 
>> account dedicated for Mesa and FDO projects like Piglit, and not my personal 
>> Appveyor account.
> 
> It appears all the results are going to mesa-dev, is there a way to
> send them to the same ppl that would get them from gitlab?
> 
> I push to some of my PRs quite a lot (esp when llvm version wrangling).
> 
> Dave.
> 

That would indeed be the ideal, but I don't know how to do that selectively.

Per https://www.appveyor.com/docs/notifications/ one can use 
`{{commitAuthorEmail}}`, but then this would apply to all builds (PRs 
and non PRs alike.

It seems the only solution is two have two integrations -- one running 
master CC mesa-dev, another running PRs CC'ing the authors.  But from 
another mail on this thread, perhaps a better solution is to add a 
Gitlab Pipeline -> Appveyor trigger, which waits for the result.

I'm afraid I don't have the time right now to dig into this.  On one 
hand, better integration would be nice, on the other, it might be easier 
to wait and see of Appevyor <-> Gitlab gets better by itself upstream.

For now I've disabled PR -> Appveyor builds to keep the noise level down.

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

Re: [Mesa-dev] [PATCH 4/4] scons: Make GCC builds stricter.

[Jose Fonseca]

Hi Michel,

> Good to see you guys starting to take better advantage of the GitLab CI 
> pipeline.

Gitlab CI integration is complicated (very configurable), but I can tell from 
my experience with my own personal Github projects that having tests run during 
PRs are a god send.

> With my last name spelled correctly Dänzer or Daenzer,

Oops.  I worried about getting the "ae" right and forgot the "n"..  m(_ _)m

Jose


From: Michel Dänzer 
Sent: Wednesday, August 28, 2019 11:59
To: Jose Fonseca ; Brian Paul ; Roland 
Scheidegger ; Charmaine Lee 
Cc: mesa-dev@lists.freedesktop.org ; 
e...@engestrom.ch 
Subject: Re: [Mesa-dev] [PATCH 4/4] scons: Make GCC builds stricter.

On 2019-08-27 12:57 p.m., Jose Fonseca wrote:
> Uses some of the same -Werror options used by Meson,

Cool stuff! Good to see you guys starting to take better advantage of
the GitLab CI pipeline.

> as suggested by Michel Daezer.

With my last name spelled correctly Dänzer or Daenzer,

Reviewed-by: Michel Dänzer 


--
Earthling Michel Dänzer   |   
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fredhat.comdata=02%7C01%7Cjfonseca%40vmware.com%7C00a1f6d6e4524f99fd1308d72ba6d5fe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637025867896875073sdata=FT3RG3hSCPhJe5Xdm3JIZ8gvSbjc6gbpsOIi0x3lMa4%3Dreserved=0
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration

[Jose Fonseca]

On 28/08/2019 11:18, Michel Dänzer wrote:
> On 2019-08-28 3:08 a.m., Eric Engestrom wrote:
>> On Tuesday, 2019-08-27 13:31:22 +0000, Jose Fonseca wrote:
>>> Appveyor seems to be building other MR 1781:
>>>
>>>
>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.appveyor.com%2Fproject%2Fmesa3d%2Fmesa-re1yd%2Fbuilds%2F26989425data=02%7C01%7Cjfonseca%40vmware.com%7Cfe3cd31e967944da212808d72ba11193%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637025843105542606sdata=1UouYWYgyMdOVBEvlQgjByq3Scl2yyy%2FEJKfrIM7vNk%3Dreserved=0
>>>
>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.appveyor.com%2Fproject%2Fmesa3d%2Fmesa-re1yd%2Fhistorydata=02%7C01%7Cjfonseca%40vmware.com%7Cfe3cd31e967944da212808d72ba11193%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637025843105542606sdata=uefH8tE%2F0i8D8hn8W9i%2BsS61OuPYrKoAVxNoJkBfS3c%3Dreserved=0
>>>
>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Feric%2Fmesa%2Fpipelines%2F59190data=02%7C01%7Cjfonseca%40vmware.com%7Cfe3cd31e967944da212808d72ba11193%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637025843105542606sdata=wIlfbXS1USrnLRnLQJ5sMqDTtyQ2cDTYRolH6UezXco%3Dreserved=0
>>
>> You shouldn't take my MRs as an example for this, as I've set up the
>> hook on my account, so my MRs always get picked up by appveyor :)
> 
> Yeah, the external integration settings are per GitLab project, and
> pre-merge CI pipelines for MRs run in the source project context, so the
> appveyor integration would need to be set up in each forked project used
> for MRs.
> 
> This is a bit unfortunate, as it means the CI pipeline which runs (in
> the main project context) after an MR is merged could fail at the
> appveyor step, even if the pre-merge pipeline passed.
> 
> Not sure what can be done about this though, other than requiring forked
> projects used for MRs to set up the appveyor integration as well.
> 
> 

That's unfortunate.

Though it looks like Appveyor is actually running MRs:

https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/27008264

and notifying mesa-dev about failures:

https://lists.freedesktop.org/archives/mesa-dev/2019-August/222329.html

It's just unfortunate that there's no mention of it on the actual MR page

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

Caio, did you happen to receive any direct email from this?


If we can't get these MRs notifcations right, then I think we're better 
off not running for MRs.  To avoid spamming the list.


Jose

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

Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration

[Jose Fonseca]

I'm not following.

I picked MR 1781 not because it was yours, but because it was running on my 
appveyor account -- 
https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/26989425 .

See for yourself on https://ci.appveyor.com/project/mesa3d/mesa-re1yd/history  
-- there's plenty of MRs being run there.

Here's another one from another person:  
https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/27006958
The odd thing is that there's no report of Appveyor on 
https://gitlab.freedesktop.org/cmarcelo/mesa/pipelines/59368


So it seems there are actually two problems:

  *   appveyor is not running for some MRs
  *   even when appveyor is running, it is not reporting back results for all 
MRs

Jose


From: Eric Engestrom 
Sent: Wednesday, August 28, 2019 02:08
To: Jose Fonseca 
Cc: mesa-dev@lists.freedesktop.org ; Brian Paul 

Subject: Re: Mesa GitLab <-> AppVeyor integration

On Tuesday, 2019-08-27 13:31:22 +, Jose Fonseca wrote:
> Appveyor seems to be building other MR 1781:
>
>   
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.appveyor.com%2Fproject%2Fmesa3d%2Fmesa-re1yd%2Fbuilds%2F26989425data=02%7C01%7Cjfonseca%40vmware.com%7C46b201504bcd45aca1f408d72b544469%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637025513249945766sdata=1jROCgNnCM04pscw1K%2FoUWF5qlqWKxzfyW9jbld%2FPoY%3Dreserved=0
>   
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.appveyor.com%2Fproject%2Fmesa3d%2Fmesa-re1yd%2Fhistorydata=02%7C01%7Cjfonseca%40vmware.com%7C46b201504bcd45aca1f408d72b544469%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637025513249945766sdata=6pqEuMnrInz7jF4ymROan8nfmPpxx%2BEuk4G9FrKd8ts%3Dreserved=0
>   
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Feric%2Fmesa%2Fpipelines%2F59190data=02%7C01%7Cjfonseca%40vmware.com%7C46b201504bcd45aca1f408d72b544469%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637025513249955761sdata=XICobt%2BBKAIcu8WCtN%2B%2B98w0Mnk5JlIehxjbBaikoOI%3Dreserved=0

You shouldn't take my MRs as an example for this, as I've set up the
hook on my account, so my MRs always get picked up by appveyor :)

>
> I don't know what's special about MR 1779.  Perhaps it's just the sheer 
> volume of merges and merge requests?
>
> Jose
>
> 
> From: Eric Engestrom 
> Sent: Tuesday, August 27, 2019 14:23
> To: Jose Fonseca 
> Cc: mesa-dev@lists.freedesktop.org ; Brian 
> Paul 
> Subject: Re: Mesa GitLab <-> AppVeyor integration
>
> On Tuesday, 2019-08-27 10:30:07 +, Jose Fonseca wrote:
> > FYI, I've followed Eric Engestroms' instructions for better Mesa <-> 
> > AppVeyor integration.  (Thanks Eric.)
> >
> > I haven't tested, but hopefully this new integration method should now 
> > trigger Appveyor builds on pull requests too, which should come handy.
> >
> > I'm still keeping the old webhook method integration around (with a 
> > different name.)  So the list might receive duplicate notifications.  I'll 
> > disable this when we're satisfied the new method works well.
> >
> > For the record, these Appveyor runs are running on a separate Appveyor 
> > account dedicated for Mesa and FDO projects like Piglit, and not my 
> > personal Appveyor account.
> >
> > Jose
>
> Thanks!
>
> Looks like it didn't quite work though... MR !1779 [1] was created after
> your email, and doesn't have the [external/appveyor] job on its pipeline.
>
> I doubt there's much I could do that you can't to try to debug this, but
> feel free to ask me :)
>
> [1] 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F1779data=02%7C01%7Cjfonseca%40vmware.com%7C46b201504bcd45aca1f408d72b544469%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637025513249955761sdata=IbHZhB9FV3mATtyZk2WbJKHfxK4xFn9gFoz2BK3CN%2BQ%3Dreserved=0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration

[Jose Fonseca]

Appveyor seems to be building other MR 1781:

  https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/26989425
  https://ci.appveyor.com/project/mesa3d/mesa-re1yd/history
  https://gitlab.freedesktop.org/eric/mesa/pipelines/59190

I don't know what's special about MR 1779.  Perhaps it's just the sheer volume 
of merges and merge requests?

Jose


From: Eric Engestrom 
Sent: Tuesday, August 27, 2019 14:23
To: Jose Fonseca 
Cc: mesa-dev@lists.freedesktop.org ; Brian Paul 

Subject: Re: Mesa GitLab <-> AppVeyor integration

On Tuesday, 2019-08-27 10:30:07 +, Jose Fonseca wrote:
> FYI, I've followed Eric Engestroms' instructions for better Mesa <-> AppVeyor 
> integration.  (Thanks Eric.)
>
> I haven't tested, but hopefully this new integration method should now 
> trigger Appveyor builds on pull requests too, which should come handy.
>
> I'm still keeping the old webhook method integration around (with a different 
> name.)  So the list might receive duplicate notifications.  I'll disable this 
> when we're satisfied the new method works well.
>
> For the record, these Appveyor runs are running on a separate Appveyor 
> account dedicated for Mesa and FDO projects like Piglit, and not my personal 
> Appveyor account.
>
> Jose

Thanks!

Looks like it didn't quite work though... MR !1779 [1] was created after
your email, and doesn't have the [external/appveyor] job on its pipeline.

I doubt there's much I could do that you can't to try to debug this, but
feel free to ask me :)

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F1779data=02%7C01%7Cjfonseca%40vmware.com%7C9bd7988d457342fb2a2808d72af1d2a2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637025090427847960sdata=3G9tePq%2BMLG1Yw%2FWr92MCo1ksWwe7exFKqoxhS2LmQU%3Dreserved=0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] scons: Make GCC builds stricter.

[Jose Fonseca]

Uses some of the same -Werror options used by Meson, as suggested by
Michel Daezer.
---
 scons/gallium.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scons/gallium.py b/scons/gallium.py
index 21197c8d0d1..2eff4174257 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -473,7 +473,10 @@ def generate(env):
 '-fmessage-length=0', # be nice to Eclipse
 ]
 cflags += [
-'-Wmissing-prototypes',
+'-Werror=implicit-function-declaration',
+'-Werror=missing-prototypes',
+'-Werror=return-type',
+'-Werror=incompatible-pointer-types',
 '-std=gnu99',
 ]
 if icc:
-- 
2.17.1

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

[Mesa-dev] [PATCH 3/4] util: Prevent strcasecmp macro redefinion.

[Jose Fonseca]

MinGW headers already define it.
---
 src/util/u_string.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/util/u_string.h b/src/util/u_string.h
index 5fea8f17e73..361dcb41e2b 100644
--- a/src/util/u_string.h
+++ b/src/util/u_string.h
@@ -110,7 +110,10 @@ util_asprintf(char **str, const char *fmt, ...)
return ret;
 }
 
+#ifndef strcasecmp
 #define strcasecmp stricmp
+#endif
+
 #define strdup _strdup
 
 #endif
-- 
2.17.1

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

[Mesa-dev] [PATCH 1/4] glx: Fix incompatible function pointer types.

[Jose Fonseca]

I don't know how Meson didn't hit this issue, when it too already uses
-Werror=incompatible-pointer-types
---
 src/mesa/drivers/x11/glxapi.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/x11/glxapi.h b/src/mesa/drivers/x11/glxapi.h
index 90323a24731..6a1ce66a891 100644
--- a/src/mesa/drivers/x11/glxapi.h
+++ b/src/mesa/drivers/x11/glxapi.h
@@ -143,7 +143,7 @@ struct _glxapi_table {
/*** GLX_SGIX_pbuffer ***/
GLXPbufferSGIX (*CreateGLXPbufferSGIX)(Display *, GLXFBConfigSGIX, unsigned 
int, unsigned int, int *);
void (*DestroyGLXPbufferSGIX)(Display *, GLXPbufferSGIX);
-   int (*QueryGLXPbufferSGIX)(Display *, GLXPbufferSGIX, int, unsigned int *);
+   void (*QueryGLXPbufferSGIX)(Display *, GLXPbufferSGIX, int, unsigned int *);
void (*SelectEventSGIX)(Display *, GLXDrawable, unsigned long);
void (*GetSelectedEventSGIX)(Display *, GLXDrawable, unsigned long *);
 
-- 
2.17.1

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

[Mesa-dev] [PATCH 2/4] util: Prevent implicit declaration of function getenv.

[Jose Fonseca]

With MinGW cross compilation.
---
 src/util/os_misc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/util/os_misc.c b/src/util/os_misc.c
index 755970430b0..436bc38604b 100644
--- a/src/util/os_misc.c
+++ b/src/util/os_misc.c
@@ -38,6 +38,7 @@
 #endif
 #include 
 #include 
+#include 
 
 #else
 
-- 
2.17.1

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

Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration

[Jose Fonseca]

FYI, I've followed Eric Engestroms' instructions for better Mesa <-> AppVeyor 
integration.  (Thanks Eric.)

I haven't tested, but hopefully this new integration method should now trigger 
Appveyor builds on pull requests too, which should come handy.

I'm still keeping the old webhook method integration around (with a different 
name.)  So the list might receive duplicate notifications.  I'll disable this 
when we're satisfied the new method works well.

For the record, these Appveyor runs are running on a separate Appveyor account 
dedicated for Mesa and FDO projects like Piglit, and not my personal Appveyor 
account.

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

Re: [Mesa-dev] dEQP + llvmpipe

[Jose Fonseca]

> I think that for GL and GLES contexts, we should disable noncormant hacks 
> instead of using env vars to falsely claim conformance.

The hacks controlled for `GALLIVM_DEBUG=no_rho_approx,no_brilinear,no_quad_lod` 
 where meant to speed up commonplace 3D rendering, on any kind of context (GL 
or not).  These particular hacks were not designed with Direct3D contexts or 
any VMware specific workloads in mind.  They are meant to speed up texture 
sampling, which often dominates pixel shader performance.

Regarding the default llvmpipe behavior is, it really depends what its goal is: 
fast SW renderering with acceptable quality, or a fully compliant SW 
renderering.  So far we've favoured performance over full conformance.  
Unfortunately, it's impossible to be both.

I'm OK not claiming any conformance with llvmpipe FWIW.

Jose


From: mesa-dev  on behalf of Eric 
Anholt 
Sent: Tuesday, August 13, 2019 21:49
To: Ilia Mirkin 
Cc: ML Mesa-dev 
Subject: Re: [Mesa-dev] dEQP + llvmpipe

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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D94957data=02%7C01%7Cjfonseca%40vmware.com%7C8cfcb00c765b4596fc0708d7202fc088%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637013261788370956sdata=WZ0LimnTNWwlGYoaldC0q9D3vBk4zBFONF6W0MibFxA%3Dreserved=0
>  .

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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: fix a missing argument to CreateAtomicCmpXchg

[Jose Fonseca]

Looks good to me.

Reviewed-by: Jose Fonseca 


From: Charmaine Lee 
Sent: Thursday, August 1, 2019 23:56
To: mesa-dev@lists.freedesktop.org ; Brian Paul 
; Neha Bhende ; Roland Scheidegger 
; Jose Fonseca ; airl...@redhat.com 

Cc: Charmaine Lee 
Subject: [PATCH] gallivm: fix a missing argument to CreateAtomicCmpXchg

This patch fixes a missing argument to CreateAtomicCmpXchg for older
version of LLVM.
---
 src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp 
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index 79d1029..8205d24 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
@@ -831,6 +831,7 @@ LLVMValueRef LLVMBuildAtomicCmpXchg(LLVMBuilderRef B, 
LLVMValueRef Ptr,
/* LLVM 3.8 doesn't have a second ordering and uses old 
SynchronizationScope enum */
return llvm::wrap(llvm::unwrap(B)->CreateAtomicCmpXchg(llvm::unwrap(Ptr), 
llvm::unwrap(Cmp),
   llvm::unwrap(New), 
mapFromLLVMOrdering(SuccessOrdering),
+  
mapFromLLVMOrdering(FailureOrdering),
   SingleThread ? 
llvm::SynchronizationScope::SingleThread : 
llvm::SynchronizationScope::CrossThread));
 }
 #endif
--
1.8.5.6

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

Re: [Mesa-dev] boolean usage in gallium

[Jose Fonseca]

Yep.  It's better to just use C99 bool everywhere.

Jose

On 30/06/2019 06:00, Marek Olšák wrote:
> boolean predates c99 support in MSVC. I think there is no reason for 
> boolean in gallium now.
> 
> Marek
> 
> On Sat., Jun. 29, 2019, 00:09 Ilia Mirkin,  > wrote:
> 
> Ken pointed out on IRC today that there was still a lot of "boolean"
> (vs bool/_Bool) usage in gallium. In fact, many interfaces are
> specified with boolean.
> 
> I had it in my mind that I had at some point removed most boolean
> usage, but that is just not the case - first of all, the interfaces
> remain with it, and I could find no evidence of such a commit. I must
> have imagined it.
> 
> Is there any reason to keep boolean around? I know conversions must be
> done carefully (since incorrect-but-working usage would not currently
> be caught by the compiler), but are there any practical reasons to
> avoid C99 _Bool in gallium code?
> 
> If not, I may begin converting things over.
> 
> Cheers,
> 
>    -ilia
> ___
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cjfonseca%40vmware.com%7C513e439c4dbe42d80f8808d6fd17f8f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636974676763494464sdata=PudvVZvCoB3oP58vHYwF%2Bq3y14psK3z%2F7PUfayMpidI%3Dreserved=0
> 

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

Re: [Mesa-dev] [PATCH] gallivm: Improve lp_build_rcp_refine.

[Jose Fonseca]

On 25/06/2019 16:22, Roland Scheidegger wrote:
> Looks good to me, albeit it's potentially minimally slower, so I'm
> wondering if the higher precision is actually useful?

It gets you an extra bit, and is necessary if you want to reach 0.5 ULP 
(otherwise it never gets there.)

Anyway, it's still disabled.  This change is mostly for reference in 
case we once want to enable this code path.  We could still use, in 
situations where we don't get or don't care for inf.  Like perspective 
correct interpolation.

> I guess though the last two steps could use lp_build_fmuladd?

Good point.  I've updated to only use fmuladd.  It might be faster and 
converge even more quickly:


@@ -2724,12 +2724,12 @@ lp_build_rcp_refine(struct lp_build_context *bld,
  LLVMValueRef rcp_a)
  {
 LLVMBuilderRef builder = bld->gallivm->builder;
-   LLVMValueRef two = lp_build_const_vec(bld->gallivm, bld->type, 2.0);
+   LLVMValueRef neg_a;
 LLVMValueRef res;

-   res = LLVMBuildFMul(builder, a, rcp_a, "");
-   res = LLVMBuildFSub(builder, two, res, "");
-   res = LLVMBuildFMul(builder, rcp_a, res, "");
+   neg_a = LLVMBuildFNeg(builder, a, "");
+   res = lp_build_fmuladd(builder, neg_a, rcp_a, bld->one);
+   res = lp_build_fmuladd(builder, res, rcp_a, rcp_a);

 return res;
  }


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

[Mesa-dev] [PATCH] gallivm: Improve lp_build_rcp_refine.

[Jose Fonseca]

Use the alternative more accurate expression from
https://en.wikipedia.org/wiki/Division_algorithm#Newton%E2%80%93Raphson_division

Tested by enabling this code path, and running gloss mesa demo.
---
 src/gallium/auxiliary/gallivm/lp_bld_arit.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c 
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index 02fb81afe51..8aa5931eb69 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
@@ -2707,11 +2707,11 @@ lp_build_sqrt(struct lp_build_context *bld,
 /**
  * Do one Newton-Raphson step to improve reciprocate precision:
  *
- *   x_{i+1} = x_i * (2 - a * x_i)
+ *   x_{i+1} = x_i + x_i * (1 - a * x_i)
  *
  * XXX: Unfortunately this won't give IEEE-754 conformant results for 0 or
  * +/-Inf, giving NaN instead.  Certain applications rely on this behavior,
- * such as Google Earth, which does RCP(RSQRT(0.0) when drawing the Earth's
+ * such as Google Earth, which does RCP(RSQRT(0.0)) when drawing the Earth's
  * halo. It would be necessary to clamp the argument to prevent this.
  *
  * See also:
@@ -2724,12 +2724,13 @@ lp_build_rcp_refine(struct lp_build_context *bld,
 LLVMValueRef rcp_a)
 {
LLVMBuilderRef builder = bld->gallivm->builder;
-   LLVMValueRef two = lp_build_const_vec(bld->gallivm, bld->type, 2.0);
LLVMValueRef res;
 
res = LLVMBuildFMul(builder, a, rcp_a, "");
-   res = LLVMBuildFSub(builder, two, res, "");
+   res = LLVMBuildFSub(builder, bld->one, res, "");
+
res = LLVMBuildFMul(builder, rcp_a, res, "");
+   res = LLVMBuildFAdd(builder, rcp_a, res, "");
 
return res;
 }
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH] scons: fix build with llvm 9.

[Jose Fonseca]

Reviewed-by: Jose Fonseca 


From: srol...@vmware.com 
Sent: Friday, May 24, 2019 02:47
To: Jose Fonseca; mesa-dev@lists.freedesktop.org
Cc: Roland Scheidegger
Subject: [PATCH] scons: fix build with llvm 9.

From: Roland Scheidegger 

The x86asmprinter component is gone, and things seem to work by just
removing it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110707
---
 scons/llvm.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scons/llvm.py b/scons/llvm.py
index a84ad51d97a..bf9666459c6 100644
--- a/scons/llvm.py
+++ b/scons/llvm.py
@@ -260,7 +260,10 @@ def generate(env):
 if '-fno-rtti' in cxxflags:
 env.Append(CXXFLAGS = ['-fno-rtti'])

-components = ['engine', 'mcjit', 'bitwriter', 'x86asmprinter', 
'mcdisassembler', 'irreader']
+if llvm_version < distutils.version.LooseVersion('9.0'):
+   components = ['engine', 'mcjit', 'bitwriter', 'x86asmprinter', 
'mcdisassembler', 'irreader']
+else:
+   components = ['engine', 'mcjit', 'bitwriter', 'mcdisassembler', 
'irreader']

 env.ParseConfig('%s --libs ' % llvm_config + ' '.join(components))
 env.ParseConfig('%s --ldflags' % llvm_config)
--
2.17.1

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

Re: [Mesa-dev] [PATCH] gallivm: fix default cbuf info.

[Jose Fonseca]

Reviewed-by: Jose Fonseca 

Thanks.

Jose


From: srol...@vmware.com 
Sent: Friday, May 24, 2019 02:08
To: Jose Fonseca; mesa-dev@lists.freedesktop.org
Cc: Roland Scheidegger
Subject: [PATCH] gallivm: fix default cbuf info.

From: Roland Scheidegger 

The default null_output really needs to be static, otherwise the values
we'll eventually get later are doubly random (they are not initialized,
and even if they were it's a pointer to a local stack variable).
VMware bug 2349556.
---
 src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c 
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
index b4e3c2fbc8..9fc9b8c77e 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
@@ -608,7 +608,7 @@ finished:
 */

for (index = 0; index < PIPE_MAX_COLOR_BUFS; ++index) {
-  const struct lp_tgsi_channel_info null_output[4];
+  static const struct lp_tgsi_channel_info null_output[4];
   info->cbuf[index] = null_output;
}

--
2.17.1

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

Re: [Mesa-dev] [PATCH] gallivm: fix broken 8-wide s3tc decoding

[Jose Fonseca]

LGTM.

Reviewed-by: Jose Fonseca 


From: srol...@vmware.com 
Sent: Tuesday, May 7, 2019 03:12
To: Jose Fonseca; Brian Paul; mesa-dev@lists.freedesktop.org
Cc: Roland Scheidegger
Subject: [PATCH] gallivm: fix broken 8-wide s3tc decoding

From: Roland Scheidegger 

Brian noticed there was an uninitialized var for the 8-wide case and 128
bit blocks, which made it always crash. Likewise, the 64bit block case
had another crash bug due to type mismatch.
Color decode (used for all s3tc formats) also had a bogus shuffle for
this case, leading to decode artifacts.
Fix these all up, which makes the code actually work 8-wide. Note that
it's still not used - I've verified it works, and the generated assembly
does look quite a bit simpler actually (20-30% less instructions for the
s3tc decode part with avx2), however in practice it still seems to be
sligthly slower for some unknown reason (tested with openarena) on my
haswell box, so for now continue to split things into 4-wide vectors
before decoding.
---
 .../auxiliary/gallivm/lp_bld_format_s3tc.c| 33 +--
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c 
b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
index 9561c349dad..8f6e9bec18a 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
@@ -77,24 +77,17 @@ lp_build_uninterleave2_half(struct gallivm_state *gallivm,
 unsigned lo_hi)
 {
LLVMValueRef shuffle, elems[LP_MAX_VECTOR_LENGTH];
-   unsigned i, j;
+   unsigned i;

assert(type.length <= LP_MAX_VECTOR_LENGTH);
assert(lo_hi < 2);

if (type.length * type.width == 256) {
-  assert(type.length >= 4);
-  for (i = 0, j = 0; i < type.length; ++i) {
- if (i == type.length / 4) {
-j = type.length;
- } else if (i == type.length / 2) {
-j = type.length / 2;
- } else if (i == 3 * type.length / 4) {
-j = 3 * type.length / 4;
- } else {
-j += 2;
- }
- elems[i] = lp_build_const_int32(gallivm, j + lo_hi);
+  assert(type.length == 8);
+  assert(type.width == 32);
+  const unsigned shufvals[8] = {0, 2, 8, 10, 4, 6, 12, 14};
+  for (i = 0; i < type.length; ++i) {
+ elems[i] = lp_build_const_int32(gallivm, shufvals[i] + lo_hi);
   }
} else {
   for (i = 0; i < type.length; ++i) {
@@ -277,7 +270,7 @@ lp_build_gather_s3tc(struct gallivm_state *gallivm,
}
else {
   LLVMValueRef tmp[4], cc01, cc23;
-  struct lp_type lp_type32, lp_type64, lp_type32dxt;
+  struct lp_type lp_type32, lp_type64;
   memset(_type32, 0, sizeof lp_type32);
   lp_type32.width = 32;
   lp_type32.length = length;
@@ -309,10 +302,14 @@ lp_build_gather_s3tc(struct gallivm_state *gallivm,
   
lp_build_const_extend_shuffle(gallivm, 2, 4), "");
  }
  if (length == 8) {
+struct lp_type lp_type32_4;
+memset(_type32_4, 0, sizeof lp_type32_4);
+lp_type32_4.width = 32;
+lp_type32_4.length = 4;
 for (i = 0; i < 4; ++i) {
tmp[0] = elems[i];
tmp[1] = elems[i+4];
-   elems[i] = lp_build_concat(gallivm, tmp, lp_type32, 2);
+   elems[i] = lp_build_concat(gallivm, tmp, lp_type32_4, 2);
 }
  }
  cc01 = lp_build_interleave2_half(gallivm, lp_type32, elems[0], 
elems[1], 0);
@@ -811,7 +808,7 @@ s3tc_dxt3_to_rgba_aos(struct gallivm_state *gallivm,
tmp = lp_build_select(, sel_mask, alpha_low, alpha_hi);
bit_pos = LLVMBuildAnd(builder, bit_pos,
   lp_build_const_int_vec(gallivm, type, 0xffdf), 
"");
-   /* Warning: slow shift with per element count */
+   /* Warning: slow shift with per element count (without avx2) */
/*
 * Could do pshufb here as well - just use appropriate 2 bits in bit_pos
 * to select the right byte with pshufb. Then for the remaining one bit
@@ -1640,7 +1637,6 @@ s3tc_decode_block_dxt5(struct gallivm_state *gallivm,
   lp_build_const_int_vec(gallivm, type16, 8), "");
alpha = LLVMBuildBitCast(builder, alpha,  i64t, "");
shuffle1 = lp_build_const_shuffle1(gallivm, 0, 8);
-   /* XXX this shuffle broken with LLVM 2.8 */
alpha0 = LLVMBuildShuffleVector(builder, alpha0, alpha0, shuffle1, "");
alpha1 = LLVMBuildShuffleVector(builder, alpha1, alpha1, shuffle1, "");

@@ -2176,6 +2172,9 @@ lp_build_fetch_s3tc_rgba_aos(struct gallivm_state 
*gallivm,
   return rgba;
}

+   /*
+* Could use n > 8 here with avx2, but doesn't seem faster.
+*/
if (n > 4) {
   unsigned count;
   LLVMTypeRef i8_vectype = LLVMVectorType(i8t, 4 * n);
--

Re: [Mesa-dev] [PATCH] glsl: work around MinGW 7.x compiler bug

[Jose Fonseca]

Looks good to me.

Reviewed-by: Jose Fonseca 



From: Brian Paul 
Sent: Wednesday, May 1, 2019 21:28
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende; Jose Fonseca; Charmaine Lee
Subject: [PATCH] glsl: work around MinGW 7.x compiler bug

I'm not sure what triggered this, but building with
scons platform=windows toolchain=crossmingw machine=x86 build=profile
with MinGW g++ 7.3 or 7.4 causes an internal compiler error.

We can work around it by forcing -O1 optimization.
---
 src/compiler/glsl/builtin_variables.cpp | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/src/compiler/glsl/builtin_variables.cpp 
b/src/compiler/glsl/builtin_variables.cpp
index 17ee80c..1b9963a 100644
--- a/src/compiler/glsl/builtin_variables.cpp
+++ b/src/compiler/glsl/builtin_variables.cpp
@@ -21,6 +21,21 @@
  * DEALINGS IN THE SOFTWARE.
  */

+
+/**
+ * Building this file with MinGW g++ 7.3 or 7.4 with:
+ *   scons platform=windows toolchain=crossmingw machine=x86 build=profile
+ * triggers an internal compiler error.
+ * Overriding the optimization level to -O1 works around the issue.
+ * MinGW 5.3.1 does not seem to have the bug, neither does 8.3.  So for now
+ * we're simply testing for version 7.x here.
+ */
+#if defined(__MINGW32__) && __GNUC__ == 7
+#warning "disabling optimizations for this file to work around compiler bug in 
MiGW gcc 7.x"
+#pragma GCC optimize("O1")
+#endif
+
+
 #include "ir.h"
 #include "ir_builder.h"
 #include "linker.h"
--
1.8.5.6

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

Re: [Mesa-dev] [PATCH] util: no-op __builtin_types_compatible_p() for non-GCC compilers

[Jose Fonseca]

Looks good
Reviewed-by: Jose Fonseca 


From: Brian Paul 
Sent: Friday, March 29, 2019 16:57
To: mesa-dev@lists.freedesktop.org
Cc: Ian Romanick; Jose Fonseca; Neha Bhende
Subject: [PATCH] util: no-op __builtin_types_compatible_p() for non-GCC 
compilers

__builtin_types_compatible_p() is GCC-specific and breaks the
MSVC build.

This intrinsic has been in u_vector_foreach() for a long time, but
that macro has only recently been used in code
(nir/nir_opt_comparison_pre.c) that's built with MSVC.

Fixes: 2cf59861a ("nir: Add partial redundancy elimination for compares")
---
 src/util/u_vector.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/util/u_vector.h b/src/util/u_vector.h
index cd8a95d..6807748 100644
--- a/src/util/u_vector.h
+++ b/src/util/u_vector.h
@@ -80,6 +80,10 @@ u_vector_finish(struct u_vector *queue)
free(queue->data);
 }

+#ifndef __GNUC__
+#define __builtin_types_compatible_p(x) 1
+#endif
+
 #define u_vector_foreach(elem, queue)  \
STATIC_ASSERT(__builtin_types_compatible_p(__typeof__(queue), struct 
u_vector *)); \
for (uint32_t __u_vector_offset = (queue)->tail;
\
--
1.8.5.6

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

Re: [Mesa-dev] [PATCH] st/mesa: fix texture deletion context mix-up issues (v2)

[Jose Fonseca]

On 25/03/2019 14:26, Brian Paul wrote:
> On 03/23/2019 10:49 AM, Jose Fonseca wrote:
>> Looks good to me.
>>
>> Reviewed-by: Jose Fonseca 
>>
>> Though I wonder if this could happen also when not destroying the 
>> current context. (Ie, if we need zoombie textures too?)
> 
> If we're not destroying the thread's current context, this patch 
> temporarily binds the context as the current one.  If the contexts 
> textures are not shared, they'll be deleted.  If they are shared, they 
> won't be deleted.  I think that part is fairly straight-forward.

OK.  Thinking more about it, we only need zombies for the sample views, 
not the textures themselves.

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

Re: [Mesa-dev] [PATCH] st/mesa: fix texture deletion context mix-up issues (v2)

[Jose Fonseca]

Looks good to me.

Reviewed-by: Jose Fonseca 

Though I wonder if this could happen also when not destroying the current 
context. (Ie, if we need zoombie textures too?)

Jose



From: Brian Paul 
Sent: Friday, March 22, 2019 19:51
To: mesa-dev@lists.freedesktop.org
Cc: Jose Fonseca; Neha Bhende
Subject: [PATCH] st/mesa: fix texture deletion context mix-up issues (v2)

When we destroy a context, we need to temporarily make that context
the current one for the thread.

That's because during context tear-down we make many calls to
_mesa_reference_texobj(, NULL).  Note there's no context
parameter.  If the texture's refcount goes to zero and we need to
delete it, we use the thread's current context.  But if that context
isn't the context we're tearing down, we get into trouble when
deallocating sampler views.  See patch 593e36f956 ("st/mesa:
implement "zombie" sampler views (v2)") for background information.

Also, we need to release any sampler views attached to the fallback
textures.

Fixes a crash on exit with a glretrace of the Nobel Clinician
application.

v2: at end of st_destroy_context(), check if save_ctx == ctx and
unbind the context if so.
---
 src/mesa/state_tracker/st_context.c | 51 -
 1 file changed, 39 insertions(+), 12 deletions(-)

diff --git a/src/mesa/state_tracker/st_context.c 
b/src/mesa/state_tracker/st_context.c
index f037384..09d467a 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -917,15 +917,39 @@ st_destroy_context(struct st_context *st)
 {
struct gl_context *ctx = st->ctx;
struct st_framebuffer *stfb, *next;
+   struct gl_framebuffer *save_drawbuffer;
+   struct gl_framebuffer *save_readbuffer;
+
+   /* Save the current context and draw/read buffers*/
+   GET_CURRENT_CONTEXT(save_ctx);
+   if (save_ctx) {
+  save_drawbuffer = save_ctx->WinSysDrawBuffer;
+  save_readbuffer = save_ctx->WinSysReadBuffer;
+   } else {
+  save_drawbuffer = save_readbuffer = NULL;
+   }

-   GET_CURRENT_CONTEXT(curctx);
+   /*
+* We need to bind the context we're deleting so that
+* _mesa_reference_texobj_() uses this context when deleting textures.
+* Similarly for framebuffer objects, etc.
+*/
+   _mesa_make_current(ctx, NULL, NULL);

-   if (curctx == NULL) {
-  /* No current context, but we need one to release
-   * renderbuffer surface when we release framebuffer.
-   * So temporarily bind the context.
-   */
-  _mesa_make_current(ctx, NULL, NULL);
+   /* This must be called first so that glthread has a chance to finish */
+   _mesa_glthread_destroy(ctx);
+
+   _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st);
+
+   /* For the fallback textures, free any sampler views belonging to this
+* context.
+*/
+   for (unsigned i = 0; i < NUM_TEXTURE_TARGETS; i++) {
+  struct st_texture_object *stObj =
+ st_texture_object(ctx->Shared->FallbackTex[i]);
+  if (stObj) {
+ st_texture_release_context_sampler_view(st, stObj);
+  }
}

st_context_free_zombie_objects(st);
@@ -933,11 +957,6 @@ st_destroy_context(struct st_context *st)
mtx_destroy(>zombie_sampler_views.mutex);
mtx_destroy(>zombie_shaders.mutex);

-   /* This must be called first so that glthread has a chance to finish */
-   _mesa_glthread_destroy(ctx);
-
-   _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st);
-
st_reference_fragprog(st, >fp, NULL);
st_reference_prog(st, >gp, NULL);
st_reference_vertprog(st, >vp, NULL);
@@ -965,4 +984,12 @@ st_destroy_context(struct st_context *st)
st = NULL;

free(ctx);
+
+   if (save_ctx == ctx) {
+  /* unbind the context we just deleted */
+  _mesa_make_current(NULL, NULL, NULL);
+   } else {
+  /* Restore the current context and draw/read buffers (may be NULL) */
+  _mesa_make_current(save_ctx, save_drawbuffer, save_readbuffer);
+   }
 }
--
1.8.5.6

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

Re: [Mesa-dev] [PATCH] st/mesa: implement "zombie" sampler views (v2)

[Jose Fonseca]

On 15/03/2019 21:12, Brian Paul wrote:

When st_texture_release_all_sampler_views() is called the texture may
have sampler views belonging to several contexts.  If we unreference a
sampler view and its refcount hits zero, we need to be sure to destroy
the sampler view with the same context which created it.

This was not the case with the previous code which used
pipe_sampler_view_release().  That function could end up freeing a
sampler view with a context different than the one which created it.
In the case of the VMware svga driver, we detected this but leaked the
sampler view.  This led to a crash with google-chrome when the kernel
module had too many sampler views.  VMware bug 2274734.

Alternately, if we try to delete a sampler view with the correct
context, we may be "reaching into" a context which is active on
another thread.  That's not safe.

To fix these issues this patch adds a per-context list of "zombie"
sampler views.  These are views which are to be freed at some point
when the context is active.  Other contexts may safely add sampler
views to the zombie list at any time (it's mutex protected).  This
avoids the context/view ownership mix-ups we had before.

Tested with: google-chrome, google earth, Redway3D Watch/Turbine demos
a few Linux games.  If anyone can recomment some other multi-threaded,
multi-context GL apps to test, please let me know.

v2: avoid potential race issue by always adding sampler views to the
zombie list if the view's context doesn't match the current context,
ignoring the refcount.

Reviewed-by: Roland Scheidegger 
Reviewed-by: Neha Bhende 
Reviewed-by: Mathias Fröhlich 
Reviewed-By: Jose Fonseca 
---
  src/mesa/state_tracker/st_cb_flush.c |  6 +++
  src/mesa/state_tracker/st_context.c  | 80 
  src/mesa/state_tracker/st_context.h  | 25 ++
  src/mesa/state_tracker/st_sampler_view.c | 21 +++--
  src/mesa/state_tracker/st_texture.h  |  3 ++
  5 files changed, 131 insertions(+), 4 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_flush.c 
b/src/mesa/state_tracker/st_cb_flush.c
index 5b3188c..81e5338 100644
--- a/src/mesa/state_tracker/st_cb_flush.c
+++ b/src/mesa/state_tracker/st_cb_flush.c
@@ -39,6 +39,7 @@
  #include "st_cb_flush.h"
  #include "st_cb_clear.h"
  #include "st_cb_fbo.h"
+#include "st_context.h"
  #include "st_manager.h"
  #include "pipe/p_context.h"
  #include "pipe/p_defines.h"
@@ -53,6 +54,11 @@ st_flush(struct st_context *st,
  {
 st_flush_bitmap_cache(st);
  
+   /* We want to call this function periodically.

+* Typically, it has nothing to do so it shouldn't be expensive.
+*/
+   st_context_free_zombie_objects(st);
+
 st->pipe->flush(st->pipe, fence, flags);
  }
  
diff --git a/src/mesa/state_tracker/st_context.c b/src/mesa/state_tracker/st_context.c

index 2898279..c38f8e5 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -261,6 +261,79 @@ st_invalidate_state(struct gl_context *ctx)
  }
  
  
+/*

+ * In some circumstances (such as running google-chrome) the state
+ * tracker may try to delete a resource view from a context different
+ * than when it was created.  We don't want to do that.
+ *
+ * In that situation, st_texture_release_all_sampler_views() calls this
+ * function to transfer the sampler view reference to this context (expected
+ * to be the context which created the view.)
+ */
+void
+st_save_zombie_sampler_view(struct st_context *st,
+struct pipe_sampler_view *view)
+{
+   struct st_zombie_sampler_view_node *entry;
+
+   assert(view->context == st->pipe);
+
+   entry = MALLOC_STRUCT(st_zombie_sampler_view_node);
+   if (!entry)
+  return;
+
+   entry->view = view;
+
+   /* We need a mutex since this function may be called from one thread
+* while free_zombie_resource_views() is called from another.
+*/
+   mtx_lock(>zombie_sampler_views.mutex);
+   LIST_ADDTAIL(>node, >zombie_sampler_views.list.node);
+   mtx_unlock(>zombie_sampler_views.mutex);
+}
+
+
+/*
+ * Free any zombie sampler views that may be attached to this context.
+ */
+static void
+free_zombie_sampler_views(struct st_context *st)
+{
+   struct st_zombie_sampler_view_node *entry, *next;
+
+   if (LIST_IS_EMPTY(>zombie_sampler_views.list.node)) {
+  return;
+   }
+
+   mtx_lock(>zombie_sampler_views.mutex);
+
+   LIST_FOR_EACH_ENTRY_SAFE(entry, next,
+>zombie_sampler_views.list.node, node) {
+  LIST_DEL(>node);  // remove this entry from the list
+
+  assert(entry->view->context == st->pipe);
+  pipe_sampler_view_reference(>view, NULL);
+
+  free(entry);
+   }
+
+   assert(LIST_IS_EMPTY(>zombie_sampler_views.list.node));
+
+   mtx_unlock(>zombie_sampler_views.mutex);
+}
+
+
+/*
+ * This function is c

Re: [Mesa-dev] [PATCH 1/8] st/mesa: implement "zombie" sampler views

[Jose Fonseca]

views */

+   assert(stObj->sampler_views->count == 0);
 free(stObj->sampler_views);
 stObj->sampler_views = NULL;
  
diff --git a/src/mesa/state_tracker/st_texture.h b/src/mesa/state_tracker/st_texture.h

index f71d5a0..c5fc30c 100644
--- a/src/mesa/state_tracker/st_texture.h
+++ b/src/mesa/state_tracker/st_texture.h
@@ -57,6 +57,9 @@ struct st_sampler_view
  {
 struct pipe_sampler_view *view;
  
+   /** The context which created this view */

+   struct st_context *st;
+
 /** The glsl version of the shader seen during validation */
 bool glsl130_or_later;
 /** Derived from the sampler's sRGBDecode state during validation */



Otherwise looks great.  It's nice to finally to have a proper solution 
for this long standing tricky issue!


Reviewed-by: Jose Fonseca 

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

Re: [Mesa-dev] [PATCH 1/6] st/mesa: fix sampler view context mismatch issue

[Jose Fonseca]

On 08/03/2019 22:52, Brian Paul wrote:

After a while of running google-chrome and viewing Bing maps, we'd see
"context mismatch in svga_sampler_view_destroy()" messages and
eventually crash because we leaked too many sampler views (the kernel
module would have too many sampler views).

When a texture object is being deleted, we call
st_texture_release_all_sampler_views() to release all the sampler
views.  In the list, there may sampler views which were created from
other contexts.

Previously, we called pipe_sampler_view_release(pipe, view) which would
use the given pipe context to destroy the view if the refcount hit
zero.  The svga error was triggered because we were calling
pipe->sampler_view_destroy(pipe, view) and the pipe context didn't
match the view's parent context.

Instead, call pipe_sampler_reference(, NULL).  That way, if
the refcount hits zero, we'll use the view's parent context to
destroy the view.  That's what we want.

The pipe_sampler_view_release() function was introduced years ago to
avoid freeing a sampler view with a context that was already deleted.

But since then we've improved sampler view and context tracking.
When a context is destroyed, the state tracker walks over all
texture objects and frees all sampler views which belong to that
context.  So, we should never end up deleting a sampler view after
its context is deleted.

After this, we can remove all calls to pipe_sampler_view_release()
in the drivers.

Finally, it appears that we need to implement a similar tear-down
mechanism for shaders and programs since we may generate per-context
shader variants.

Testing done: google chrome, misc GL demos, games
---
  src/mesa/state_tracker/st_context.c  | 3 +--
  src/mesa/state_tracker/st_sampler_view.c | 8 
  2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/src/mesa/state_tracker/st_context.c 
b/src/mesa/state_tracker/st_context.c
index 2898279..a7464fd 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -278,8 +278,7 @@ st_destroy_context_priv(struct st_context *st, bool 
destroy_pipe)
 st_destroy_bound_image_handles(st);
  
 for (i = 0; i < ARRAY_SIZE(st->state.frag_sampler_views); i++) {

-  pipe_sampler_view_release(st->pipe,
->state.frag_sampler_views[i]);
+  pipe_sampler_view_reference(>state.frag_sampler_views[i], NULL);
 }
  
 /* free glReadPixels cache data */

diff --git a/src/mesa/state_tracker/st_sampler_view.c 
b/src/mesa/state_tracker/st_sampler_view.c
index e4eaf39..650a2b0 100644
--- a/src/mesa/state_tracker/st_sampler_view.c
+++ b/src/mesa/state_tracker/st_sampler_view.c
@@ -74,7 +74,7 @@ st_texture_set_sampler_view(struct st_context *st,
if (sv->view) {
   /* check if the context matches */
   if (sv->view->context == st->pipe) {
-pipe_sampler_view_release(st->pipe, >view);
+pipe_sampler_view_reference(>view, NULL);
  goto found;
   }
} else {
@@ -94,13 +94,13 @@ st_texture_set_sampler_view(struct st_context *st,
  
   if (new_max < views->max ||

   new_max > (UINT_MAX - sizeof(*views)) / sizeof(views->views[0])) 
{
-pipe_sampler_view_release(st->pipe, );
+pipe_sampler_view_reference(, NULL);
  goto out;
   }
  
   struct st_sampler_views *new_views = malloc(new_size);

   if (!new_views) {
-pipe_sampler_view_release(st->pipe, );
+pipe_sampler_view_reference(, NULL);
  goto out;
   }
  
@@ -225,7 +225,7 @@ st_texture_release_all_sampler_views(struct st_context *st,

 simple_mtx_lock(>validate_mutex);
 struct st_sampler_views *views = stObj->sampler_views;
 for (i = 0; i < views->count; ++i)
-  pipe_sampler_view_release(st->pipe, >views[i].view);
+  pipe_sampler_view_reference(>views[i].view, NULL);
 simple_mtx_unlock(>validate_mutex);
  }
  



With your upcoming change that prevents the sampler view from ever being 
released with the wrong context (which I suppose should go before this 
one?), this series is


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

Re: [Mesa-dev] dumb meson questions

[Jose Fonseca]

Did you build LLVM yourself.  In my experience, passing

-DCMAKE_C_FLAGS="-g1 -fno-omit-frame-pointer" \
-DCMAKE_CXX_FLAGS="-g1 -fno-omit-frame-pointer" \

to cmake when building LLVM makes debugging info much smaller, without 
compromising the ability to get stack traces, etc.

Jose


From: mesa-dev  on behalf of Brian Paul 

Sent: Wednesday, March 6, 2019 15:46
To: Kenneth Graunke
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] dumb meson questions

On 03/06/2019 01:18 AM, Kenneth Graunke wrote:
> On Tuesday, March 5, 2019 10:20:10 PM PST Dave Airlie wrote:
>> On Wed, 6 Mar 2019 at 14:01, Brian Paul  wrote:
>>> I guess I don't fully understand a few things about the new meson build.
>>>
>>> 1. I'm trying to build the gallium VMware driver with this:
>>>
>>> export BUILD_DIR=build-meson-dri
>>>
>>> mkdir "${BUILD_DIR}"
>>>
>>> meson -Dshared-llvm=false \
>>>-Dplatforms=x11,drm \
>>>-Dgallium-drivers=svga \
>>>-Dvulkan-drivers= \
>>>"${BUILD_DIR}"
>>>
>>> ninja -C "${BUILD_DIR}"
>>>
>>> When it's done, there is no vmwgfx_dri.so driver file. So libGL
>>> complains that it can't find the svga driver (nor swrast).  I must be
>>> missing something.
>>
>> I don't think meson got the install in place stuff carried over, so I
>> think everyone does --prefix= somewhere
>> and that should create the vmwgfx_dri.so which will be a link to the
>> libgallium_dri.so you've found.
>
> Right.  Running 'ninja' and 'ninja install' together, for the entire
> project, is still faster than the old 'make' system (at least with an
> SSD)...so we didn't bother with the custom lib/ symlinks.
>
> I wrote a wrapper script for ninja that makes it easy to work with
> multiple build trees, can also automatically 'ninja install', and
> which can be run from anywhere in your git repository:
>
> https://nam04.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~kwg%2Fnj%2Fplain%2Fnjdata=02%7C01%7Cjfonseca%40vmware.com%7C68873d3170214283bd2f08d6a24aea95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636874839986720161sdata=bQLVu4ZVREZaXrg%2BCi6ZmGsz5PGYYsOVV5qP%2FsGIKJs%3Dreserved=0
>
> In my setup, I do:
>
> $ mkdir -p build/debug/install
> $ meson --buildtype=debug --prefix=$PWD/build/debug/install \
>-Ddri-drivers=i965 -Dgallium-drivers=iris -Dvulkan-drivers=intel \
>-Dglvnd=true -Dtools=intel,nir,glsl,intel-ui build/debug
>
> $ mkdir -p build/release/install
> $ CFLAGS='-O3 -g -fno-omit-frame-pointer -march=native' \
>CXXFLAGS='-O3 -g -fno-omit-frame-pointer -march=native' \
>meson --buildtype=release --prefix=$PWD/build/release/install \
>-Ddri-drivers=i965 -Dvulkan-drivers=intel -Dgallium-drivers=iris \
>-Dglvnd=true build/release
>
> Then,
>
> $ nj
>
> from anywhere in your Mesa repo will build and install the build/debug
> tree.  Or to use the build/release tree:
>
> $ nj release
> $ nj release clean
>
> You can simply point LD_LIBRARY_PATH at mesa/build/debug/install/lib to
> use your newly built Mesa (instead of pointing it at the old mesa/lib).
>
> For simpler projects, nj also works with a single 'build' directory
> (with no subdirectories), and it can also do in-tree builds if you're
> using CMake (say for Piglit).
>
> Hope this helps!

Yeah, doing a 'ninja install' with a few other tweaks to my script
solves the issue.  Thanks, Ken!


I'd like to point out that the Mesa doc page for Meson doesn't even
mention 'ninja install' despite the title of the page being "Compilation
and *Installation* using Meson"

Perhaps someone can fix that.  It would also be helpful to have a few
concrete examples of meson/ninja commands for common configurations.


>
>>> 2. When the build completes I see that there's a libgallium_dri.so file
>>> that's HUGE:
>>>
>>> $ ls -l build-meson-dri/src/gallium/targets/dri/libgallium_dri.so
>>>
>>> -rwxr-xr-x 1 brianp users 726507584 Mar  5 20:47
>>> build-meson-dri/src/gallium/targets/dri/libgallium_dri.so*
>>>
>>>
>>> 726MB seems a bit excessive.  The libvdpau_gallium.so and
>>> libxatracker.so libraries are also about that size.  What's the story there?
>>
>> meson build debug by default, I expect you've gotten a bunch of that.
>>
>> Dave.
>
> I suspect it also has to do with static LLVM.  Mine is only 49M with
> debugging symbols...

Yeah, that occurred to me too later.  But when I don't specify static
LLVM I get tons of undefined LLVM symbols:

[...]
src/gallium/auxiliary/libgallium.a(gallivm_lp_bld_tgsi.c.o): In function
`lp_build_action_set_dst_type':
/home/projects/Mesa-gitlab/mesa/build-meson-dri/../src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:94:
undefined reference to `LLVMTypeOf'
/home/projects/Mesa-gitlab/mesa/build-meson-dri/../src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:91:
undefined reference to `LLVMVoidTypeInContext'
[...]

I have LLVM 7.0 installed and see both static and dynamic libraries in
my /usr/local/lib/

-Brian

Re: [Mesa-dev] [PATCH 1/3] svga: keep a list of contexts for the screen

[Jose Fonseca]

I have few doubts/questions.

On 05/03/2019 23:57, Brian Paul wrote:

This will allow us to query whether a context is valid.

In addition to keeping a list of contexts, we need to give each
context we create a unique ID which is never re-used.  The screen
also contains a bitmask to track which IDs are valid.  We need the
ID since a context pointer could be recycled by the memory allocator.
---
  src/gallium/drivers/svga/svga_context.c |  7 +++
  src/gallium/drivers/svga/svga_context.h |  6 +++
  src/gallium/drivers/svga/svga_screen.c  | 86 +
  src/gallium/drivers/svga/svga_screen.h  | 23 +
  4 files changed, 122 insertions(+)

diff --git a/src/gallium/drivers/svga/svga_context.c 
b/src/gallium/drivers/svga/svga_context.c
index 7b3e9e8..1284d2f 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -57,6 +57,7 @@ DEBUG_GET_ONCE_BOOL_OPTION(force_hw_line_stipple, 
"SVGA_FORCE_HW_LINE_STIPPLE",
  static void
  svga_destroy(struct pipe_context *pipe)
  {
+   struct svga_screen *svgascreen = svga_screen(pipe->screen);
 struct svga_context *svga = svga_context(pipe);
 unsigned shader, i;
  
@@ -97,6 +98,9 @@ svga_destroy(struct pipe_context *pipe)
  
 svga->swc->destroy(svga->swc);
  
+   /* remove this context from the screen's list */

+   svga_screen_remove_context(svgascreen, svga);
+
 util_bitmask_destroy(svga->blend_object_id_bm);
 util_bitmask_destroy(svga->ds_object_id_bm);
 util_bitmask_destroy(svga->input_element_object_id_bm);
@@ -300,6 +304,9 @@ svga_context_create(struct pipe_screen *screen, void *priv, 
unsigned flags)
 svga->pred.query_id = SVGA3D_INVALID_ID;
 svga->disable_rasterizer = FALSE;
  
+   /* add this context to the screen's list */

+   svga_screen_save_context(svgascreen, svga);
+
 goto done;
  
  cleanup:

diff --git a/src/gallium/drivers/svga/svga_context.h 
b/src/gallium/drivers/svga/svga_context.h
index fc63ec3..2ec6b3f 100644
--- a/src/gallium/drivers/svga/svga_context.h
+++ b/src/gallium/drivers/svga/svga_context.h
@@ -441,6 +441,12 @@ struct svga_context
 struct u_upload_mgr *const0_upload;
 struct u_upload_mgr *tex_upload;
  
+   /** used for svga_screen's list of contexts */

+   struct list_head context_node;
+
+   /** A per-context ID which is never reused */
+   unsigned context_id;
+
 struct {
boolean no_swtnl;
boolean force_swtnl;
diff --git a/src/gallium/drivers/svga/svga_screen.c 
b/src/gallium/drivers/svga/svga_screen.c
index 6cb5a14..6f4e8fc 100644
--- a/src/gallium/drivers/svga/svga_screen.c
+++ b/src/gallium/drivers/svga/svga_screen.c
@@ -24,6 +24,7 @@
   **/
  
  #include "git_sha1.h" /* For MESA_GIT_SHA1 */

+#include "util/u_bitmask.h"
  #include "util/u_format.h"
  #include "util/u_memory.h"
  #include "util/u_inlines.h"
@@ -1129,6 +1130,11 @@ svga_screen_create(struct svga_winsys_screen *sws)
debug_printf("svga: msaa samples mask: 0x%x\n", svgascreen->ms_samples);
 }
  
+   LIST_INITHEAD(>contexts);

+   mtx_init(>contexts_mutex, mtx_plain);
+
+   svgascreen->context_id_bm = util_bitmask_create();
+
 (void) mtx_init(>tex_mutex, mtx_plain);
 (void) mtx_init(>swc_mutex, mtx_recursive);
  
@@ -1144,6 +1150,86 @@ error1:

  }
  
  
+/*

+ * Add the given context to the screen's list.
+ * This should be done once when a context is created.
+ */
+void
+svga_screen_save_context(struct svga_screen *svgascreen,
+ struct svga_context *svga)
+{
+   /* This context should not already be in the list */
+   assert(!svga_screen_context_exists(svgascreen, svga));
+
+   /* the context ID should not be set yet */
+   assert(svga->context_id == 0);
+
+   mtx_lock(>contexts_mutex);
+
+   /* Assign a unique ID to the svga context.  The ID is never reused */
+   svga->context_id = svgascreen->context_counter++;


post-increment doesn't look right, because context_counter is never 
initialied to 1 anywhere.   So it seems to me the first context will 
have a context_id of zero, which shouldn't happen.


I think we should rename `context_counter` to `last_context_id` and use 
pre-increment.



+
+   util_bitmask_set(svgascreen->context_id_bm, svga->context_id);
+
+   LIST_ADDTAIL(>context_node, >contexts);
+
+   mtx_unlock(>contexts_mutex);
+}
+
+
+/*
+ * Remove the given context from the screen's list.
+ * This should be done once when a context is destroyed;
+ */
+void
+svga_screen_remove_context(struct svga_screen *svgascreen,
+   struct svga_context *svga)
+{
+   /* This context should be in the list */
+   assert(svga_screen_context_exists(svgascreen, svga));
+
+   mtx_lock(>contexts_mutex);
+
+   /* remove the ID from the bitmask */
+   util_bitmask_clear(svgascreen->context_id_bm, svga->context_id);
+
+   LIST_DEL(>context_node);
+
+   mtx_unlock(>contexts_mutex);
+}
+
+
+/*
+ * Return true if the context 

Re: [Mesa-dev] [PATCH 2/2] gallium/util: add some const qualifiers in u_bitmask.c

[Jose Fonseca]

On 05/03/2019 23:56, Brian Paul wrote:

And add/update comments.
---
  src/gallium/auxiliary/util/u_bitmask.c | 16 ++--
  1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_bitmask.c 
b/src/gallium/auxiliary/util/u_bitmask.c
index 397b497..433a09d 100644
--- a/src/gallium/auxiliary/util/u_bitmask.c
+++ b/src/gallium/auxiliary/util/u_bitmask.c
@@ -90,7 +90,7 @@ static inline boolean
  util_bitmask_resize(struct util_bitmask *bm,
  unsigned minimum_index)
  {
-   unsigned minimum_size = minimum_index + 1;
+   const unsigned minimum_size = minimum_index + 1;
 unsigned new_size;
 util_bitmask_word *new_words;
  
@@ -131,7 +131,7 @@ util_bitmask_resize(struct util_bitmask *bm,
  
  
  /**

- * Lazily update the filled.
+ * Check if we can increment the filled counter.
   */
  static inline void
  util_bitmask_filled_set(struct util_bitmask *bm,
@@ -146,6 +146,10 @@ util_bitmask_filled_set(struct util_bitmask *bm,
 }
  }
  
+

+/**
+ * Check if we need to decrement the filled counter.
+ */
  static inline void
  util_bitmask_filled_unset(struct util_bitmask *bm,
unsigned index)
@@ -167,7 +171,7 @@ util_bitmask_add(struct util_bitmask *bm)
  
 assert(bm);
  
-   /* linear search for an empty index */

+   /* linear search for an empty index, starting at filled position */
 word = bm->filled / UTIL_BITMASK_BITS_PER_WORD;
 bit  = bm->filled % UTIL_BITMASK_BITS_PER_WORD;
 mask = 1 << bit;
@@ -249,9 +253,9 @@ boolean
  util_bitmask_get(struct util_bitmask *bm,
   unsigned index)
  {
-   unsigned word = index / UTIL_BITMASK_BITS_PER_WORD;
-   unsigned bit  = index % UTIL_BITMASK_BITS_PER_WORD;
-   util_bitmask_word mask = 1 << bit;
+   const unsigned word = index / UTIL_BITMASK_BITS_PER_WORD;
+   const unsigned bit  = index % UTIL_BITMASK_BITS_PER_WORD;
+   const util_bitmask_word mask = 1 << bit;
  
 assert(bm);
  



Series is

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

[Mesa-dev] [PATCH] scons: Workaround failures with MSVC when using SCons 3.0.[2-4].

[Jose Fonseca]

This change applies the workaround suggested by Bill Deegan on the
affected SCons versions.

It also adds a comment with the URL explaining why we were using
customizing the decider and max_drift in the first place, as I had
forgotten all about it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109443
Tested-by: liviupro...@yahoo.com
---
 scons/gallium.py | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/scons/gallium.py b/scons/gallium.py
index 963834a5fbc..efe32e06c6c 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -308,7 +308,13 @@ def generate(env):
 if env.GetOption('num_jobs') <= 1:
 env.SetOption('num_jobs', num_jobs())
 
-env.Decider('MD5-timestamp')
+# Speed up dependency checking.  See
+# - https://github.com/SCons/scons/wiki/GoFastButton
+# - https://bugs.freedesktop.org/show_bug.cgi?id=109443
+scons_version = distutils.version.StrictVersion(SCons.__version__)
+if scons_version < distutils.version.StrictVersion('3.0.2') or \
+   scons_version > distutils.version.StrictVersion('3.0.4'):
+env.Decider('MD5-timestamp')
 env.SetOption('max_drift', 60)
 
 # C preprocessor options
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH 2/2] appveyor: Add a Cygwin build script

[Jose Fonseca]

I just noticed these patches, because Appveyor build is broken, and to 
my surprise, on Cygwin.


There are several problems with these patches:

- First of all, there were commited with no reviewed by.  Not by me (a 
quick `git log appveyor.yml` would tell you I pretty much wrote and 
maitain it).  But worse of all, there's no review-by from anybody!  This 
is not a trivial change neither.  Honestly, I'm disappointed by these 
stealth commits.  I don't have time to keep up with mesa-dev threads, 
but I'm not MIA, and I've been responsive to all emails I've been CCed.


- Are you responsible for fixing the cygwin build? Somebody needs to 
ensure Cygwin build stays in good health.  Systematic failures of Cygwin 
will cause the mesa-dev list to be spammed, and other developers to 
become numb to failures. So we can't allow to happen.  On  the other 
hand, I'm not familiar with how mesa is supposed to build work on 
Cygwin, so I can't take than upon myself.


- The batch files are broken.  Cmd.exe will not stop processing a batch 
file when a error happens (appveyor does for comands started from 
.yml.)  so the scripts\appveyor_msvc.bat batch can fail one of the early 
commands, and the exit code won't propagate to appveyor.)


As it stands I'm about to revert these two changes.  We can bring cygwin 
support back once the above issues have been addresed.


Jose


On 14/12/2018 19:20, Jon Turney wrote:

Signed-off-by: Jon Turney 
---
  appveyor.yml| 19 +-
  scripts/appveyor_cygwin.bat | 40 +
  2 files changed, 54 insertions(+), 5 deletions(-)
  create mode 100644 scripts/appveyor_cygwin.bat

diff --git a/appveyor.yml b/appveyor.yml
index 0ec3a1e7bfe..9c6e5acd370 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -38,6 +38,9 @@ cache:
  - '%LOCALAPPDATA%\pip\Cache -> appveyor.yml'
  - win_flex_bison-2.5.15.zip
  - llvm-5.0.1-msvc2017-mtd.7z
+- C:\pkgcache
+- 'C:\cygwin64\home\%USERNAME%\.ccache'
+- 'C:\cygwin\home\%USERNAME%\.ccache'
  
  os: Visual Studio 2017
  
@@ -47,17 +50,23 @@ init:

  - git config --global core.autocrlf true
  
  environment:

-  WINFLEXBISON_VERSION: 2.5.15
-  LLVM_ARCHIVE: llvm-5.0.1-msvc2017-mtd.7z
+  matrix:
+  - compiler: msvc
+WINFLEXBISON_VERSION: 2.5.15
+LLVM_ARCHIVE: llvm-5.0.1-msvc2017-mtd.7z
+  - compiler: cygwin
+arch: x64
  
  install:

-- call scripts\appveyor_msvc.bat install
+- call scripts\appveyor_%compiler%.bat install
  
  build_script:

-- call scripts\appveyor_msvc.bat build_script
+- call scripts\appveyor_%compiler%.bat build_script
  
  after_build:

-- call scripts\appveyor_msvc.bat after_build
+- call scripts\appveyor_%compiler%.bat after_build
+
+test: off
  
  # It's possible to setup notification here, as described in

  # 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.appveyor.com%2Fdocs%2Fnotifications%23appveyor-yml-configurationdata=02%7C01%7Cjfonseca%40vmware.com%7C7e9e0b630a3e44c0101708d661f97a40%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636804121479341361sdata=0H2uZbwA9%2BFlkyDQtcsjXjbEQtthAOGfxh%2BfcCS%2Bd8M%3Dreserved=0
 , but
diff --git a/scripts/appveyor_cygwin.bat b/scripts/appveyor_cygwin.bat
new file mode 100644
index 000..831270b8cd3
--- /dev/null
+++ b/scripts/appveyor_cygwin.bat
@@ -0,0 +1,40 @@
+set PKGCACHE=C:\pkgcache
+set CYGWIN_MIRROR=http://cygwin.mirror.constant.com
+
+if _%arch%_ == _x64_ set SETUP=setup-x86_64.exe && set CYGWIN_ROOT=C:\cygwin64
+if _%arch%_ == _x86_ set SETUP=setup-x86.exe && set CYGWIN_ROOT=C:\cygwin
+
+set PATH=%CYGWIN_ROOT%\bin;%SYSTEMROOT%\system32
+
+goto %1
+
+:install
+echo Updating Cygwin and installing build prerequsites
+%CYGWIN_ROOT%\%SETUP% -qnNdO -R "%CYGWIN_ROOT%" -s "%CYGWIN_MIRROR%" -l 
"%PKGCACHE%" -g -P ^
+bison,^
+ccache,^
+flex,^
+glproto,^
+libX11-devel,^
+libX11-xcb-devel,^
+libXdamage-devel,^
+libXext-devel,^
+libXfixes-devel,^
+libexpat-devel,^
+libllvm-devel,^
+libxcb-dri2-devel,^
+libxcb-glx-devel,^
+libxcb-xfixes-devel,^
+meson,^
+ninja,^
+python3-mako,^
+zlib-devel
+goto :eof
+
+:build_script
+bash -lc "cd $APPVEYOR_BUILD_FOLDER; meson _build -Degl=false --wrap-mode=nofallback 
&& ninja -C _build"
+goto :eof
+
+:after_build
+bash -lc "cd $APPVEYOR_BUILD_FOLDER; ninja -C _build test"
+goto :eof



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

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

[Jose Fonseca]

On 11/01/2019 22:38, Matt Turner wrote:

On Fri, Jan 11, 2019 at 2:28 PM Ilia Mirkin  wrote:


On Fri, Jan 11, 2019 at 5:12 PM Matt Turner  wrote:


From: Gert Wollny 

Since Meson will eventually be the only build system deprecate autotools
now. It can still be used by invoking configure with the flag
   --enable-autotools

NAKed-by: Ilia Mirkin 


[nouveau]


Acked-by: Eric Engestrom 
Acked-by: Kenneth Graunke 
Acked-by: Lionel Landwerlin 
Acked-by: Jason Ekstrand 
Reviewed-by: Matt Turner 


[intel]


Acked-by: Rob Clark 


[freedreno]


Acked-by: Marek Olšák 


[radeon]


Reviewed-by: Christian Gmeiner 


[etnaviv]


Reviewed-by: Eric Anholt 


[vc4]


Signed-off-by: Gert Wollny 


[sorry Gert, not sure how to classify you]

I think the vmware team (which largely maintains llvmpipe and svga) is
probably worth hearing from -- I believe they've largely stayed out of
it. But an ack/nack would be good. Also virgl isn't represented, I
believe. Probably not *required* to hear from these, but perhaps worth
a poke?


Sure. I've Cc'd Dave, Brian, José, and Roland on this reply.


Thanks for letting us know.  No concerns for my part FWIW, though my 
involvement on Mesa has been minimal lately.  I think for some of my 
colleagues might be different, but I've been using SCons almost 
exclusively for a very long time, so autotools removal doesn't affect me.


autotools could never become "the build the system to rule them all", in 
Mesa-land, due to the lack of Windows, but there's at least hope Meson 
might one day become it.


For the time where SCons is still around, I wonder if there's value in 
keeping Makefile.sources, or we should just fold them into SConscripts? 
Because they add complexity to SCons which now makes little point, 
unless there's some way to share source file lists between SCons and Meson?


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

Re: [Mesa-dev] [PATCH] gallivm: abort when trying to use non-existing intrinsic

[Jose Fonseca]

On 21/12/2018 14:28, Roland Scheidegger wrote:

Am 21.12.18 um 08:46 schrieb Jose Fonseca:

On 21/12/2018 01:42, srol...@vmware.com wrote:

From: Roland Scheidegger 

Whenever llvm removes an intrinsic (we're using), we're hitting segfaults
due to llvm doing calls to address 0 in the jitted code instead.
However, Jose figured out we can actually detect this with
LLVMGetIntrinsicID(), so use this to abort, so we don't have to wonder
what got broken. (Of course, someone still needs to fix the code to
no longer use this intrinsic.)
---
   src/gallium/auxiliary/gallivm/lp_bld_intr.c | 10 ++
   1 file changed, 10 insertions(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_intr.c
b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
index 74ed16f33f0..c9df136b103 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_intr.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
@@ -241,6 +241,16 @@ lp_build_intrinsic(LLVMBuilderRef builder,
       function = lp_declare_intrinsic(module, name, ret_type,
arg_types, num_args);
   +  /*
+   * If llvm removes an intrinsic we use, we'll hit this abort
(rather
+   * than a call to address zero in the jited code).
+   */
+  if (LLVMGetIntrinsicID(function) == 0) {
+ printf("llvm (version 0x%x) found no intrinsic for %s, going
to crash...\n",
+    HAVE_LLVM, name);


Better to use _debug_printf() so it's redirected to stderr (or
OutpuDebug on Windows.)

Alright, though this will drop the output on non-debug builds.


Not really: debug_printf only prints on debug build, but  _debug_printf 
(note the leading underscore) always print.


Perhaps it's not the smartest naming convention, but it should do the 
expected.



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

Re: [Mesa-dev] [PATCH] gallivm: abort when trying to use non-existing intrinsic

[Jose Fonseca]

On 21/12/2018 01:42, srol...@vmware.com wrote:

From: Roland Scheidegger 

Whenever llvm removes an intrinsic (we're using), we're hitting segfaults
due to llvm doing calls to address 0 in the jitted code instead.
However, Jose figured out we can actually detect this with
LLVMGetIntrinsicID(), so use this to abort, so we don't have to wonder
what got broken. (Of course, someone still needs to fix the code to
no longer use this intrinsic.)
---
  src/gallium/auxiliary/gallivm/lp_bld_intr.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_intr.c 
b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
index 74ed16f33f0..c9df136b103 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_intr.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
@@ -241,6 +241,16 @@ lp_build_intrinsic(LLVMBuilderRef builder,
  
function = lp_declare_intrinsic(module, name, ret_type, arg_types, num_args);
  
+  /*

+   * If llvm removes an intrinsic we use, we'll hit this abort (rather
+   * than a call to address zero in the jited code).
+   */
+  if (LLVMGetIntrinsicID(function) == 0) {
+ printf("llvm (version 0x%x) found no intrinsic for %s, going to 
crash...\n",
+HAVE_LLVM, name);


Better to use _debug_printf() so it's redirected to stderr (or 
OutpuDebug on Windows.)



+ abort();
+  }
+
if (!set_callsite_attrs)
   lp_add_func_attributes(function, attr_mask);
  



I think it's worth auditing we don't use lp_build_intrinsic() helper for 
LLVM functions we built ourselves.  I took a look, and didn't found any.


Otherwise

Reviewed-by: Jose Fonseca 

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

Re: [Mesa-dev] [PATCH] gallivm: don't use pavg.b intrinsic on llvm >= 6.0

[Jose Fonseca]

ntinue;
+ /* only have util fetch func for etc1 */
+ if (format_desc->layout == UTIL_FORMAT_LAYOUT_ETC &&
+ format != PIPE_FORMAT_ETC1_RGB8) {
+continue;
+ }
  
-  /* only have util fetch func for etc1 */

-  if (format_desc->layout == UTIL_FORMAT_LAYOUT_ETC &&
-  format != PIPE_FORMAT_ETC1_RGB8) {
- continue;
-  }
+ /* missing fetch funcs */
+ if (format_desc->layout == UTIL_FORMAT_LAYOUT_ASTC) {
+continue;
+ }
  
-  /* missing fetch funcs */

-  if (format_desc->layout == UTIL_FORMAT_LAYOUT_ASTC) {
- continue;
-  }
+ /* only test twice with formats which can use cache */
+ if (format_desc->layout != UTIL_FORMAT_LAYOUT_S3TC && use_cache) {
+continue;
+ }
  
-  if (!test_one(verbose, fp, format_desc)) {

-   success = FALSE;
+ if (!test_one(verbose, fp, format_desc, use_cache)) {
+  success = FALSE;
+ }
}
 }
-#if USE_TEXTURE_CACHE
 align_free(cache_ptr);
-#endif
  
 return success;

  }



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

Re: [Mesa-dev] [PATCH] gallivm: use llvm jit code for decoding s3tc

[Jose Fonseca]

There's an function -- LLVMGetIntrinsicID -- I wonder if we can use it 
to trap unsupported intrinsics?


Jose

On 20/12/2018 22:09, Roland Scheidegger wrote:

Am 20.12.18 um 16:56 schrieb Michel Dänzer:

On 2018-12-19 4:51 a.m., srol...@vmware.com wrote:

From: Roland Scheidegger 

This is (much) faster than using the util fallback.
(Note that there's two methods here, one would use a cache, similar to
the existing code (although the cache was disabled), except the block
decode is done with jit code, the other directly decodes the required
pixels. For now don't use the cache (being direct-mapped is suboptimal,
but it's difficult to come up with something better which doesn't have
too much overhead.)


This change made lp_test_format segfault on my Ryzen 7 1700, both using
LLVM 7 and current SVN HEAD. Not much information in the backtrace
unfortunately:



Ahh I failed to test with newer llvm versions (it works with llvm 5.0 at
least).
It is (once again...) due to intrinsics disappearing from llvm.
I especially hate it that there's seemingly no way to detect if an
intrinsic has disappeared, since llvm will just replace it will calls to
address 0 if the intrinsic doesn't exist nowadays...
Probably it's the llvm.x86.sse2.pavg.b intrinsic, I'll fix it...

Roland




Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x77fcd16a in ?? ()
#2  0x2c2c2c2caeaeaeae in ?? ()
#3  0x979797976f6f6f6f in ?? ()
#4  0x20b0d7f2 in ?? ()
#5  0x976f2cae in ?? ()
#6  0x0089625d008eb099 in ?? ()
#7  0x7b8487218483a821 in ?? ()
#8  0x008414210094ffd6 in ?? ()
#9  0x007bef9400739629 in ?? ()
#10 0x0069 in ?? ()
#11 0x06d0 in ?? ()
#12 0x7fffe490 in ?? ()
#13 0x5593f040 in ?? ()
#14 0x7fffe430 in ?? ()
#15 0x77fcd053 in ?? ()
#16 0x77fcd000 in ?? ()
#17 0x556fd618 in util_format_test_cases ()
#18 0x558c0780 in ?? ()
#19 0x7fffe490 in ?? ()
#20 0x556fd618 in util_format_test_cases ()
#21 0x555667cc in test_format_float (verbose=, 
desc=0x7fffe4a0, fp=0x0) at ../src/gallium/drivers/llvmpipe/lp_test_format.c:184
#22 test_one (verbose=, format_desc=0x7fffe4a0, fp=0x0) at 
../src/gallium/drivers/llvmpipe/lp_test_format.c:342
#23 test_all (verbose=, fp=0x0) at 
../src/gallium/drivers/llvmpipe/lp_test_format.c:395
#24 0x5556621f in main (argc=1, argv=0x7fffe628) at 
../src/gallium/drivers/llvmpipe/lp_test_main.c:419






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

Re: [Mesa-dev] [PATCH] gallivm: remove unused float coord wrapping for aos sampling

[Jose Fonseca]

   lp_build_sample_image_nearest_afloat(bld,
-size1,
-row_stride1_vec, 
img_stride1_vec,
-data_ptr1, mipoff1, s, t, 
r, offsets,
-);
-}
-else {
-   lp_build_sample_image_linear_afloat(bld,
-   size1,
-   row_stride1_vec, 
img_stride1_vec,
-   data_ptr1, mipoff1, s, t, 
r, offsets,
-   );
-}
+ if (img_filter == PIPE_TEX_FILTER_NEAREST) {
+lp_build_sample_image_nearest(bld,
+  size1,
+  row_stride1_vec, img_stride1_vec,
+  data_ptr1, mipoff1, s, t, r, offsets,
+  );
   }
   else {
-if (img_filter == PIPE_TEX_FILTER_NEAREST) {
-   lp_build_sample_image_nearest(bld,
- size1,
- row_stride1_vec, img_stride1_vec,
- data_ptr1, mipoff1, s, t, r, 
offsets,
- );
-}
-else {
-   lp_build_sample_image_linear(bld,
-size1,
-row_stride1_vec, img_stride1_vec,
-data_ptr1, mipoff1, s, t, r, 
offsets,
-);
-}
+lp_build_sample_image_linear(bld,
+ size1,
+ row_stride1_vec, img_stride1_vec,
+ data_ptr1, mipoff1, s, t, r, offsets,
+ );
   }
  
   /* interpolate samples from the two mipmap levels */




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

Re: [Mesa-dev] Make Jordan an Owner of the mesa project?

[Jose Fonseca]

ACK.


Jose



From: Jason Ekstrand 
Sent: Tuesday, December 4, 2018 00:48
To: ML mesa-dev
Cc: Nicolai Hähnle; Ian Romanick; Ilia Mirkin; Dave Airlie; Kenneth Graunke; 
Matt Turner; Brian Paul; Jose Fonseca; Eric Anholt; Marek Olšák; Rob Clark
Subject: Make Jordan an Owner of the mesa project?

Jordan has requested to be made an Owner of the mesa project.  As much as I may 
be the guy who pushed to get everything set up, I don't want to do this sort of 
thing on my own.  As such, I'm asking for some ACKs.  If I can get 5 ACKs (at 
least 2 non-intel) from other Owners and no NAKs, I'll click the button.

Personally, I think the answer here is absurdly obvious.  Jordan is one of the 
most involved people in the community. :-D

As a side-note, does this seem like a reasonable process for adding people as 
Owners?

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

Re: [Mesa-dev] [PATCH] draw: fix infinite loop in line stippling

[Jose Fonseca]

On 23/11/2018 01:34, srol...@vmware.com wrote:

From: Roland Scheidegger 

The calculated length of a line may be infinite, if the coords we
get are bogus. This leads to an infinite loop in line stippling.
To prevent this test for this explicitly (although technically
on at least x86 sse it would actually work without the explicit
test, as long as we use the int-converted length value).
While here also get rid of some always-true condition.

Note this does not actually solve the root cause, which is that
the coords we receive are bogus after clipping. This seems a difficult
problem to solve. One issue is that due to float arithmetic, clip w
may become 0 after clipping if the incoming geometry is
"sufficiently degenerate", hence x/y/z ndc (and window) coords will
be all inf (or nan). Even with w not quite 0, I believe it's possible
we produce values which are actually outside the view volume.
(Also, x=y=z=w=0 coords in clipspace would be not considered subject
to clipping, and similarly result in all NaN coords.) We just hope for
now other draw stages (and rasterizers) can handle those relatively
safely (llvmpipe itself should be sort of robust against this, certainly
converstion to fixed point will produce garbage, it might fail a couple
assertions but should neither hang nor crash otherwise).
---
  .../auxiliary/draw/draw_pipe_stipple.c| 26 +++
  1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_stipple.c 
b/src/gallium/auxiliary/draw/draw_pipe_stipple.c
index d30572cc61..386b7649e4 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_stipple.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_stipple.c
@@ -48,8 +48,8 @@
  struct stipple_stage {
 struct draw_stage stage;
 float counter;
-   uint pattern;
-   uint factor;
+   ushort pattern;
+   ushort factor;
 bool smooth;
  };
  
@@ -110,7 +110,7 @@ emit_segment(struct draw_stage *stage, struct prim_header *header,
  
  
  static inline bool

-stipple_test(int counter, ushort pattern, int factor)
+stipple_test(int counter, ushort pattern, ushort factor)
  {
 int b = (counter / factor) & 0xf;
 return !!((1 << b) & pattern);
@@ -136,6 +136,10 @@ stipple_line(struct draw_stage *stage, struct prim_header 
*header)
  
 float length;

 int i;
+   int intlength;
+
+   if (header->flags & DRAW_PIPE_RESET_STIPPLE)
+  stipple->counter = 0;
  
 if (stipple->smooth) {

float dx = x1 - x0;
@@ -147,21 +151,21 @@ stipple_line(struct draw_stage *stage, struct prim_header 
*header)
length = MAX2(dx, dy);
 }
  
-   if (header->flags & DRAW_PIPE_RESET_STIPPLE)

-  stipple->counter = 0;
+   if (util_is_inf_or_nan(length))
+  intlength = 0;
+   else
+  intlength = ceilf(length);
  
 /* XXX ToDo: instead of iterating pixel-by-pixel, use a look-up table.

  */
-   for (i = 0; i < length; i++) {
+   for (i = 0; i < intlength; i++) {
bool result = stipple_test((int)stipple->counter + i,
- (ushort)stipple->pattern, stipple->factor);
+ stipple->pattern, stipple->factor);
if (result != state) {
   /* changing from "off" to "on" or vice versa */
   if (state) {
-if (start != i) {
-   /* finishing an "on" segment */
-   emit_segment(stage, header, start / length, i / length);
-}
+/* finishing an "on" segment */
+emit_segment(stage, header, start / length, i / length);
   }
   else {
  /* starting an "on" segment */



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

Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function available on non-standard platforms

[Jose Fonseca]

On 21/11/2018 21:17, Ian Romanick wrote:

On 11/21/2018 12:16 PM, Jose Fonseca wrote:

    util: use standard name for strncat()



    util: use standard name for strncmp()
    util: use standard name for strcmp()
    util: use standard name for strchr()
    util: use standard name for sprintf()
    util: use standard name for vasprintf()
    util: use standard name for vsprintf()
    util: use standard name for snprintf()
    util: use standard name for vsnprintf()



Generally I agree with the principle of using standard functions, and
provide drop-in replacements for the systems where they are broken.  It
leads to less friction, less need to learn new things.


But C string functions is IMO a special case, because the standard
functions are so poorly designed, and make writing correct and secure
code so dawm difficult:

- snprintf doesn't write the null char

- strncat n parameter is awkard to use

-  vasprintf have different return codes on different systems.
According to GNU manpages, it's not even C or POSIX.


And a standard for the sake of standard is just silly.


So IMO, if people care and have the time to uniformize these things, I
think they should move away standard C functions, and write some sane C
string manipulation abstraction/helpers.  And we should make GCC throw
warnings every time people try to use the standard C string functions.



  All of these functions appear to have been added by 131a1fbc91725.  I've

added Jose to CC since he wrote it.  [...]



  That doesn't give much insight. :(




:(



*sigh*


The reason for adding was in b1922de9f3478869c6788ef4e954c06c20e7aa9c .


Right... I was more thinking about the str* functions than the *printf
functions.  Locale problems with scanf / printf are real on every
platform.  We had issues with this in the GLSL parser due to "." vs ","
as the ones to tenths separator in floating point numbers.  Other
*printf portability problems are real too.  I don't think there's any
variation with strchr or strstr, though. :)

Specifically, I (and I guess Emil also) propose removing the wrappers for:

  - strchr
  - strstr
  - strcmp (does this have locale issues?)
  - strncmp (does this have locale issues?)
  - strncat

And leave the rest for at least the time being.


For those, yes, it should be fine.

I'm not 100% sure if MSVC provides them all, but we can always fallback 
to a #define where not.


strcmp/strncmp don't seem to consider locale, and we typically only use 
them for ASCII string equality comparison anyway.


Jose


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

Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function available on non-standard platforms

[Jose Fonseca]

> vasprintf have different return codes on different systems.

Forget this. I was mixing up with the other  function that calculates how many 
chars a xxxprintf function would write, which we use to implement vasprintf.

Jose

From: Jose Fonseca
Sent: Wednesday, November 21, 2018 8:16:35 PM
To: Ian Romanick; Eric Engestrom; mesa-dev@lists.freedesktop.org
Cc: Brian Paul; Roland Scheidegger; Neha Bhende; Charmaine Lee
Subject: Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function available on 
non-standard platforms


>   util: use standard name for strncat()

>   util: use standard name for strncmp()
>   util: use standard name for strcmp()
>   util: use standard name for strchr()
>   util: use standard name for sprintf()
>   util: use standard name for vasprintf()
>   util: use standard name for vsprintf()
>   util: use standard name for snprintf()
>   util: use standard name for vsnprintf()


Generally I agree with the principle of using standard functions, and provide 
drop-in replacements for the systems where they are broken.  It leads to less 
friction, less need to learn new things.


But C string functions is IMO a special case, because the standard functions 
are so poorly designed, and make writing correct and secure code so dawm 
difficult:

- snprintf doesn't write the null char

- strncat n parameter is awkard to use

-  vasprintf have different return codes on different systems.  According to 
GNU manpages, it's not even C or POSIX.


And a standard for the sake of standard is just silly.


So IMO, if people care and have the time to uniformize these things, I think 
they should move away standard C functions, and write some sane C string 
manipulation abstraction/helpers.  And we should make GCC throw warnings every 
time people try to use the standard C string functions.


> All of these functions appear to have been added by 131a1fbc91725.  I've
added Jose to CC since he wrote it.  [...]


> That doesn't give much insight. :(


> :(


*sigh*


The reason for adding was in b1922de9f3478869c6788ef4e954c06c20e7aa9c .  We 
needed those because XP kernel driver environment didn't provide a complete  
CRT.  But we dropped XP kernel support long time ago, so that's no longer 
relevant.


I believe the reason these functions became widespread since then was the fact 
that MSVC functions didn't follow C99 (e.g., ll), but that might no longer be 
an issue with MSVC 2017 runtime.  This needs to be verified.


Finally there's also the fact that standard snprintf is sensitive to current 
locale, which is a bad idea for driver code.   I suppose this is not an issue 
for Linux, which has always used snprintf underneath.  But we need to double 
check all other util_snprintf .  It's possible that the mere fact we statically 
link CRT is sufficient to protect us from that (since it ends up being like a 
completely different CRT instant from the application), but I'm not 100% sure.


Jose


From: Ian Romanick 
Sent: Wednesday, November 21, 2018 18:47
To: Eric Engestrom; mesa-dev@lists.freedesktop.org
Cc: Jose Fonseca
Subject: Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function available on 
non-standard platforms

On 11/20/2018 05:11 AM, Eric Engestrom wrote:
> ... instead of making standard platforms use non-standard functions.

I haven't looked at the specific patches, so this comment may not apply.
 When we first headed down the path of adding a billion wrapper
functions, I campaigned pretty strongly to give them the standard names.
 The problem is that some platforms have functions with the standard
names that deviate from the standard behavior in ways that make them
unusable.  I think one of the printf-like functions was the main problem
here, but it was a long time ago.

Either way, you can't give the wrapper the standard name in this case.
Once you have to name one wrapper function _foo_standard_name, you might
as well name them all like that.

> This also reduces the likelihood of someone forgetting to use the
> non-standard function, and reduces the fix to a simple #include.

If we cared, I bet we could write a 'make check' test that would just
grep through the tree for functions that are supposed to be wrapped.
The test would fail if a non-wrapped version was used.  We'd probably
have to use Python, so I don't know how much effort it would be.

> Changes generated using this shell function for each function name:
>   fix() {
> files=$(ag -lw util_$1)
> sed s/'\'/$1/g -i $files
> git add -up $files
> git commit -sm 'util: use standard name for '$1'()'
>   }
>
> Eric Engestrom (13):
>   util: use standard name for strchrnul()
>   util: use standard name for strcasecmp()
>   util: use standard name for strdup()
>   util: use standard name for strstr()

What the... ?  strstr is part of C89.  What platform actually needs a
wrappe

Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function available on non-standard platforms

[Jose Fonseca]

>   util: use standard name for strncat()

>   util: use standard name for strncmp()
>   util: use standard name for strcmp()
>   util: use standard name for strchr()
>   util: use standard name for sprintf()
>   util: use standard name for vasprintf()
>   util: use standard name for vsprintf()
>   util: use standard name for snprintf()
>   util: use standard name for vsnprintf()


Generally I agree with the principle of using standard functions, and provide 
drop-in replacements for the systems where they are broken.  It leads to less 
friction, less need to learn new things.


But C string functions is IMO a special case, because the standard functions 
are so poorly designed, and make writing correct and secure code so dawm 
difficult:

- snprintf doesn't write the null char

- strncat n parameter is awkard to use

-  vasprintf have different return codes on different systems.  According to 
GNU manpages, it's not even C or POSIX.


And a standard for the sake of standard is just silly.


So IMO, if people care and have the time to uniformize these things, I think 
they should move away standard C functions, and write some sane C string 
manipulation abstraction/helpers.  And we should make GCC throw warnings every 
time people try to use the standard C string functions.


> All of these functions appear to have been added by 131a1fbc91725.  I've
added Jose to CC since he wrote it.  [...]


> That doesn't give much insight. :(


> :(


*sigh*


The reason for adding was in b1922de9f3478869c6788ef4e954c06c20e7aa9c .  We 
needed those because XP kernel driver environment didn't provide a complete  
CRT.  But we dropped XP kernel support long time ago, so that's no longer 
relevant.


I believe the reason these functions became widespread since then was the fact 
that MSVC functions didn't follow C99 (e.g., ll), but that might no longer be 
an issue with MSVC 2017 runtime.  This needs to be verified.


Finally there's also the fact that standard snprintf is sensitive to current 
locale, which is a bad idea for driver code.   I suppose this is not an issue 
for Linux, which has always used snprintf underneath.  But we need to double 
check all other util_snprintf .  It's possible that the mere fact we statically 
link CRT is sufficient to protect us from that (since it ends up being like a 
completely different CRT instant from the application), but I'm not 100% sure.


Jose


From: Ian Romanick 
Sent: Wednesday, November 21, 2018 18:47
To: Eric Engestrom; mesa-dev@lists.freedesktop.org
Cc: Jose Fonseca
Subject: Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function available on 
non-standard platforms

On 11/20/2018 05:11 AM, Eric Engestrom wrote:
> ... instead of making standard platforms use non-standard functions.

I haven't looked at the specific patches, so this comment may not apply.
 When we first headed down the path of adding a billion wrapper
functions, I campaigned pretty strongly to give them the standard names.
 The problem is that some platforms have functions with the standard
names that deviate from the standard behavior in ways that make them
unusable.  I think one of the printf-like functions was the main problem
here, but it was a long time ago.

Either way, you can't give the wrapper the standard name in this case.
Once you have to name one wrapper function _foo_standard_name, you might
as well name them all like that.

> This also reduces the likelihood of someone forgetting to use the
> non-standard function, and reduces the fix to a simple #include.

If we cared, I bet we could write a 'make check' test that would just
grep through the tree for functions that are supposed to be wrapped.
The test would fail if a non-wrapped version was used.  We'd probably
have to use Python, so I don't know how much effort it would be.

> Changes generated using this shell function for each function name:
>   fix() {
> files=$(ag -lw util_$1)
> sed s/'\'/$1/g -i $files
> git add -up $files
> git commit -sm 'util: use standard name for '$1'()'
>   }
>
> Eric Engestrom (13):
>   util: use standard name for strchrnul()
>   util: use standard name for strcasecmp()
>   util: use standard name for strdup()
>   util: use standard name for strstr()

What the... ?  strstr is part of C89.  What platform actually needs a
wrapper for this?  I see zero uses in the code base of util_strstr.
Ditto for strdup, strncmp, strcmp, strchr, and possibly others.  I
looked, and Microsoft has strncmp at least as far back as Visual Studio
2012.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fprevious-versions%2Fvisualstudio%2Fvisual-studio-2012%2Feywx8zcx(v%3Dvs.110data=02%7C01%7Cjfonseca%40vmware.com%7Cc87f73c43298407e4aeb08d64fe1bc31%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636784228289598865sdata=Gg%2B%2BlQmc4wmh7k0zohBEdUatGjdCkPDnmC

Re: [Mesa-dev] [PATCH] gallivm: fix improper clamping of vertex index when fetching gs inputs

[Jose Fonseca]

->uint_bld,

  indirect_index,
@@ -1502,7 +1506,15 @@ emit_fetch_gs_input(
attrib_index = get_indirect_index(bld,
  reg->Register.File,
  reg->Register.Index,
->Indirect);
+>Indirect,
+   /*
+* XXX: this is possibly not quite the right value, since file_max may be
+* larger than the max attrib index, due to it being the max of declared
+* inputs AND the max vertices per prim (which is 6 for tri adj).
+* It should however be safe to use (since we always allocate
+* PIPE_MAX_SHADER_INPUTS (80) for it, which is overallocated quite a bit).
+*/
+info->file_max[reg->Register.File]);
 } else {
attrib_index = lp_build_const_int32(gallivm, reg->Register.Index);
 }
@@ -1511,7 +1523,11 @@ emit_fetch_gs_input(
vertex_index = get_indirect_index(bld,
  reg->Register.File,
  reg->Dimension.Index,
->DimIndirect);
+>DimIndirect,
+   /*
+* A fixed 6 should do as well (which is what we allocate).
+*/


This mid-call comment makes code hard to read.  let's just put the 
`u_vertices_per_prim(info->properties[TGSI_PROPERTY_GS_INPUT_PRIM])` in 
a local variable before get_indirect_index call and comment there.




+
u_vertices_per_prim(info->properties[TGSI_PROPERTY_GS_INPUT_PRIM]));
 } else {
vertex_index = lp_build_const_int32(gallivm, reg->Dimension.Index);
 }
@@ -1565,7 +1581,8 @@ emit_fetch_temporary(
indirect_index = get_indirect_index(bld,
reg->Register.File,
reg->Register.Index,
-  >Indirect);
+  >Indirect,
+  
bld->bld_base.info->file_max[reg->Register.File]);
  
index_vec = get_soa_array_offsets(_base->uint_bld,

  indirect_index,
@@ -1785,7 +1802,8 @@ emit_store_chan(
indirect_index = get_indirect_index(bld,
reg->Register.File,
reg->Register.Index,
-  >Indirect);
+  >Indirect,
+          
bld->bld_base.info->file_max[reg->Register.File]);
 } else {
assert(reg->Register.Index <=
   bld_base->info->file_max[reg->Register.File]);



Otherwise looks great.

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

Re: [Mesa-dev] [PATCH 10/12] llvmpipe: remove pre LLVM 5.0 codepath

[Jose Fonseca]

On 31/10/2018 13:30, Emil Velikov wrote:

From: Emil Velikov 

LLVM versions earlier than 5.0.1 are no longer supported.

Cc: Roland Scheidegger 
Cc: Jose Fonseca 
Signed-off-by: Emil Velikov 
---
  src/gallium/drivers/llvmpipe/lp_jit.c | 4 
  1 file changed, 4 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_jit.c 
b/src/gallium/drivers/llvmpipe/lp_jit.c
index e2309f47157..ae5b0fe8151 100644
--- a/src/gallium/drivers/llvmpipe/lp_jit.c
+++ b/src/gallium/drivers/llvmpipe/lp_jit.c
@@ -223,13 +223,9 @@ lp_jit_create_types(struct lp_fragment_shader_variant *lp)
 }
  
 if (gallivm_debug & GALLIVM_DEBUG_IR) {

-#if HAVE_LLVM >= 0x304
char *str = LLVMPrintModuleToString(gallivm->module);
fprintf(stderr, "%s", str);
LLVMDisposeMessage(str);
-#else
-  LLVMDumpModule(gallivm->module);
-#endif
 }
  }
  



This and patch 3 looks good too.

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

Re: [Mesa-dev] [PATCH 09/12] gallivm: remove workarounds for pre LLVM 5.0

[Jose Fonseca]

On 31/10/2018 13:30, Emil Velikov wrote:

From: Emil Velikov 

With LLVM 5.0.1 the minimum required version, we can drop all the dead
code.

Cc: Roland Scheidegger 
Cc: Jose Fonseca 
Signed-off-by: Emil Velikov 
---
Gents this is a quick and dirty grep job. A couple of places may need
the comments to be tweaked/dropped - I've annotated those with XXX.


[..]

Nice cleanup. Thanks.

Could you please re-indent the # pragma for DEBUG macro.  Otherwise 
looks perfect.  I'm also OK leaving the XXX comments for now and revisit 
later.


Reviewed-by: Jose Fonseca 

Jose

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

Re: [Mesa-dev] [PATCH 07/31] nir/opt_if: Rework condition propagation

[Jose Fonseca]

On 22/10/18 23:13, Jason Ekstrand wrote:
> Instead of doing our own constant folding, we just emit instructions and
> let constant folding happen.  This is substantially simpler and lets us
> use the nir_imm_bool helper instead of dealing with the const_value's
> ourselves.
> ---
>   src/compiler/nir/nir_opt_if.c | 91 ---
>   1 file changed, 30 insertions(+), 61 deletions(-)
> 
> diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
> index 0c94aa170b5..60368a0259e 100644
> --- a/src/compiler/nir/nir_opt_if.c
> +++ b/src/compiler/nir/nir_opt_if.c
[...]
> +   nir_ssa_def *def[2] = { };

I'm afraid empty struct/array initializers aren't standard C and MSVC 
throws an error.

I really wish there was some GCC warning we could enable for this, as it 
appears to be a common mistake, particularly on nir, probably due to all 
simple POD structs.  But I couldn't find one.

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

Re: [Mesa-dev] [PATCH] scons/svga: remove opt from the list of valid build types

[Jose Fonseca]

Looks great.

Reviewed-by: Jose Fonseca 

On 26/10/18 17:52, Brian Paul wrote:
> This reverts commit a5fd54f8bf6713312fa5efd7ef5cd125557a0ffe.
> 
> The whole point was to add a way to pass -DVMX86_STATS to the build,
> but we can do that with a command line argument when we invoke scons.
> ---
>   common.py  | 2 +-
>   scons/gallium.py   | 8 +++-
>   src/gallium/drivers/svga/svga_screen.c | 2 --
>   3 files changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/common.py b/common.py
> index be3ccfc..e2afff9 100644
> --- a/common.py
> +++ b/common.py
> @@ -86,7 +86,7 @@ def AddOptions(opts):
>   from SCons.Options.EnumOption import EnumOption
>   opts.Add(EnumOption('build', 'build type', 'debug',
>   allowed_values=('debug', 'checked', 'profile',
> -'release', 'opt')))
> +'release')))
>   opts.Add(BoolOption('verbose', 'verbose output', 'no'))
>   opts.Add(EnumOption('machine', 'use machine-specific assembly code',
>   default_machine,
> diff --git a/scons/gallium.py b/scons/gallium.py
> index aa7201a..963834a 100755
> --- a/scons/gallium.py
> +++ b/scons/gallium.py
> @@ -279,7 +279,7 @@ def generate(env):
>   if env['build'] == 'profile':
>   env['debug'] = False
>   env['profile'] = True
> -if env['build'] in ('release', 'opt'):
> +if env['build'] == 'release':
>   env['debug'] = False
>   env['profile'] = False
>   
> @@ -325,8 +325,6 @@ def generate(env):
>   cppdefines += ['NDEBUG']
>   if env['build'] == 'profile':
>   cppdefines += ['PROFILE']
> -if env['build'] in ('opt', 'profile'):
> -cppdefines += ['VMX86_STATS']
>   if env['platform'] in ('posix', 'linux', 'freebsd', 'darwin'):
>   cppdefines += [
>   '_POSIX_SOURCE',
> @@ -477,7 +475,7 @@ def generate(env):
>   ccflags += [
>   '/O2', # optimize for speed
>   ]
> -if env['build'] in ('release', 'opt'):
> +if env['build'] == 'release':
>   if not env['clang']:
>   ccflags += [
>   '/GL', # enable whole program optimization
> @@ -588,7 +586,7 @@ def generate(env):
>   shlinkflags += ['-Wl,--enable-stdcall-fixup']
>   #shlinkflags += ['-Wl,--kill-at']
>   if msvc:
> -if env['build'] in ('release', 'opt') and not env['clang']:
> +if env['build'] == 'release' and not env['clang']:
>   # enable Link-time Code Generation
>   linkflags += ['/LTCG']
>   env.Append(ARFLAGS = ['/LTCG'])
> diff --git a/src/gallium/drivers/svga/svga_screen.c 
> b/src/gallium/drivers/svga/svga_screen.c
> index ab9a3c7..95dde8b 100644
> --- a/src/gallium/drivers/svga/svga_screen.c
> +++ b/src/gallium/drivers/svga/svga_screen.c
> @@ -92,8 +92,6 @@ svga_get_name( struct pipe_screen *pscreen )
>   */
>  build = "build: DEBUG;";
>  mutex = "mutex: " PIPE_ATOMIC ";";
> -#elif defined(VMX86_STATS)
> -   build = "build: OPT;";
>   #else
>  build = "build: RELEASE;";
>   #endif
> 

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

Re: [Mesa-dev] Meson windows v5 (10/19/2018) review

[Jose Fonseca]

On 21/10/18 20:54, Liviu Prodea wrote:
1. When using Meson 0.48.x both -Dc_args -Dcpp_args and -Db_vscrt 
methods of selecting the CRT are ineffective on changing the CRT from MD 
to MT resulting in build failure if LLVM is built with MT CRT. This 
issue persists from last time I tested this WIP branch. However if MT 
built LLVM is indeed unsupported unlike Scons I am OK with it as long as 
it is documented.


2. Assuming no 1 has been worked around (we have LLVM built with MD CRT 
available), LLVM JIT-ed drivers like llvmpipe and swr cannot be selected 
despite resulted opengl32.dll being around 20MB and swr DLLs being built 
as well only when expected. Tested with GPU Caps Viewer (a 32-bit only 
software), it reports the driver as softpipe OpenGL 3.1 with 248 
extensions.  Since it's 32-bit app I did not attempt to build swr for 
this test as it's unsupported for 32-bit apps.  It appears this is a 
really persistent issue as I had it right from the first time I tested 
this branch. Maybe I need to change the recipe I use to build LLVM so 
that I use Meson instead of CMake. That would be really unpleasant if it 
turns out to be the root of this problem. I have this marked as optional 
and it is on least priority on my TODO list:


https://github.com/pal1000/mesa-dist-win/issues/7 
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpal1000%2Fmesa-dist-win%2Fissues%2F7=02%7C01%7Cjfonseca%40vmware.com%7C201e146521934e79895f08d63790411a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636757490087355401=KOompJzgdq2B9tawfDqGxxlXOLNqm0EbGRD9%2F9T%2FtHU%3D=0>


3. More filename parity with Scons similar to

https://gitlab.freedesktop.org/dbaker/mesa/commit/f31d0802da6a20b3878a789bb38c9733c4b0ff24#bda6b0f93966e610f473867639a87adfc5437011 
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdbaker%2Fmesa%2Fcommit%2Ff31d0802da6a20b3878a789bb38c9733c4b0ff24%23bda6b0f93966e610f473867639a87adfc5437011=02%7C01%7Cjfonseca%40vmware.com%7C201e146521934e79895f08d63790411a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636757490087355401=GbvqWeGNGKV1ylnh9X6ddXE2ExtxSSrX8i4nnpX9zyo%3D=0>


- swrAVX-0.dll should be swrAVX.dll

- swrAVX2-0.dll should be swrAVX2.dll

- libOsmesa.dll should be osmesa.dll

4. opengl32.dll built with Meson depends on shared library z.dll. I have 
absolutely no problem with this but Jose Fonseca may not like this 
considering one of his replies from the Scons gles option conversations.



Yep, we really don't want opengl32.dll (or any Mesa based OpenGL ICD) to 
depend on any DLL whatsoever besides Windows standard DLLs (this 
excludes even MSVC runtime, hence the need of /MT /MTd.)  This is 
because these drivers will be loaded onto arbitrary process are normally 
installed into C:\Windows\system32, hence any dependencies will need to 
be installed there, so depending on a z.dll could clash with z.dll 
shipped by applications



Regarding MT vs MTd, I've often considered just always use /MT and side 
step the runtime mismatch issue completely, because I honestly don't 
remember the debug C runtime ever helping debugging anything.  In fact, 
we often use cross compiled MinGW binaries for day-to-day development 
anyway.



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

Re: [Mesa-dev] [Mesa-stable][PATCH] Scons: Put to rest zombie texture_float build option

[Jose Fonseca]

I went ahead and committed this.  Thanks.

Jose

On 23/10/18 22:10, Liviu Prodea wrote:

I found a remnant of texture_float build option that wasn't removed in

https://gitlab.freedesktop.org/mesa/mesa/commit/66673bef941af344314fe9c91cad8cd330b245eb 



This patch removes it.

---

  common.py | 3 ---
  1 file changed, 3 deletions(-)


diff --git a/common.py b/common.py
index f4f2bb4..be3ccfc 100644
--- a/common.py
+++ b/common.py
@@ -105,9 +105,6 @@ def AddOptions(opts):
  opts.Add(BoolOption('debug', 'DEPRECATED: debug build', 'yes'))
  opts.Add(BoolOption('profile', 'DEPRECATED: profile build', 'no'))
  opts.Add(BoolOption('quiet', 'DEPRECATED: profile build', 'yes'))
-    opts.Add(BoolOption('texture_float',
-    'enable floating-point textures and renderbuffers',
-    'no'))
  opts.Add(BoolOption('swr', 'Build OpenSWR', 'no'))
  if host_platform == 'windows':
  opts.Add('MSVC_VERSION', 'Microsoft Visual C/C++ version')




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

Re: [Mesa-dev] [PATCH] scons: Remove gles option.

[Jose Fonseca]

> Jose, does it make more sense to just make gles on windows an error 
in meson?



I don't mind if there are options for other things, but the default for 
the unsuspicious user should be to create a single self-contained 
opengl32.dll, as that is what's generally most useful (it can be used 
with unmodified windows applications by putting on the same dir.)



Jose



*From:* Dylan Baker 
*Sent:* Friday, October 19, 2018 18:04
*To:* mesa-dev@lists.freedesktop.org; Brian Paul; Jose Fonseca; Liviu 
Prodea; Roland Scheidegger

*Subject:* Re: [Mesa-dev] [PATCH] scons: Remove gles option.
That's not quite right. GLES needs shared glapi, but shared glapi 
doesn't need
gles. meson and autoconf have separate toggles for shared-glapi and 
gles, they

both happen to default to "on" currently.

If you want to uses GLES with mesa on Windows your best bet is probably 
to use
ARB_ES_compatibility (replace  with 1, 2, 3, 3_1, or 3_2 as 
needed) from a

GL Core Context like you would using the Nvidia or Intel driver on windows.
Don't try to go down the EGL on windows madness that the proprietary AMD 
driver

requires.

Meson will likely continue to support shared glapi on windows because every
other platform that mesa supports needs shared-glapi. I have in my 
latest spin
default gles off on windows with meson. Jose, does it make more sense to 
just

make gles on windows an error in meson?

Dylan

Quoting Liviu Prodea (2018-10-19 08:04:28)
>
>
>
> I think I found autotools build equivalent for gles=y. It is 
--enable-shared-glapi. And the docs say it is needed to support 
applications that mix OpenGL and OpenGL ES:

>
> https://www.mesa3d.org/egl.html
>
> 
-

>
>
> On Friday, October 19, 2018, 4:15:48 PM GMT+3, Brian Paul 
 wrote:

>
>
>
>
>
> Reviewed-by: Brian Paul 
>
> On 10/19/2018 06:33 AM, Jose Fonseca wrote:
> > It's broken, and WGL state tracker is always built with GLES support
> > noawadays.
> > ---
> >  common.py | 2 --
> >  src/SConscript                              | 7 ---
> >  src/gallium/state_trackers/osmesa/SConscript | 4 +---
> >  src/gallium/state_trackers/wgl/SConscript | 4 +---
> >  src/gallium/targets/libgl-gdi/SConscript    | 6 --
> >  src/gallium/targets/libgl-xlib/SConscript | 6 --
> >  src/mapi/glapi/SConscript | 6 +-
> >  src/mapi/shared-glapi/SConscript            | 9 +
> >  src/mesa/SConscript | 4 +---
> >  src/mesa/drivers/osmesa/SConscript          | 4 +---
> >  10 files changed, 6 insertions(+), 46 deletions(-)
> >
> > diff --git a/common.py b/common.py
> > index 113fc7f5c12..f4f2bb44c1c 100644
> > --- a/common.py
> > +++ b/common.py
> > @@ -99,8 +99,6 @@ def AddOptions(opts):
> >                          'enable static code analysis where 
available', 'no'))

> >      opts.Add(BoolOption('asan', 'enable Address Sanitizer', 'no'))
> >      opts.Add('toolchain', 'compiler toolchain', default_toolchain)
> > -    opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES 
support',

> > -                        'no'))
> >      opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
> >      opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with 
openmp (swrast)',

> >                          'no'))
> > diff --git a/src/SConscript b/src/SConscript
> > index 95ea061c4bb..54350a9cdcc 100644
> > --- a/src/SConscript
> > +++ b/src/SConscript
> > @@ -42,10 +42,6 @@ env.Append(CPPPATH = ["#" + env['build_dir']])
> >  if env['platform'] != 'windows':
> >      SConscript('loader/SConscript')
> >
> > -# When env['gles'] is set, the targets defined in 
mapi/glapi/SConscript are not
> > -# used.  libgl-xlib and libgl-gdi adapt themselves to use the 
targets defined
> > -# in mapi/glapi-shared/SConscript. mesa/SConscript also adapts 
itself to

> > -# enable OpenGL ES support.
> >  SConscript('mapi/glapi/gen/SConscript')
> >  SConscript('mapi/glapi/SConscript')
> >
> > @@ -61,8 +57,5 @@ if not env['embedded']:
> >      if env['platform'] == 'haiku':
> >          SConscript('egl/SConscript')
> >
> > -    if env['gles']:
> > - SConscript('mapi/shared-glapi/SConscript')
> > -
> >  SConscript('gallium/SConscript')
> >
> > diff --git a/src/gallium/state_trackers/osmesa/SConscript 
b/src/gallium/state_trackers/osmesa/SConscript

> > index f5519f13762..be67d0fe739 100644
> > --- a/src/gallium/state_trackers/osmesa/SConscript
> > +++ b/src/gallium/state_trackers/osmesa/

Re: [Mesa-dev] [PATCH] scons: Remove gles option.

[Jose Fonseca]

SCons never had parity with autoconf.  It never gained enough traction 
to replace autoconf, so it become this thing which is mostly use by 
VMware and others who care about Windows.


Maybe one day meson will replace SCons.  But I certainly have no plans 
to have scons replace anything anymore.


Jose

On 19/10/18 16:28, Liviu Prodea wrote:








On Friday, October 19, 2018, 6:04:28 PM GMT+3, Liviu Prodea 
 wrote:








I think I found autotools build equivalent for gles=y. It is 
--enable-shared-glapi. And the docs say it is needed to support applications 
that mix OpenGL and OpenGL ES:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mesa3d.org%2Fegl.htmldata=02%7C01%7Cjfonseca%40vmware.com%7C94ebe6edaed045e7fbc008d635d77afe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636755596930665492sdata=tjgrqRqwIRY8wcfCaaV3v3lsP8kbnjlb%2B2WG%2FxfE3Sk%3Dreserved=0

and Meson equivalent is shared-glapi:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fblob%2Fmaster%2Fmeson_options.txtdata=02%7C01%7Cjfonseca%40vmware.com%7C94ebe6edaed045e7fbc008d635d77afe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636755596930665492sdata=pBeisAPjw5OWraF36VHD%2FHStVKFJDuznhc%2BoNKLQ8tg%3Dreserved=0

Apparently Scons is the only build system that has gles=no default. The other 2 
actively maintained build systems have both equivalent options default to true.
-


On Friday, October 19, 2018, 4:15:48 PM GMT+3, Brian Paul  
wrote:





Reviewed-by: Brian Paul 

On 10/19/2018 06:33 AM, Jose Fonseca wrote:

It's broken, and WGL state tracker is always built with GLES support
noawadays.
---
   common.py                                    | 2 --
   src/SConscript                              | 7 ---
   src/gallium/state_trackers/osmesa/SConscript | 4 +---
   src/gallium/state_trackers/wgl/SConscript    | 4 +---
   src/gallium/targets/libgl-gdi/SConscript    | 6 --
   src/gallium/targets/libgl-xlib/SConscript    | 6 --
   src/mapi/glapi/SConscript                    | 6 +-
   src/mapi/shared-glapi/SConscript            | 9 +
   src/mesa/SConscript                          | 4 +---
   src/mesa/drivers/osmesa/SConscript          | 4 +---
   10 files changed, 6 insertions(+), 46 deletions(-)

diff --git a/common.py b/common.py
index 113fc7f5c12..f4f2bb44c1c 100644
--- a/common.py
+++ b/common.py
@@ -99,8 +99,6 @@ def AddOptions(opts):
                           'enable static code analysis where available', 'no'))
       opts.Add(BoolOption('asan', 'enable Address Sanitizer', 'no'))
       opts.Add('toolchain', 'compiler toolchain', default_toolchain)
-    opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support',
-                        'no'))
       opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
       opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp 
(swrast)',
                           'no'))
diff --git a/src/SConscript b/src/SConscript
index 95ea061c4bb..54350a9cdcc 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -42,10 +42,6 @@ env.Append(CPPPATH = ["#" + env['build_dir']])
   if env['platform'] != 'windows':
       SConscript('loader/SConscript')
   
-# When env['gles'] is set, the targets defined in mapi/glapi/SConscript are not

-# used.  libgl-xlib and libgl-gdi adapt themselves to use the targets defined
-# in mapi/glapi-shared/SConscript.  mesa/SConscript also adapts itself to
-# enable OpenGL ES support.
   SConscript('mapi/glapi/gen/SConscript')
   SConscript('mapi/glapi/SConscript')
   
@@ -61,8 +57,5 @@ if not env['embedded']:

       if env['platform'] == 'haiku':
           SConscript('egl/SConscript')
   
-    if env['gles']:

-        SConscript('mapi/shared-glapi/SConscript')
-
   SConscript('gallium/SConscript')
   
diff --git a/src/gallium/state_trackers/osmesa/SConscript b/src/gallium/state_trackers/osmesa/SConscript

index f5519f13762..be67d0fe739 100644
--- a/src/gallium/state_trackers/osmesa/SConscript
+++ b/src/gallium/state_trackers/osmesa/SConscript
@@ -14,10 +14,8 @@ if env['platform'] == 'windows':
       env.AppendUnique(CPPDEFINES = [
           'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
           'WIN32_LEAN_AND_MEAN', # 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmsdn2.microsoft.com%2Fen-us%2Flibrary%2F6dwk3a1z.aspxdata=02%7C01%7Cjfonseca%40vmware.com%7C94ebe6edaed045e7fbc008d635d77afe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636755596930665492sdata=keOzo6Ret8LKwXsSFEWGZlrBf0I6UsfjTbMDh12ujaw%3Dreserved=0
+        '_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
__declspec(dllimport)
       ])
-    if not env['gles']:
-        # prevent _glapi_* from being declared __declspec(dllimport)
-        env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
   
  

[Mesa-dev] [PATCH] scons: Remove gles option.

[Jose Fonseca]

It's broken, and WGL state tracker is always built with GLES support
noawadays.
---
 common.py| 2 --
 src/SConscript   | 7 ---
 src/gallium/state_trackers/osmesa/SConscript | 4 +---
 src/gallium/state_trackers/wgl/SConscript| 4 +---
 src/gallium/targets/libgl-gdi/SConscript | 6 --
 src/gallium/targets/libgl-xlib/SConscript| 6 --
 src/mapi/glapi/SConscript| 6 +-
 src/mapi/shared-glapi/SConscript | 9 +
 src/mesa/SConscript  | 4 +---
 src/mesa/drivers/osmesa/SConscript   | 4 +---
 10 files changed, 6 insertions(+), 46 deletions(-)

diff --git a/common.py b/common.py
index 113fc7f5c12..f4f2bb44c1c 100644
--- a/common.py
+++ b/common.py
@@ -99,8 +99,6 @@ def AddOptions(opts):
 'enable static code analysis where available', 'no'))
 opts.Add(BoolOption('asan', 'enable Address Sanitizer', 'no'))
 opts.Add('toolchain', 'compiler toolchain', default_toolchain)
-opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support',
-'no'))
 opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
 opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp (swrast)',
 'no'))
diff --git a/src/SConscript b/src/SConscript
index 95ea061c4bb..54350a9cdcc 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -42,10 +42,6 @@ env.Append(CPPPATH = ["#" + env['build_dir']])
 if env['platform'] != 'windows':
 SConscript('loader/SConscript')
 
-# When env['gles'] is set, the targets defined in mapi/glapi/SConscript are not
-# used.  libgl-xlib and libgl-gdi adapt themselves to use the targets defined
-# in mapi/glapi-shared/SConscript.  mesa/SConscript also adapts itself to
-# enable OpenGL ES support.
 SConscript('mapi/glapi/gen/SConscript')
 SConscript('mapi/glapi/SConscript')
 
@@ -61,8 +57,5 @@ if not env['embedded']:
 if env['platform'] == 'haiku':
 SConscript('egl/SConscript')
 
-if env['gles']:
-SConscript('mapi/shared-glapi/SConscript')
-
 SConscript('gallium/SConscript')
 
diff --git a/src/gallium/state_trackers/osmesa/SConscript 
b/src/gallium/state_trackers/osmesa/SConscript
index f5519f13762..be67d0fe739 100644
--- a/src/gallium/state_trackers/osmesa/SConscript
+++ b/src/gallium/state_trackers/osmesa/SConscript
@@ -14,10 +14,8 @@ if env['platform'] == 'windows':
 env.AppendUnique(CPPDEFINES = [
 'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
 'WIN32_LEAN_AND_MEAN', # 
http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx
+'_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
__declspec(dllimport)
 ])
-if not env['gles']:
-# prevent _glapi_* from being declared __declspec(dllimport)
-env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
 
 st_osmesa = env.ConvenienceLibrary(
 target ='st_osmesa',
diff --git a/src/gallium/state_trackers/wgl/SConscript 
b/src/gallium/state_trackers/wgl/SConscript
index a7fbb07a89a..bbf5ebd9764 100644
--- a/src/gallium/state_trackers/wgl/SConscript
+++ b/src/gallium/state_trackers/wgl/SConscript
@@ -14,10 +14,8 @@ env.AppendUnique(CPPDEFINES = [
 '_GDI32_', # prevent wgl* being declared __declspec(dllimport)
 'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers
 'WIN32_LEAN_AND_MEAN', # 
http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx
+'_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared 
__declspec(dllimport)
 ])
-if not env['gles']:
-# prevent _glapi_* from being declared __declspec(dllimport)
-env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS'])
 
 wgl = env.ConvenienceLibrary(
 target ='wgl',
diff --git a/src/gallium/targets/libgl-gdi/SConscript 
b/src/gallium/targets/libgl-gdi/SConscript
index 132cb73358d..94feca24ef3 100644
--- a/src/gallium/targets/libgl-gdi/SConscript
+++ b/src/gallium/targets/libgl-gdi/SConscript
@@ -48,12 +48,6 @@ else:
 
 env['no_import_lib'] = 1
 
-# when GLES is enabled, gl* and _glapi_* belong to bridge_glapi and
-# shared_glapi respectively
-if env['gles']:
-env.Prepend(LIBPATH = [shared_glapi.dir])
-glapi = [bridge_glapi, 'libglapi']
-
 opengl32 = env.SharedLibrary(
 target ='opengl32',
 source = sources,
diff --git a/src/gallium/targets/libgl-xlib/SConscript 
b/src/gallium/targets/libgl-xlib/SConscript
index fb7a0ce50e3..b49b4e6fe2a 100644
--- a/src/gallium/targets/libgl-xlib/SConscript
+++ b/src/gallium/targets/libgl-xlib/SConscript
@@ -18,12 +18,6 @@ env.Append(CPPDEFINES = ['USE_XSHM'])
 env.Prepend(LIBS = env['X11_LIBS'])
 env.Prepend(LIBPATH = env['X11_LIBPATH'])
 
-# when GLES is enabled, gl* and _glapi_* belong to bridge_glapi and
-# shared_glapi respectively
-if env['gles']:
-env.Prepend(LIBPATH = [shared_glapi.dir])
-glapi = [bridge_glapi, 'glapi']
-
 env.Prepend(LIBS = [
 st_xlib,
 ws_xlib,
diff --git 

Re: [Mesa-dev] Scons/GLES: shared_glapi and osmesa link failure

[Jose Fonseca]

I still can't make much sense of that github issue thread.

Applications on Windows use opengl32.dll for acceleration, not 
libEGL/libGLESv1/libGLESv2 as these are not provided by the OS.  The 
only place you see these DLLs are things like GLES -> D3D11/GL 
translators like Angle.


So the "missing glapi.dll" is a red herring IMO: the solution is not to 
somehow the build the glapi.dll but rather build mesa so it's never 
needed.  Which is what scons does by default.


What Meson does or not by default I don't know.  It might provide all 
those DLLs, but that doesn't change the fact that windows applications 
will target opengl32.dll for accelleration.



Jose

On 18/10/18 15:46, Liviu Prodea wrote:
Well, all this started in that Github issue thread. That guy @elkhalafy 
was using llvmpipe to get Blender 2.80 to work on his system with 
unsupported (too old) iGPU. I don't know what he did but it resulted in 
Blender failing with missing libglapi.dll. So I researched about how to 
build it and it led me to this build variable gles of type boolean. When 
set to true it builds glapi as a shared library named libglapi.dll. It 
is also a requirement to build libGLESv1_CM.dll and libGLESv2.dll which 
only get build when selecting all build targets or probably I wasn't 
able to find the right target(s).


A Meson build approximation is -Dgles1=true -Dgles2=true which builds 
all 3 DLLs and it is default unlike in Scons case,


On Thursday, October 18, 2018, 3:08:11 PM GMT+3, Jose Fonseca 
 wrote:



I don't know what gles=y entails anymore, but if it's broken we should
simply remove it.

That said, our WGL GLES contexts, via WGL_EXT_create_context_es2_profile
extension, even without gles=y option.

So what exactly are you looking for here?

Jose

On 18/10/18 13:02, Liviu Prodea wrote:
 > scons build=release platform=windows machine=x86 gles=y libgl-gdi osmesa
 >
 > Creating library build\windows-x86\mesa\drivers\osmesa\osmesa.lib and
 > object build\windows-x86\mesa\drivers\osmesa\osmesa.exp
 > osmesa.obj : error LNK2001: unresolved external symbol
 > __imp___glapi_check_multithread
 > osmesa.obj : error LNK2001: unresolved external symbol
 > __imp___glapi_get_proc_address
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_set_context
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_set_dispatch
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_set_nop_handler
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_new_nop_table
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_Context
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_get_dispatch_table_size
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_get_context
 > mesa.lib(remap.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_add_dispatch
 > mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_get_dispatch
 > mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_Dispatch
 > build\windows-x86\mesa\drivers\osmesa\osmesa.dll : fatal error LNK1120:
 > 12 unresolved externals
 > scons: *** [build\windows-x86\mesa\drivers\osmesa\osmesa.dll] Error 1120
 > st_osmesa.lib(osmesa.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_get_proc_address
 > mesa.lib(st_manager.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_check_multithread
 > mesa.lib(vbo_exec_api.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_set_dispatch
 > mesa.lib(glthread.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_set_context
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_get_dispatch_table_size
 > mesa.lib(remap.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_add_dispatch
 > build\windows-x86\gallium\targets\osmesa\osmesa.dll : fatal error
 > LNK1120: 6 unresolved externals
 > scons: *** [build\windows-x86\gallium\targets\osmesa\osmesa.dll] 
Error 1120

 > scons: building terminated because of errors.
 >
 > This is a long standing issue. First reported here:
 >
 > 
https://lists.freedesktop.org/archives/mesa-users/2012-May/000431.html 
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fmesa-users%2F2012-May%2F000431.html=02%7C01%7Cjfonseca%40vmware.com%7Cf70f01ecc5524d6dbbcb08d635089556%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636754708317413432=J3QPOUwBYNd87u%2F5MZrYtT6BTz2Pdyyj6NKAsj%2BCkxw%3D=0%20>
 > 
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fmesa-u

Re: [Mesa-dev] Scons/GLES: shared_glapi and osmesa link failure

[Jose Fonseca]

I don't know what gles=y entails anymore, but if it's broken we should 
simply remove it.


That said, our WGL GLES contexts, via WGL_EXT_create_context_es2_profile 
extension, even without gles=y option.


So what exactly are you looking for here?

Jose

On 18/10/18 13:02, Liviu Prodea wrote:

scons build=release platform=windows machine=x86 gles=y libgl-gdi osmesa

Creating library build\windows-x86\mesa\drivers\osmesa\osmesa.lib and 
object build\windows-x86\mesa\drivers\osmesa\osmesa.exp
osmesa.obj : error LNK2001: unresolved external symbol 
__imp___glapi_check_multithread
osmesa.obj : error LNK2001: unresolved external symbol 
__imp___glapi_get_proc_address
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_context
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_dispatch
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_nop_handler
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_new_nop_table
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_Context
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_dispatch_table_size
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_context
mesa.lib(remap.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_add_dispatch
mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_dispatch
mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_Dispatch
build\windows-x86\mesa\drivers\osmesa\osmesa.dll : fatal error LNK1120: 
12 unresolved externals

scons: *** [build\windows-x86\mesa\drivers\osmesa\osmesa.dll] Error 1120
st_osmesa.lib(osmesa.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_proc_address
mesa.lib(st_manager.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_check_multithread
mesa.lib(vbo_exec_api.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_dispatch
mesa.lib(glthread.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_context
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_dispatch_table_size
mesa.lib(remap.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_add_dispatch
build\windows-x86\gallium\targets\osmesa\osmesa.dll : fatal error 
LNK1120: 6 unresolved externals

scons: *** [build\windows-x86\gallium\targets\osmesa\osmesa.dll] Error 1120
scons: building terminated because of errors.

This is a long standing issue. First reported here:

https://lists.freedesktop.org/archives/mesa-users/2012-May/000431.html 



Encountered again in 2016:

https://lists.freedesktop.org/archives/mesa-users/2016-March/001142.html 



and finally by myself in early 2018:

https://bugs.freedesktop.org/show_bug.cgi?id=106843 



Eric Engestrom suggested me to try the work in progress Meson build for 
Windows. Unfortunately it has other issues which prevents it from being 
ready for prime time as I reported here:


https://gitlab.freedesktop.org/dbaker/mesa/issues/2 



I stumbled upon this issue when dealing with this feature request:

https://github.com/pal1000/mesa-dist-win/issues/8 



I was able to get that feature done but with a terribly ugly hack which 
should not even be mentioned.


This issue affects the linking between 

[Mesa-dev] [PATCH 1/3] appveyor: Update to MSVC 2017.

[Jose Fonseca]

That's what we (and I suppose most people out there) are using now.
---
 appveyor.yml | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/appveyor.yml b/appveyor.yml
index 73be3c57df8..66f8354bd66 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -35,9 +35,9 @@ clone_depth: 100
 
 cache:
 - win_flex_bison-2.5.9.zip
-- llvm-5.0.1-msvc2015-mtd.7z
+- llvm-5.0.1-msvc2017-mtd.7z
 
-os: Visual Studio 2015
+os: Visual Studio 2017
 
 init:
 # Appveyor defaults core.autocrlf to input instead of the default (true), but
@@ -46,7 +46,7 @@ init:
 
 environment:
   WINFLEXBISON_ARCHIVE: win_flex_bison-2.5.9.zip
-  LLVM_ARCHIVE: llvm-5.0.1-msvc2015-mtd.7z
+  LLVM_ARCHIVE: llvm-5.0.1-msvc2017-mtd.7z
 
 install:
 # Check git config
@@ -61,7 +61,7 @@ install:
 # Install python wheels, necessary to install SCons via pip
 - python -m pip install wheel
 # Install SCons
-- python -m pip install scons==2.5.1
+- python -m pip install scons==3.0.1
 - scons --version
 # Install flex/bison
 - if not exist "%WINFLEXBISON_ARCHIVE%" appveyor DownloadFile 
"https://downloads.sourceforge.net/project/winflexbison/old_versions/%WINFLEXBISON_ARCHIVE%;
@@ -76,10 +76,10 @@ install:
 - set LLVM=%CD%\llvm
 
 build_script:
-- scons -j%NUMBER_OF_PROCESSORS% MSVC_VERSION=14.0 llvm=1
+- scons -j%NUMBER_OF_PROCESSORS% MSVC_VERSION=14.1 llvm=1
 
 after_build:
-- scons -j%NUMBER_OF_PROCESSORS% MSVC_VERSION=14.0 llvm=1 check
+- scons -j%NUMBER_OF_PROCESSORS% MSVC_VERSION=14.1 llvm=1 check
 
 
 # It's possible to setup notification here, as described in
-- 
2.17.1

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

[Mesa-dev] [PATCH 3/3] appveyor: Cache pip's cache files.

[Jose Fonseca]

It should speed up the Python packages installation.
---
 appveyor.yml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/appveyor.yml b/appveyor.yml
index a4e942c14ca..ccb84fd3403 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -33,7 +33,9 @@ branches:
 # - https://www.appveyor.com/blog/2014/06/04/shallow-clone-for-git-repositories
 clone_depth: 100
 
+# https://www.appveyor.com/docs/build-cache/
 cache:
+- '%LOCALAPPDATA%\pip\Cache -> appveyor.yml'
 - win_flex_bison-2.5.15.zip
 - llvm-5.0.1-msvc2017-mtd.7z
 
-- 
2.17.1

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

[Mesa-dev] [PATCH 2/3] appveyor: Update to newer Mako/winflexbison versions.

[Jose Fonseca]

As that's what most people are bound to use.
---
 appveyor.yml | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/appveyor.yml b/appveyor.yml
index 66f8354bd66..a4e942c14ca 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -34,7 +34,7 @@ branches:
 clone_depth: 100
 
 cache:
-- win_flex_bison-2.5.9.zip
+- win_flex_bison-2.5.15.zip
 - llvm-5.0.1-msvc2017-mtd.7z
 
 os: Visual Studio 2017
@@ -45,7 +45,7 @@ init:
 - git config --global core.autocrlf true
 
 environment:
-  WINFLEXBISON_ARCHIVE: win_flex_bison-2.5.9.zip
+  WINFLEXBISON_VERSION: 2.5.15
   LLVM_ARCHIVE: llvm-5.0.1-msvc2017-mtd.7z
 
 install:
@@ -55,7 +55,7 @@ install:
 - python --version
 - python -m pip --version
 # Install Mako
-- python -m pip install Mako==1.0.6
+- python -m pip install Mako==1.0.7
 # Install pywin32 extensions, needed by SCons
 - python -m pip install pypiwin32
 # Install python wheels, necessary to install SCons via pip
@@ -64,7 +64,8 @@ install:
 - python -m pip install scons==3.0.1
 - scons --version
 # Install flex/bison
-- if not exist "%WINFLEXBISON_ARCHIVE%" appveyor DownloadFile 
"https://downloads.sourceforge.net/project/winflexbison/old_versions/%WINFLEXBISON_ARCHIVE%;
+- set WINFLEXBISON_ARCHIVE=win_flex_bison-%WINFLEXBISON_VERSION%.zip
+- if not exist "%WINFLEXBISON_ARCHIVE%" appveyor DownloadFile 
"https://github.com/lexxmark/winflexbison/releases/download/v%WINFLEXBISON_VERSION%/%WINFLEXBISON_ARCHIVE%;
 - 7z x -y -owinflexbison\ "%WINFLEXBISON_ARCHIVE%" > nul
 - set Path=%CD%\winflexbison;%Path%
 - win_flex --version
-- 
2.17.1

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

Re: [Mesa-dev] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions

[Jose Fonseca]

On 24/09/18 01:55, Marek Olšák wrote:

On Fri, Sep 21, 2018 at 11:34 AM, Emil Velikov  wrote:

On 21 September 2018 at 00:42, Timothy Arceri  wrote:

On 20/9/18 11:09 pm, Ian Romanick wrote:


On 09/19/2018 11:36 PM, Federico Dossena wrote:


As most of you are probably aware of, id2 and id3 games store GL
extensions in a buffer that's too small for modern systems. This usually
leads to a crash when MESA_EXTENSION_MAX_YEAR is not set, but what the
creator of this commit didn't know is that some id3 games (the more
"recent" ones) don't crash, they just truncate the string. As a result
of this commit, these games can't detect some extensions and therefore
don't work properly.



It sounds like the problem is still that MESA_EXTENSION_MAX_YEAR is not
set, so why not just set it?  Doesn't that fix the problem?



There is no driconfig option for this currently. Personally I'd rather just
sort the extensions (even if it was only for 32bit builds of Mesa) rather
than adding a bunch of code and extra entry's into driconfig.

Or are you saying you would prefer we do nothing and people should use
MESA_EXTENSION_MAX_YEAR be required to use?


As mentioned in my other reply there seems to be two type of problems
when dealing with some idtech games:
  - blind copy - leading to crashes
  - copy + truncation - leading to "missing" extensions


Since the change causes incorrect rendering and it's impossible to
associate that with the need to set MESA_EXTENSION_MAX_YEAR, the env
var doesn't help. You need to be a professional driver developer in
order to guess that the env var should be set. I certainly wouldn't
guess that. I didn't even know that the extension list is not sorted
by year anymore.

The driconfig approach is fragile. You can't identify the list of
affected apps because you don't have or test all apps and they may
just show incorrect rendering, which is inconclusive. Building a list
of affected apps for driconfig is a huge effort that nobody will
realistically do. I prefer minimizing the number of workarounds in
driconfig as much as possible.

Marek


I agree FWIW.

The sorting by year is a bit of a nuisance, but unfortunately the 
problem won't disappear by wishing it away.


IMHO, only sorting on some apps is just adding complexity to the workaround.

Restricting to 32bit makes sense though, as it makes a clear transition 
path, since I suppose no 64 bit app is affected, and I suppose one day 
(far in the future perhaps, on specially on Windows) 32 bit will go out 
of use.


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

Re: [Mesa-dev] [PATCH 1/2] util: try to fix the Android build

[Jose Fonseca]

On 09/09/18 02:02, Marek Olšák wrote:

From: Marek Olšák 

---
  src/util/u_thread.h | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/util/u_thread.h b/src/util/u_thread.h
index ec0d9a7..0c20ebb 100644
--- a/src/util/u_thread.h
+++ b/src/util/u_thread.h
@@ -29,20 +29,23 @@
  
  #include 

  #include 
  
  #include "c11/threads.h"
  
  #ifdef HAVE_PTHREAD

  #include 
  #endif
  
+#if defined(HAVE_PTHREAD) && !defined(ANDROID)


If you add `&& !defined(__APPLE__)` then you'll also fix macOS builds, 
(ie https://bugs.freedesktop.org/show_bug.cgi?id=107869 )


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

Re: [Mesa-dev] [PATCH 2/2] gallium: try to fix the Windows build

[Jose Fonseca]

Sorry Marek, I just pushed an identical patch as I had missed this one.

Jose

On 09/09/18 02:02, Marek Olšák wrote:

From: Marek Olšák 

Windows doesn't have thrd_current.
---
  src/gallium/auxiliary/util/u_helpers.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_helpers.c 
b/src/gallium/auxiliary/util/u_helpers.c
index f773360..8095242 100644
--- a/src/gallium/auxiliary/util/u_helpers.c
+++ b/src/gallium/auxiliary/util/u_helpers.c
@@ -127,20 +127,21 @@ util_upload_index_buffer(struct pipe_context *pipe,
   * The function pins the current thread and driver threads to a group of
   * CPU cores that share the same L3 cache. This is needed for good multi-
   * threading performance on AMD Zen CPUs.
   *
   * \param upper_thread  thread in the state tracker that also needs to be
   *  pinned.
   */
  void
  util_context_thread_changed(struct pipe_context *ctx, thrd_t *upper_thread)
  {
+#ifdef HAVE_PTHREAD
 thrd_t current = thrd_current();
 int cache = util_get_L3_for_pinned_thread(current,
   util_cpu_caps.cores_per_L3);
  
 /* If the main thread is not pinned, choose the L3 cache. */

 if (cache == -1) {
unsigned num_caches = util_cpu_caps.nr_cpus /
  util_cpu_caps.cores_per_L3;
static unsigned last_cache;
  
@@ -151,20 +152,21 @@ util_context_thread_changed(struct pipe_context *ctx, thrd_t *upper_thread)
  
 /* Tell the driver to pin its threads to the same L3 cache. */

 if (ctx->set_context_param) {
ctx->set_context_param(ctx, PIPE_CONTEXT_PARAM_PIN_THREADS_TO_L3_CACHE,
   cache);
 }
  
 /* Do the same for the upper level thread if there is any (e.g. glthread) */

 if (upper_thread)
util_pin_thread_to_L3(*upper_thread, cache, util_cpu_caps.cores_per_L3);
+#endif
  }
  
  /* This is a helper for hardware bring-up. Don't remove. */

  struct pipe_query *
  util_begin_pipestat_query(struct pipe_context *ctx)
  {
 struct pipe_query *q =
ctx->create_query(ctx, PIPE_QUERY_PIPELINE_STATISTICS, 0);
 if (!q)
return NULL;



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