Re: Degugging with gdb

I don't know anything about using Mesa as a meson subproject, but the way I usually test a local Mesa build is: https://docs.mesa3d.org/install.html#running-against-a-local-build-easy-way For example if I wanted to run gdb on glxgears I might say: $ meson devenv -C build gdb -q glxgears You

Re: Queries regarding the Khronos specification license

For what it's worth, I did raise this as a potential issue with the apache2 license migration for Khronos projects, and explicitly asked about MIT dual-licensing at least for the GL headers. (The morbidly curious with a Khronos membership may find the relevant discussion in the arb-nextgen

Re: GBM as standalone buffer allocator

On Mon, Oct 23, 2023 at 6:39 AM Srinivas Pullakavi (QUIC) < quic_spull...@quicinc.com> wrote: > Hi, > > > > We are planning to enhance GBM as a standalone buffer allocator, which can > be used for all multi-media clients. Ex: video, camera, display etc; > > > > GBM create device expects a file

Re: Venus crashes guest if vkCreateInstance is called on MoltenVK

Nothing userspace can do should be able to crash the hypervisor. If it can, that's a qemu bug. - ajax On Fri, May 26, 2023 at 9:22 PM DUO Labs wrote: > I'm working on integrating virglrenderer with MoltenVK on MacOS. However, > I found that when vkCreateInstance is called, even though the

Re: Performance issues with Lavapipe in Windows (?)

My first suspicion would be to rule out window system interaction. If you render to your own VkImage instead of to a swapchain, how fast can you go? - ajax On Tue, Apr 4, 2023 at 12:56 PM George Karpathios wrote: > Hi list, I hope all is well. > > I would like to ask if there are any known

Re: Headless OpenGL Rendering using SSH and X11 forwarding

12290 is indeed EGL_BAD_ACCESS, and it's pretty much impossible for Mesa's eglInitialize to return that, so (if I had to guess) you have nvidia's driver installed as well, and (extra guessing now) nvidia's EGL only works with connections to the local machine and not over the network. Mesa

Re: [EXTERNAL] Re: Zink MR signoff tags

Same for the X11 backends (xlib, glx, egl/x11, wsi/x11). On Tue, Oct 18, 2022 at 6:14 PM Karol Herbst wrote: > and for Nouveau while I am at it. > > Unless somebody screams and still wants them. > > On Wed, Oct 19, 2022 at 12:12 AM Karol Herbst wrote: > > > > Same for Rusticl > > > > On Mon,

Re: Question about eglCreatePbufferSurface with empty attrib_list

AFAIK this was the pre-framebuffer-object / OES_surfaceless_context way of making a context current without (really) having a bound surface. That said I don't think Mesa actually implements that feature correctly, atm I think you'll get a BadValue from the xcb_create_pixmap call, but patches to

Re: Amber branch plan

At the moment 21.3.8 is the last planned Mesa 21.3.Z. So I kind of imagine 21.3.9 being the first "amber-only" release where we flip the meson option for amber to true by default, and we'd keep that branch going for as long as people want to keep it compiling and fixing bugs in it. - ajax On

Re: Amber branch plan

This is my plan as well. I'm aiming to get amber packaged for Fedora before February so I'll want to see !10557 merged pretty soon. - ajax On Mon, Dec 6, 2021 at 7:36 PM Jason Ekstrand wrote: > > +1 > > On Mon, Dec 6, 2021 at 5:51 PM Dylan Baker wrote: >> >> Since classic is gone, I thought

Re: [Mesa-dev] Request for developer access for Tony Wasserka

Done, welcome aboard. - ajax On Fri, Nov 20, 2020 at 4:49 AM Samuel Pitoiset wrote: > > +1 > > On 11/20/20 10:44 AM, Daniel Schürmann wrote: > > Hi, > > > > I would like to request developer access for our new team member, Tony > > Wasserka. > > > > He has proven himself capable with a number

[Mesa-dev] Intent to retire ancient driver support

Sending this on to the list for visibility, since not everyone follows everything on gitlab. In this merge request: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7660 I retire support for DRI drivers older than Mesa 8.0, which was February 2012. In particular this retires the ability

[Mesa-dev] Heads up: new GLX/WSI presentation features in git

I've landed a couple of changes to the GLX and X11 WSI code that enable GLX_EXT_swap_control_tear and VK_PRESENT_MODE_FIFO_RELAXED_KHR, respectively. These enable the app to request that "late" swaps (that missed the requested MSC or UST) post immediately instead of waiting for the next vblank,

Re: [Mesa-dev] swrast gallium provider doesn't work on Solaris SPARC (Mesa 20 with LLVM 10)

