Re: Lavapipe license

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

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

; 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 per

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

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

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

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

Re: Increase memory size of Lavapipe device?

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:

Re: Mesa3D crash reporting

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

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

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

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

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

Re: Enable OpenGL software rendering on macOS

ing, 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

Re: Enable OpenGL software rendering on macOS

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

Re: revenge of CALLOC_STRUCT

-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

Re: [Mesa-dev] Merge blocked

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

Re: [Mesa-dev] Merge blocked

, 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.freedesk

[Mesa-dev] Merge blocked

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

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

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

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

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

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

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 l

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

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

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

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

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

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

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

ose 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 &g

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

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/f

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

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:

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

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:

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

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

[Mesa-dev] RFC: Memory allocation on Mesa

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

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

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

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

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

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

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

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

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

Re: [Mesa-dev] 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

[Mesa-dev] 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

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

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 person

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

l 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, F

Re: [Mesa-dev] size of LP_MAX_VBUF_SIZE

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

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

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

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

- 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

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

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

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

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

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

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

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

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

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

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 in

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

h 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

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

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.safe

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [Mesa-dev] dEQP + llvmpipe

> 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

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

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

Re: [Mesa-dev] boolean usage in gallium

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: > >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ne

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

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

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

ew'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

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

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 *s

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

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 wron

Re: [Mesa-dev] dumb meson questions

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.

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

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

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

k = 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] [PATCH] scons: Workaround failures with MSVC when using SCons 3.0.[2-4].

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:

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

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

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

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

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

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

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

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

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

t;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

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)

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

data_ptr1, mipoff1, s, t, r, offsets, -); -} +lp_build_sample_image_linear(bld, + size1, + row_stride1_vec, im

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

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

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

egment */ +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

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

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

> 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: Wednes

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

stant 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 n

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

reg->Register.File, reg->Register.Index, - >Indirect); + >Indirect, + bld->bld_base.info->file_max[reg->Registe

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

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

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

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

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

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. > --- >

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

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

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

0%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 t

Re: [Mesa-dev] [Mesa-stable][PATCH] Scons: Put to rest zombie texture_float build option

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

Re: [Mesa-dev] [PATCH] scons: Remove gles option.

sed 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; Rol

Re: [Mesa-dev] [PATCH] scons: Remove gles option.

. - 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

[Mesa-dev] [PATCH] scons: Remove gles option.

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|

Re: [Mesa-dev] Scons/GLES: shared_glapi and osmesa link failure

GLESv1_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 P

Re: [Mesa-dev] Scons/GLES: shared_glapi and osmesa link failure

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:

[Mesa-dev] [PATCH 1/3] appveyor: Update to MSVC 2017.

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 @@

[Mesa-dev] [PATCH 3/3] appveyor: Cache pip's cache files.

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: # -

[Mesa-dev] [PATCH 2/3] appveyor: Update to newer Mako/winflexbison versions.

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

Re: [Mesa-dev] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions

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

Re: [Mesa-dev] [PATCH 1/2] util: try to fix the Android build

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

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

  1   2   3   4   5   6   7   8   9   10   >