Re: Headless OpenGL Rendering using SSH and X11 forwarding

If that's the case, yes, I can confirm the NV driver does not support rendering with remote X servers using EGL, with or without indirect GLX support enabled in said server, and yes, EGLDevice will work just fine in that situation for offscreen rendering if you're trying to use the local GPU.

Re: Xbox Series S/X UWP

On 6/6/22 09:22, Jesse Natalie wrote: (Hopefully this goes through and not to spam like last time I tried to respond…) No, neither of these would currently work with UWP. The primary reason is that neither Khronos API has extensions to initialize the winsys on top of the UWP core window

[Mesa-dev] [RFC] GBM Alternate Backend Discovery & Loading

I've brought this up in the past, but I have some patches implementing it now, so I was hoping to get some further feedback on the idea of supporting GBM backends external to Mesa. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902 From my reading, the GBM core code was intended

Re: [Mesa-dev] [PATCH 0/5] nouveau: Improved format modifier support

Thanks, now available as https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3724 -James On 2/5/20 1:45 PM, Jason Ekstrand wrote: FYI: GitLab merge requests are the preferred way to send patches these days. --Jason On February 5, 2020 21:52:25 James Jones wrote: This series pulls

[Mesa-dev] [PATCH 2/5] nouveau: Stash supported sector layout in screen

its chipset and stash the layout in the nouveau screen structure. Signed-off-by: James Jones --- src/gallium/drivers/nouveau/nouveau_screen.c | 12 src/gallium/drivers/nouveau/nouveau_screen.h | 1 + 2 files changed, 13 insertions(+) diff --git a/src/gallium/drivers/nouveau

[Mesa-dev] [PATCH 1/5] drm-uapi: Update headers from nouveau/linux-5.6

Copy latest drm_fourcc.h from nouveau/linux-5.6 XXX - Update this with final commit ID/info commit: d8a841ff4f4cbb31dd0dfd037399421969837730 Author: James Jones Date: Tue Aug 6 17:10:10 2019 -0700 drm: Generalized NV Block Linear DRM format mod Signed-off-by: James Jones --- include/drm

[Mesa-dev] [PATCH 5/5] nouveau: Use format modifiers in buffer allocation

, if modifiers are provided and none are compatible with the miptree creation request, the function now fails. This brings the nouveau behavior in line with other drivers such as i965 and etnaviv. Signed-off-by: James Jones --- .../drivers/nouveau/nvc0/nvc0_miptree.c | 111 -- 1

[Mesa-dev] [PATCH 3/5] nouveau: Use DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D

for more resource types, but overall this should be a functional no-op for existing applications. Signed-off-by: James Jones --- .../drivers/nouveau/nvc0/nvc0_miptree.c | 99 --- .../drivers/nouveau/nvc0/nvc0_resource.c | 37 --- .../drivers/nouveau/nvc0

[Mesa-dev] [PATCH 4/5] nouveau: no modifier != the invalid modifier

resources, so there is not yet a framework in place to determine which modifiers are valid for a given resource creation request, and hence no way to reject only those which are invalid. Signed-off-by: James Jones --- src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 4 +--- 1 file changed, 1

[Mesa-dev] [PATCH 0/5] nouveau: Improved format modifier support

on the general gallium/dri cleanup patch: [PATCH] gallium: Add format modifier aux plane query Which was sent out separately. James Jones (5): drm-uapi: Update headers from nouveau/linux-5.6 nouveau: Stash supported sector layout in screen nouveau: Use DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D

[Mesa-dev] [PATCH] gallium: Add format modifier aux plane query

is the iris driver's I915_FORMAT_MOD_Y_TILED_CCS, provide a generic implementation of this screen proc as a utility function, and use that in every driver besides the iris driver, which requires a trivial customization on top of it. Signed-off-by: James Jones --- src/gallium/auxiliary/util/u_screen.c

Re: [Mesa-dev] [PATCH 2/2] nouveau: Enable support for EXT_external_objects

FWIW, Reviewed-by: James Jones For the series, but someone more familiar with Nouveau should probably review as well. Thanks, -James On 06/21/2018 07:01 PM, Miguel A. Vico wrote: Enable EXT_external_objects for nvc0 and nv50 Signed-off-by: Miguel A Vico Moya --- src/gallium/drivers

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