On Wed, 2020-05-13 at 18:27 +0200, Petr Sumbera wrote: > Hi, > > I have difficulties with Mesa update from version Mesa 18 (LLVM 6) where > it used to work. > > Now with Mesa 20 and LLVM 10 glxgears doesn't show wheels but just some > random rectangles. Please see attached picture. > > Any

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote: > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > > pre-merge CI. > > > > Thanks for the suggestion! I

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

On Sun, 2020-03-29 at 09:45 -0700, Kristian Høgsberg wrote: > As for loading, doesn't glvnd solve that? It could. It does not. Right now there's not a (good) way for the DDX driver to communicate a preferred implementation name to the GLX client. xserver's glx just knows it needs an

Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem

On Tue, 2020-03-17 at 10:12 -0700, Jacob Lifshay wrote: > One related issue with explicit sync using sync_file is that combined > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the > rendering in userspace (like llvmpipe but for Vulkan and with extra > instructions for GPU tasks) but

Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem

On Wed, 2020-03-11 at 12:31 -0500, Jason Ekstrand wrote: > - X11: With present, it has these "explicit" fence objects but > they're always a shmfence which lets the X server and client do a > userspace CPU-side hand-off without going over the socket (and > round-tripping through the kernel).

Re: [Mesa-dev] libdrm can't be released because of meson

On Wed, 2019-10-16 at 15:36 -0400, Marek Olšák wrote: > Hi, > > Since autotools is no longer in libdrm, it's not possible to make a release: Apparently meson support in release.sh has been languishing unmerged for a while: https://gitlab.freedesktop.org/xorg/util/modular/merge_requests/8 This

Re: [Mesa-dev] gitlab issue migration, labels & triage

On Mon, 2019-09-23 at 11:50 +0300, Denys wrote: > Hello Adam. > I would ask to get a permissions to edit/triage the issues, as we did before > in bugzilla. We have a small team working on mesa project (right now intel > part mostly), so it would be great to have possibility to sort user issues

Re: [Mesa-dev] [PATCH] egl/gbm: Fix config validation

rms. Restore the equivalent check that *both* configs actually > have an alpha channel before considering a mismatch. > > Fixes: 7b4ed2b513ef ("egl: Convert configs to use shifts and sizes instead of > masks") > Signed-off-by: Robin Murphy Makes sense to me

Re: [Mesa-dev] gitlab issue migration, labels & triage

On Wed, 2019-09-18 at 23:41 +0200, Bas Nieuwenhuizen wrote: > Has anybody put any though in how to best manage things here? e.g. > some process, or do we want some form of automatic labeling, or is my > concern overblown? Well, there's the list of issues with no label:

Re: [Mesa-dev] Release workflow with gitlab issues

On Wed, 2019-09-18 at 12:08 -0700, Mark Janes wrote: > Adding the release managers to the CC to make sure they see the thread... > > Dylan Baker writes: > > > Hi everyone, > > > > Since we're migrating to gitlab issues, it seems like a good time to review > > how > > we track stable releases,

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

On Thu, 2019-08-29 at 11:52 -0700, Kenneth Graunke wrote: > What do people think? If folks are in favor, Daniel can migrate > everything for us, like he did with the other projects. If not, > I'd like to hear what people's concerns are. It's been almost three weeks, and this seems to have

Re: [Mesa-dev] [PATCH] demos: eglinfo: Add support for surfaceless EGL platform

On Sun, 2019-09-15 at 17:53 +0300, Matwey V. Kornilov wrote: > Signed-off-by: Matwey V. Kornilov Thanks! I had an equivalent hack in my local copy and hadn't pushed it, tsk tsk. I've opened a merge request for yours here: https://gitlab.freedesktop.org/mesa/demos/merge_requests/4 Will merge in

Re: [Mesa-dev] Moving libglvnd to FreeDesktop Gitlab

On Wed, 2019-09-04 at 14:27 -0600, Kyle Brenneman wrote: > On 9/4/19 8:44 AM, Daniel Stone wrote: > > Hi, > > > > On Wed, 4 Sep 2019 at 15:12, Chuck Atkins wrote: > > > Can we use Gitlab's GitHub import feature? > > > > > > https://gitlab.freedesktop.org/help/user/project/import/github.md > > >

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

On Fri, 2019-08-30 at 14:26 +0100, Chris Wilson wrote: > Quoting Daniel Stone (2019-08-30 14:13:08) > > Hi, > > > > On Thu, 29 Aug 2019 at 21:35, Chris Wilson wrote: > > > > > > I think so. I just want a list of all bugs that may affect the code I'm > > > working on, wherever they were filed. I

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

On Tue, 2019-08-27 at 10:57 +, Jose Fonseca wrote: > I don't know how Meson didn't hit this issue, when it too already uses > -Werror=incompatible-pointer-types Yeah, weird. Reviewed-by: Adam Jackson - ajax ___ mesa-dev mailing list me

Re: [Mesa-dev] mirroring ogl-sample source code in gitlab?

On Wed, 2019-06-12 at 10:29 +0200, Erik Faye-Lund wrote: > On Wed, 2019-06-12 at 10:25 +0200, Erik Faye-Lund wrote: > > On Tue, 2019-06-11 at 12:41 -0400, Adam Jackson wrote: > > > On Tue, 2019-06-11 at 11:13 +0200, Erik Faye-Lund wrote: > > > > > > > So he

Re: [Mesa-dev] mirroring ogl-sample source code in gitlab?

On Tue, 2019-06-11 at 11:13 +0200, Erik Faye-Lund wrote: > So here's the question: How does people feel about hosting this under > https://gitlab.freedesktop.org/mesa/ogl-sample/? If people are OK with > this, I will make that happen, and send out a patch to update the link > we have in our FAQ

Re: [Mesa-dev] GLU and GLUT issues migrated to gitlab

On Mon, 2019-05-13 at 12:14 -0400, Adam Jackson wrote: > Not, I hope, that anyone is likely to notice, but I've moved the open > GLU and GLUT bugs from bugzilla to gitlab and closed the components in > bugzilla. I say "moved" but really glut only had one open bug and it &

[Mesa-dev] GLU and GLUT issues migrated to gitlab

Not, I hope, that anyone is likely to notice, but I've moved the open GLU and GLUT bugs from bugzilla to gitlab and closed the components in bugzilla. I say "moved" but really glut only had one open bug and it was fixed ages ago. Anyway, use gitlab now please. - ajax

Re: [Mesa-dev] [PATCH] Revert "glx: Fix synthetic error generation in __glXSendError"

On Tue, 2019-05-07 at 20:17 +1000, Timothy Arceri wrote: > I don't know enough about this code to take responsibility for such > changes. I was just trying to revert to the status quo until this could > be investigated again. > > My suggestion is we roll back the recent change. Then someone

Re: [Mesa-dev] [PATCH 2/3] mesa: fix pbuffers because internally they are front buffers

On Mon, 2019-04-29 at 20:35 -0400, Marek Olšák wrote: > Yeah that's possible. The thing is that a GL context can have a > doublebuffered config and begin with GL_BACK as the draw buffer, but > MakeCurrent can set a pbuffer with a singlebuffered config and then > nothing is rendered with Mesa

Re: [Mesa-dev] [PATCH 2/3] mesa: fix pbuffers because internally they are front buffers

On Fri, 2019-04-26 at 23:31 -0400, Marek Olšák wrote: I don't claim to know what this series is trying to fix, but: > +* 2) Pbuffers are back buffers from the application point of view, > +*but they are front buffers from the Mesa point of view, > +*because they are always

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

On Tue, 2019-04-23 at 19:21 -0400, Marek Olšák wrote: > Then I think a separate EGL extension that exposes swrast would be > better. The thing with the device extensions is that swrast is not a > device. Enh. I've got dumb GPUs I need to support, they need to run OpenGL, and if they were running

[Mesa-dev] [PATCH] egl: Fix EGL_PLATFORM_X11_SCREEN_KHR handling

If this was specified and a non-NULL display was passed to eglGetPlatformDisplay, we would ignore the attribute and instead use whatever xcb thought the default screen would be. To fix this, store a copy of the attribute list in the _EGLDisplay, and use that to look up any non-default screen

Re: [Mesa-dev] Mesa compatibility range

On Wed, 2019-04-10 at 15:37 +, Jonathan Jackson wrote: > 1. My question is: Is it reasonable to think that llvmpipe (or other > drivers) will grand me a much wider > array of supported system if I use that implementation over the original > Windows one? I'm reasonably sure that

Re: [Mesa-dev] [PATCH 1/2] egl: add optional plat_opt to _eglFindDisplay()

On Thu, 2019-04-04 at 16:25 +0100, Emil Velikov wrote: > I'm not a huge fan of this. Yet again the other platform (x11) that uses > these has a number of issues, see below for details. Once those are resolved > we could try and make this more uniform. > > a) spec does not mention if a new (or

Re: [Mesa-dev] Should piglit drop bugzilla and move to using gitlab issues?

On Fri, 2019-03-01 at 17:35 -0800, Kenneth Graunke wrote: > On Friday, March 1, 2019 1:30:48 PM PST Dylan Baker wrote: > > Quoting Jordan Justen (2019-03-01 12:22:18) > > > I guess piglit makes very light usage of bugzilla. Would it be simpler > > > to just use gitlab issues in the piglit gitlab