On 02/22/2018 01:16 PM, Alex Deucher wrote: On Thu, Feb 22, 2018 at 1:49 PM, Bas Nieuwenhuizen wrote: On Thu, Feb 22, 2018 at 7:04 PM, Kristian Høgsberg wrote: On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher wrote: On Wed,

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

On 12/28/2017 10:24 AM, Miguel Angel Vico wrote: (Adding dri-devel back, and trying to respond to some comments from the different forks) James Jones wrote: Your worst case analysis above isn't far off from our HW, give or take some bits and axes here and there. We've started an internal

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

On 12/20/2017 01:58 PM, Daniel Stone wrote: Hi Miguel, On 20 December 2017 at 16:51, Miguel Angel Vico wrote: In the meantime, I've been working on putting together an open source implementation of the allocator mechanisms using the Nouveau driver for all to be able to

Re: [Mesa-dev] GBM and the Device Memory Allocator Proposals

On 12/06/2017 03:25 AM, Nicolai Hähnle wrote: On 06.12.2017 08:07, James Jones wrote: [snip] So lets say you have a setup where both display and GPU supported FOO/tiled, but only GPU supported compressed (FOO/CC) and cached (FOO/cached).  But the GPU supported the following transitions

Re: [Mesa-dev] GBM and the Device Memory Allocator Proposals

On 12/01/2017 01:52 PM, Miguel Angel Vico wrote: On Fri, 1 Dec 2017 13:38:41 -0500 Rob Clark wrote: On Fri, Dec 1, 2017 at 12:09 PM, Nicolai Hähnle wrote: On 01.12.2017 16:06, Rob Clark wrote: On Thu, Nov 30, 2017 at 5:43 PM, Nicolai Hähnle

Re: [Mesa-dev] GBM and the Device Memory Allocator Proposals

On 12/01/2017 10:34 AM, Nicolai Hähnle wrote: On 01.12.2017 18:09, Nicolai Hähnle wrote: [snip] As for the actual transition API, I accept that some metadata may be required, and the metadata probably needs to depend on the memory layout, which is often vendor-specific. But even linear

Re: [Mesa-dev] GBM and the Device Memory Allocator Proposals

On 11/30/2017 12:06 PM, Lyude Paul wrote: On Thu, 2017-11-30 at 13:20 -0500, Rob Clark wrote: On Thu, Nov 30, 2017 at 12:59 AM, James Jones <jajo...@nvidia.com> wrote: On 11/29/2017 04:09 PM, Miguel Angel Vico wrote: On Wed, 29 Nov 2017 16:28:15 -0500 Rob Clark <robdcl...@gmail.c

Re: [Mesa-dev] GBM and the Device Memory Allocator Proposals

On 11/30/2017 10:48 AM, Rob Clark wrote: On Thu, Nov 30, 2017 at 1:28 AM, James Jones <jajo...@nvidia.com> wrote: On 11/29/2017 01:10 PM, Rob Clark wrote: On Wed, Nov 29, 2017 at 12:33 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote: On Sat, Nov 25, 2017 at 1:20 PM, Rob C

Re: [Mesa-dev] GBM and the Device Memory Allocator Proposals

November 24, 2017 09:29:43 Rob Clark <robdcl...@gmail.com> wrote: On Mon, Nov 20, 2017 at 8:11 PM, James Jones <jajo...@nvidia.com> wrote: As many here know at this point, I've been working on solving issues related to DMA-capable memory allocation for various devices for s

Re: [Mesa-dev] GBM and the Device Memory Allocator Proposals

y require some adjustments. Thanks, Miguel. Once we agree upon something, I can take care of filing the request, but I'm unclear what the initial list of approvers should be. Looking at the main contributors of both the initial draft of $new_thing and git repository, does the following list of

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

<airl...@redhat.com> Cc: Daniel Stone <dani...@collabora.com> Cc: Chad Versace <chadvers...@chromium.org> Cc: James Jones <jajo...@nvidia.com> Daniel Stone (1): vulkan/wsi: Add a wsi_image structure Dave Airlie (4): vulkan/wsi: use function ptr definitions from the spec.

[Mesa-dev] GBM and the Device Memory Allocator Proposals