Re: [Mesa-dev] RFC - libglvnd and GLXVND vendor enumeration to facilitate GLX multi-vendor PRIME GPU offload

On Fri, 2019-02-08 at 10:19 -0800, Andy Ritger wrote: > (1) If configured for PRIME GPU offloading (environment variable or > application profile), client-side libglvnd could load the possible > libGLX_${vendor}.so libraries it finds, and call into each to > find which vendor (and

Re: [Mesa-dev] 10-bit fbconfigs break most video players using VAAPI+GLX

On Wed, 2019-02-06 at 10:33 -0500, Adam Jackson wrote: > On Tue, 2019-02-05 at 17:30 -0500, Marek Olšák wrote: > > > If we expose 10-bit or 16-bit formats, a lot of software will be > > broken. Any ideas how to get out of this rabbit hole? > > Use GLX_SGIX_visual_select

Re: [Mesa-dev] 10-bit fbconfigs break most video players using VAAPI+GLX

On Tue, 2019-02-05 at 17:30 -0500, Marek Olšák wrote: > If we expose 10-bit or 16-bit formats, a lot of software will be > broken. Any ideas how to get out of this rabbit hole? Use GLX_SGIX_visual_select_group to hide the depth-30 formats after the depth-24 ones. We're already doing this for

Re: [Mesa-dev] [PATCH 04/13] egl: Convert configs to use shifts instead of masks

On Mon, 2019-01-28 at 10:42 -0800, Kevin Strasser wrote: > @@ -237,19 +268,35 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig > *dri_config, int id, > break; > >case __DRI_ATTRIB_RED_MASK: > - dri_masks[0] = value; > + dri_shifts[0] = ffs(value) - 1; >

Re: [Mesa-dev] [PATCH 00/13] Enable fp16 visuals and fbconfigs

ers) to support EXT_gl_colorspace_scrgb / > EXT_gl_colorspace_scrgb_linear, used in places like Android wide color > gamut. This looks great! Comments on 4/ and 11/ are minor, and haven't built my way through testing this yet, but: Reviewed-by: Adam Jackson - ajax ___

Re: [Mesa-dev] [PATCH 11/13] gallium: Add buffer and configs handling or fp16 formats

On Mon, 2019-01-28 at 10:42 -0800, Kevin Strasser wrote: > Expose configs when allow_fp16_configs has been enabled and > DRI_LOADER_CAP_FP16 is set in the loader. > > Also, make kms_swrast_dri respect format bpp, to allow for allocating > buffers wider than 32 bpp. Was this the only offender? -

Re: [Mesa-dev] Fwd: Review for last remaining Mesa wayland-drm depth 30 bits?

On Tue, 2019-01-29 at 17:51 +0100, Mario Kleiner wrote: > Thanks for the quick review! > > Patchwork didn't pick the r-b's up though. Do i need to do anything / > ping somebody to get those merged to master ideally before the close > 19.0 branchpoint and not overlooked? I've created a merge

Re: [Mesa-dev] Fwd: Review for last remaining Mesa wayland-drm depth 30 bits?

ion: > > https://patchwork.freedesktop.org/project/mesa/list/?submitter=14956 > > Would be good to get this into Mesa 19 before new color formats are > added. Should be useful for new formats as well. 4 and 5 are: Reviewed-by: Adam Jackson - ajax ___

Re: [Mesa-dev] [PATCH] meson: add toggle for TLS support in GLX

On Sat, 2019-01-26 at 13:56 +0100, Patrick Steinhardt wrote: > Unfortunately, I'm not aware of any easy way to do this. The > problem is not due to the compiler, as the program compiles and > links just fine with musl libc. Instead, this is a runtime issue > that happens when dlopen'ing shared

Re: [Mesa-dev] [RFC 1/6] dri: Support 64 bit rgba masks

On Wed, 2019-01-16 at 17:58 +, Strasser, Kevin wrote: > Adam Jackson wrote: > > > Probably what I'd do is only define those masks to non-zero for <=32bpp > > formats, > > Not sure if I understood this statement. Do you mean if we keep the _HI and > _LO >

Re: [Mesa-dev] [RFC 1/6] dri: Support 64 bit rgba masks

On Wed, 2019-01-16 at 04:41 +, Strasser, Kevin wrote: > Emil Velikov wrote: > > > > Please split this up a bit. I'm thinking of: > > - dri_interface > > - mesa > > - egl > > - gbm > > - glx - seems sparse on updates, guessting you're followed in laster > > patches? > > Sure, I can

Re: [Mesa-dev] [RFC 1/6] dri: Support 64 bit rgba masks

On Fri, 2019-01-11 at 15:01 +, Emil Velikov wrote: > > @@ -460,6 +464,14 @@ driGetConfigAttribIndex(const __DRIconfig *config, > > else > > *value = 0; > > break; > > +case __DRI_ATTRIB_RED_MASK_HI: > > +case __DRI_ATTRIB_GREEN_MASK_HI: > > +case

[Mesa-dev] [PATCH 3/3] specs: Bump GLX_MESA_query_renderer to version 9

Note that we have an official GL extension number, pick the appropriate section of the GLX spec to modify, and add changelog. Signed-off-by: Adam Jackson --- docs/specs/MESA_query_renderer.spec | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/docs/specs

[Mesa-dev] [PATCH 1/3] specs: Remove GLES profile interaction text from GLX_MESA_query_renderer

-by: Adam Jackson --- docs/specs/MESA_query_renderer.spec | 12 1 file changed, 12 deletions(-) diff --git a/docs/specs/MESA_query_renderer.spec b/docs/specs/MESA_query_renderer.spec index dd45e02ba50..3b4a445cf88 100644 --- a/docs/specs/MESA_query_renderer.spec +++ b/docs/specs

[Mesa-dev] [PATCH 0/3] Update GLX_MESA_query_renderer spec

No functional change, just making the text match the implementation. Will sync this to the Khronos registry once merged. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] specs: Remove GLX_RENDERER_ID_MESA from GLX_MESA_query_renderer

, 0, ); to return the number of renderers, but a new entrypoint might be cleaner. Still, better to not specify it at all than to lie about it. Signed-off-by: Adam Jackson --- docs/specs/MESA_query_renderer.spec | 19 --- 1 file changed, 19 deletions(-) diff --git a/docs/specs

Re: [Mesa-dev] [PATCH EGL/MESA] EGL/mesa: Initial writeup for MESA_query_renderer

On Thu, 2018-11-08 at 02:42 +0530, Veluri Mithun wrote: > Hi all, > Thanks Adam for your interest in this. > > > > +New Tokens > > > + > > > +Accepted as an in EGLQueryRendererIntegerMESA and > > > +EGLQueryCurrentRendererIntegerMESA: > > > + > > > +EGL_RENDERER_VENDOR_ID_MESA

Re: [Mesa-dev] [PATCH EGL/MESA] EGL/mesa: Initial write up for EGL_MESA_query_driver

On Mon, 2018-11-05 at 23:33 +0530, Veluri Mithun wrote: > +New Procedures and Functions > + > +const char* EGLGetDriverConfig(const char *driverName); This is difficult to implement in a GLVND environment. The frontend would need a way to distinguish responses from the vendor library for "I

Re: [Mesa-dev] [PATCH EGL/MESA] EGL/mesa: Initial writeup for MESA_query_renderer

On Mon, 2018-11-05 at 10:04 +0530, Veluri Mithun wrote: > Signed-off-by: Veluri Mithun Thanks for looking into this! Many of these comments apply equally to the GLX extension I think; if you wanted to write a patch for the equivalent text for that extension too, that'd be awesome. > +EGL

Re: [Mesa-dev] [PATCH RFC] egl: Add a 565 pbuffer-only EGL config under X11.

LConfig with zero bits set for EGL_SURFACE_TYPE, which is a bug in dri2_add_config() I suppose. That's probably not how driver_configs is sorted in reality, and passing CTS is a valid thing to want, so with the above addressed: Reviewed-by: Adam Jackson But if CTS can be fixed, let's do that too. -

[Mesa-dev] [PATCH] meson: Add some presets for s390 and ppc

in principle Just Work on ppc64le, but that's true of aarch64 too, and we're not building radv by default there yet either. Signed-off-by: Adam Jackson --- meson.build | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/meson.build b/meson.build index

Re: [Mesa-dev] [PATCH] docs: Update FAQ with respect to s3tc support

d October 2017, the Mesa project did not include s3tc support due > +to intellectual property (IP) and/or patent issues around the s3tc algorithm. > ... phrase it positively here, as in: "Oh, but it is! Prior to..." With that: Reviewed-by: Adam Jackson - ajax

Re: [Mesa-dev] Lets talk about autotools

On Tue, 2018-09-18 at 13:50 -0700, Dylan Baker wrote: > > It would be nice if meson would act like autotools in that regard by > > creating the drivers and libraries in specific directories (also as a > > configure option if there is concern about compilation speed). > > This is impossible by

Re: [Mesa-dev] Why are pbuffers backed by a pixmaps (Was Re: [PATCH] egl: Fix leak of X11 pixmaps backing pbuffers in DRI3.)