eeded to implement the improved allocator mechanisms, we'll be contributing patches if no one beats us to it. Thanks in advance for any feedback! -James Jones ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] EGL_EXT_*_drm - primary vs render node (Was Re: [Piglit] [PATCH 1/2] egl: Add sanity test for EGL_EXT_device_query (v3))

On 09/12/2016 07:00 AM, Emil Velikov wrote: Hi James, On 8 September 2016 at 17:27, Emil Velikov wrote: In order to clear any ambiguity in EGL_EXT_device_drm we need to "s/DRM driver./DRM driver which support KMS./". With that small change things should be fine.

Re: [Mesa-dev] EGL_EXT_*_drm - primary vs render node (Was Re: [Piglit] [PATCH 1/2] egl: Add sanity test for EGL_EXT_device_query (v3))

On 09/08/2016 04:30 AM, Emil Velikov wrote: On 7 September 2016 at 19:54, James Jones <jajo...@nvidia.com> wrote: On 09/07/2016 04:18 AM, Emil Velikov wrote: Hi Mathias, On 6 September 2016 at 18:32, Mathias Fröhlich <mathias.froehl...@gmx.net> wrote: ** EGL_EXT_output_drm

Re: [Mesa-dev] EGL_EXT_*_drm - primary vs render node (Was Re: [Piglit] [PATCH 1/2] egl: Add sanity test for EGL_EXT_device_query (v3))

On 09/07/2016 04:18 AM, Emil Velikov wrote: Hi Mathias, On 6 September 2016 at 18:32, Mathias Fröhlich wrote: ** EGL_EXT_output_drm Correction - the above should read: EGL_EXT_{device,output}_drm *** Using/exposing the card or render node - Extension is

Re: [Mesa-dev] [PATCH 2/2] egl: implement EGL_MESA_transparent_alpha for x11 and wayland

On 03/03/2015 11:05 AM, Daniel Stone wrote: Hi, On 3 March 2015 at 18:56, Jason Ekstrand ja...@jlekstrand.net wrote: On Tue, Mar 3, 2015 at 10:07 AM, Chad Versace chad.vers...@intel.com wrote: On 02/23/2015 06:32 AM, Jonny Lamb wrote: + static const EGLint argb_attrs[] = { +

Re: [Mesa-dev] [PATCH 2/2] egl: implement EGL_MESA_transparent_alpha for x11 and wayland

On 04/17/2015 04:08 PM, James Jones wrote: On 03/03/2015 11:05 AM, Daniel Stone wrote: Hi, On 3 March 2015 at 18:56, Jason Ekstrand ja...@jlekstrand.net wrote: On Tue, Mar 3, 2015 at 10:07 AM, Chad Versace chad.vers...@intel.com wrote: On 02/23/2015 06:32 AM, Jonny Lamb wrote: + static

Re: [Mesa-dev] glxinfo and indirect contexts on nvidia driver

Hi Dave, Adding { GLX_DRAWABLEL_TYPE, GLX_WINDOW_BIT } to the attrib list should work, and would technically be more correct since glxinfo is creating a window drawable. 32-bit float FBConfigs won't be able to render to X drawables (at least on our driver), so they don't have associated

Re: [Mesa-dev] Mesa drivers/GLX and fork

In case it helps, we have always interpreted the spec as follows: -Forking duplicates process memory and FDs, including the display connection and the GLX context client-side state (and GL server state if direct rendering, but not X server state, such as the context XID), as messy as that is.

Re: [Mesa-dev] OpenGL compositors and glxWaitX()

On 6/6/11 2:09 AM, Thomas Hellstrom thellst...@vmware.com wrote: Hi! While trying to improve the vmwgfx X driver to better cope with OpenGL compositors, I noticed that compiz never calls glxWaitX() to make sure the pixmaps that it textures from are updated. Since we migrate X rendered

Re: [Mesa-dev] glXMakeCurrent crashes (was: Re: How to obtain OpenGL implementation/driver information?)

On 2/4/11 3:26 PM, Benoit Jacob bja...@mozilla.com wrote: - Original Message - On Fre, 2011-02-04 at 14:21 -0800, Benoit Jacob wrote: - Original Message - Benoit Jacob wrote: - Original Message - On Thu, Feb 3, 2011 at 4:37 PM, Benoit Jacob