On Mon, 2018-08-13 at 16:32 -0700, Kristian Høgsberg wrote: > On Mon, Aug 13, 2018 at 3:53 AM Emil Velikov wrote: > > > > So if I understood you correctly [and the spec] there is no > > requirement (nor ban) on rendering to pbuffers from X11. > > It's an implementation decision to allow it. > >

Re: [Mesa-dev] Why are pbuffers backed by a pixmaps (Was Re: [PATCH] egl: Fix leak of X11 pixmaps backing pbuffers in DRI3.)

On Thu, 2018-08-09 at 18:22 +0100, Emil Velikov wrote: > In the GLX case, it's required due to server-side rendering. One needs > a separate primitive for each pbuffer, thus the information can be > passed long the wire. I can't parse this. "Primitive"? So, backstory time. GLX_SGIX_pbuffer was

Re: [Mesa-dev] [PATCH] egl: Fix leak of X11 pixmaps backing pbuffers in DRI3.

On Thu, 2018-08-09 at 17:20 +0100, Emil Velikov wrote: > If you have a moment, I'd be interested to know why we're creating a X > primitive for pbuffer surface. > IIRC pbuffers are used of off-screen rendering, thus having zero > knowledge/dependency on the underlying platform. pbuffers might be

Re: [Mesa-dev] [Mesa-stable] [PATCH] glx: GLX_MESA_multithread_makecurrent is direct-only

On Thu, 2018-08-09 at 15:54 +0300, Andres Gomez wrote: > Adam, which is the status of this patch? Is this effectively dropped? It's still valid, and still not very important. I'd just forgotten it. Merged now, thanks for the reminder: remote: remote: I: patch #191858 updated using rev

[Mesa-dev] [PATCH] glx: Demand success from CreateContext requests (v2)

Fourdan) Signed-off-by: Adam Jackson --- src/glx/glxcmds.c | 93 --- 1 file changed, 55 insertions(+), 38 deletions(-) diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c index 4db0228eaba..3ed960fbf3c 100644 --- a/src/glx/glxcmds.c +++ b/src/glx

[Mesa-dev] [PATCH] glx: Demand success from CreateContext requests

this, as a cheap way of verifying that the XID is real. glXCreateContextAttribsARB solves this by using the _checked version of the xcb command, so effectively this change makes the classic context creation paths as robust as CreateContextAttribs. Signed-off-by: Adam Jackson --- src/glx/glxcmds.c | 92

Re: [Mesa-dev] [PATCH] glx: Add checks for context being direct before calling GetGLXDRIDrawable

On Wed, 2018-08-01 at 17:15 +0300, Danylo Piliaiev wrote: > If indirect context is explicitly created by application and not > with LIBGL_ALWAYS_INDIRECT=1 then dri may be initialized in > __glXInitialize which allows Mesa to take invalid code paths > due to GetGLXDRIDrawable returning non-null

Re: [Mesa-dev] [RFC] add a config file for dri loader to choose a different dri driver

On Tue, 2018-07-31 at 08:03 +, Yu, Qiang wrote: > Seems the mesa driconf infrastructure is just what I need: > https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ > > So I can reference the loader_get_dri_config_device_id implementation > for adding loader driver override

Re: [Mesa-dev] [PATCH] Make glXChooseFBConfig handle unspecified sRGB correctly

On Mon, 2018-07-30 at 12:14 -0700, Eric Anholt wrote: > Jon Turney writes: > > > Make glXChooseFBConfig properly handle the case where the only matching > > configs have the sRGB flag set, but no sRGB attribute is specified. > > > > Since 6e06e281, the sRGBcapable flag is now actually compared,

Re: [Mesa-dev] [PATCH v3] dri3: For 1.2, use root window instead of pixmap drawable

On Fri, 2018-07-27 at 16:16 +0200, Olivier Fourdan wrote: > Hi, > > On Thu, 26 Jul 2018 at 19:53, Eric Anholt wrote: > > > > Olivier Fourdan writes: > > > > > get_supported_modifiers() and pixmap_from_buffers() requests both > > > expect a window as drawable, passing a pixmap will fail as the

[Mesa-dev] [PATCH] swrast: Fix eglMakeCurrent(dpy, NULL, NULL, ctx) (v2)

Fixes 14 piglits, mostly in egl_khr_create_context. v2: Also short-circuit the same-context-no-drawables case (Eric Anholt) Fixes: https://github.com/anholt/libepoxy/issues/177 Signed-off-by: Adam Jackson --- src/mesa/drivers/dri/swrast/swrast.c | 37 ++-- 1 file

[Mesa-dev] [PATCH] glx: Don't allow glXMakeContextCurrent() with only one valid drawable

Drawable and readable need to either both be None or both be non-None. Cc: Signed-off-by: Adam Jackson --- src/glx/glxcurrent.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/glx/glxcurrent.c b/src/glx/glxcurrent.c index fd04929b89f..2b9c708c3ee 100644 --- a/src/glx

Re: [Mesa-dev] [PATCH] swrast: Fix eglMakeCurrent(dpy, NULL, NULL, ctx)

On Fri, 2018-07-06 at 10:29 +0100, Emil Velikov wrote: > Skimming through the egl_khr_create_context text, this relaxes some > parts which are meant to be an error. > For example > > * If either of or is a valid surface and the other > is EGL_NO_SURFACE, an EGL_BAD_MATCH error is

[Mesa-dev] [PATCH] swrast: Fix eglMakeCurrent(dpy, NULL, NULL, ctx)

Fixes 14 piglits, mostly in egl_khr_create_context. Fixes: https://github.com/anholt/libepoxy/issues/177 Signed-off-by: Adam Jackson --- src/mesa/drivers/dri/swrast/swrast.c | 34 +++- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/src/mesa/drivers/dri

Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

On Fri, 2018-06-15 at 11:23 -0600, Kyle Brenneman wrote: > The Khronos repository basically is a package for the headers. The > challenge is that the pkg-config file has to specify an include path and > a library path. The include path depends on where you put the header > files (which are in

Re: [Mesa-dev] [PATCH mesa] add project README

On Fri, 2018-06-08 at 16:57 +0100, Eric Engestrom wrote: > +Build & install > +--- > + > +You can find more information in our documentation (`docs/install.html > +`_), but the recommdended way is to use 'recommended' - ajax

Re: [Mesa-dev] GitLab migration update

On Thu, 2018-06-07 at 08:25 +0100, Daniel Stone wrote: > The following dormant repos were _not_ migrated, but can be migrated > (perhaps to an archive/ section?) if they are still useful: > clover glw libwsbm linux-agp-compat r600_demo rbug-gui Eek. glw has a bugfix in it from me I don't even

Re: [Mesa-dev] GitLab personal repos

On Sat, 2018-06-02 at 13:10 -0400, Rob Clark wrote: > On Sat, Jun 2, 2018 at 12:07 PM, Jason Ekstrand wrote: > > 1) Forks share objects behind the user's back so it should use > > significantly less space on the GitLab server if everyone's personal mesa > > repo is an actual GitLab fork and not

Re: [Mesa-dev] [PATCH] glx: Fix number of property values to read in glXImportContextEXT

text (v2)" > Signed-off-by: Michel Dänzer Ugh. Truly embarrassing. Reviewed-by: Adam Jackson - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] drisw Xshm support

4 instead of 3. > > I've also tested it works against an cirrus fbdev packed 24bpp X server. Thanks for dusting these off. Series is: Reviewed-by: Adam Jackson - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.fr

Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

On Tue, 2018-05-29 at 09:54 -0700, Dylan Baker wrote: > Quoting Adam Jackson (2018-05-29 06:50:46) > > GL_LIB expands to GLX_mesa, but applications should not link against > > that. -lGL is never wrong, just hardcode it. > > Actually There is this really stupid option i

Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

On Tue, 2018-05-29 at 18:35 +0100, Emil Velikov wrote: > On 29 May 2018 at 15:29, Daniel Stone wrote: > > On 29 May 2018 at 15:17, Eric Engestrom wrote: > > > On Tuesday, 2018-05-29 09:50:46 -0400, Adam Jackson wrote: > > > > GL_LIB expands to GLX_mesa, but applic

[Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

GL_LIB expands to GLX_mesa, but applications should not link against that. -lGL is never wrong, just hardcode it. Signed-off-by: Adam Jackson --- src/mesa/gl.pc.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/gl.pc.in b/src/mesa/gl.pc.in index 181724b97b

Re: [Mesa-dev] [PATCH] glx/dri: Take an extra reference on our own GLX drawables

On Wed, 2018-05-09 at 18:17 +0200, Michel Dänzer wrote: > On 2018-05-08 09:47 PM, Adam Jackson wrote: > > dri*_bind_context, when switching current drawables, will drop the > > reference on the old one; since that refcount has probably now gone to > > zero that means we

Re: [Mesa-dev] [PATCH 2/2] loader_dri3: Variant 2: Wait for pending swaps to complete before drawable_fini.

On Tue, 2018-05-08 at 11:42 +0200, Michel Dänzer wrote: > Idle notify events shouldn't need special treatment, since the pixmap > XIDs of the buffers will be different between loader_dri3_drawable > incarnations, aren't they? We're destroying loader_dri3_drawable structs at MakeCurrent time, but

Re: [Mesa-dev] [RFC] Fix attempt for Mesa + X-Server 1.20 + modesetting-ddx hangs on KDE5.

On Fri, 2018-05-04 at 15:45 +0200, Mario Kleiner wrote: > The real problem, if i understand it correctly, is the way the life-time > of dri3_drawables and loader_dri3_drawables is managed atm. by Mesa's > bindContext() functions. Whenever glXMakeCurrent() etc. are called to > assign new/different

[Mesa-dev] [PATCH] glx/dri: Take an extra reference on our own GLX drawables

quickly, let alone test promptly against a wide enough range of servers and DRIs to have any confidence in. I'll work on the real solution, but in the meantime this is effectively not a memory leak for any real scenario, and fixes a real bug. Signed-off-by: Adam Jackson <a...@redhat.com> Cc:

Re: [Mesa-dev] [PATCH] dri2: Sync i965_pci_ids.h from Mesa.

On Wed, 2018-03-07 at 07:46 -0800, Rodrigo Vivi wrote: > Copied from Mesa with no modifications. > > Gives us Geminilake and Kaby Lake platform names updates and > sync on Coffee Lake PCI IDs. > > Cc: Timo Aaltonen > Signed-off-by: Rodrigo Vivi

Re: [Mesa-dev] [RFC 0/6] Remove stubbed GLX_SGIX_swap_{barrier, group}

e client side ever saw the light of day. At any rate the empty stubs can't possibly be helping anything. Series is: Reviewed-by: Adam Jackson <a...@redhat.com> - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC][PATCH xserver] Multi-buffered flips on subsurfaces seg fault in Mesa

On Mon, 2018-01-29 at 17:54 +0100, Roman Gilg wrote: > The above patch series only allows flips on a child window with the same > dimensions as its parent xwl_window. For flips on child windows (for example > the video view port of a video player in windowed mode, see here: >

Re: [Mesa-dev] [PATCH shaderdb 2/3] run: fallback to 3.1 core context

On Mon, 2018-01-29 at 15:08 -0500, Rob Clark wrote: > Hmm, does that mean there is no way to create a 3.1 core profile if a > driver supports 3.1 compat? This is where the "forward-compatible" bit matters, iirc. If you ask for 3.1FC you shouldn't get ARB_compatibility. - ajax

Re: [Mesa-dev] [PATCH mesa] egl: keep extension list sorted, per comment at the top

On Thu, 2018-01-25 at 10:14 +, Eric Engestrom wrote: > Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com> Reviewed-by: Adam Jackson <a...@redhat.com> - ajax ___ mesa-dev mailing list mesa-dev@lists.freede

Re: [Mesa-dev] [PATCH 1/2] meson: Fix configuring dri glx with only gallium drivers

On Mon, 2018-01-15 at 20:01 +, Jon Turney wrote: > On 12/01/2018 17:25, Dylan Baker wrote: > > meson considers classic swrast to be a dri driver, I know it's not exactly > > accurate, but, at least for me, it made the build system easier to reason > > about. > > I think maybe the point here

Re: [Mesa-dev] [PATCH 1/2] meson: Fix configuring dri glx with only gallium drivers

On Fri, 2018-01-12 at 13:18 +, Jon Turney wrote: > 'meson -Ddri-drivers= -Dgallium-drivers=swrast -Dglx=dri' fails with 'dri > based GLX requires at least one DRI driver' > > Signed-off-by: Jon Turney > --- > meson.build | 2 +- > src/glx/meson.build | 2

Re: [Mesa-dev] [PATCH] link mesautil with pthreads

On Mon, 2018-01-01 at 22:49 +0100, Igor Gnatenko wrote: > ../../src/util/.libs/libmesautil.a(libmesautil_la-u_queue.o): In function > `u_thread_setname': > /builddir/build/BUILD/mesa-17.3.1/src/util/../../src/util/u_thread.h:66: > undefined reference to `pthread_setname_np' >

Re: [Mesa-dev] [Mesa-stable] [PATCH] glx: GLX_MESA_multithread_makecurrent is direct-only

On Wed, 2017-12-06 at 15:01 -0500, Ian Romanick wrote: > On 12/06/2017 10:32 AM, Emil Velikov wrote: > > On 5 December 2017 at 16:10, Adam Jackson <a...@redhat.com> wrote: > > > This extension is not defined for indirect contexts. Marking it as > > > "client

Re: [Mesa-dev] [PATCH 2/3] glx: Lift sending the MakeCurrent request to top-level code (v2)

On Wed, 2017-12-06 at 15:14 +, Emil Velikov wrote: > > - if (gc->vtable->bind(gc, oldGC, draw, read) != Success) { > > + if (gc->vtable->bind(gc, gc, draw, read) != Success) { > > __glXSetCurrentContextNull(); > > This line seems inconsistent/wrong. > > The

  1   2   3   4   5   >