On 1/20/25 14:00, Laurent Pinchart wrote:
On Fri, Jan 10, 2025 at 01:23:40PM -0800, James Jones wrote:
On 12/19/24 10:03, Simona Vetter wrote:
On Thu, Dec 19, 2024 at 09:02:27AM +, Daniel Stone wrote:
On Wed, 18 Dec 2024 at 10:32, Brian Starkey wrote:
On Wed, Dec 18, 2024 at 11:24:58AM
ng only 1 linear
modifier is OK. Then, you can look at modifiers of other drivers if you
want to find commonalities.
DRM_FORMAT_MOD_LINEAR needs to go because it prevents apps from
detecting whether 2 devices have 0 compatible memory layouts, which is a
useful thing to know.
Marek
On Fri, Jan 10
On 12/19/24 10:03, Simona Vetter wrote:
On Thu, Dec 19, 2024 at 09:02:27AM +, Daniel Stone wrote:
On Wed, 18 Dec 2024 at 10:32, Brian Starkey wrote:
On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
For that reason I think linear modifiers with explicit pitch/size
alignment c
by Wine then you never run
into this issue. You would just allocate some address range internally
and mremap() into that.
Regards,
Christian.
Am 22.10.24 um 19:32 schrieb James Jones:
This sounds interesting, but does it come with the same "Only gets 2GB
VA" downside Derek pointed out
This sounds interesting, but does it come with the same "Only gets 2GB
VA" downside Derek pointed out in the thread fork where he was
responding to Michel?
Thanks,
-James
On 10/22/24 07:14, Christian König wrote:
Hi guys,
one theoretical alternative not mentioned in this thread is the use of
On 10/21/24 07:33, Jose Fonseca wrote:
I see a few downsides with the proposed callback:
- feels like a solution too tailored for WINE
- there's a layering violation: the application suddenly takes the
driving seat for a thing deep down in the GL driver
so I fear Mesa community might regret it d
FWIW, the NVIDIA binary driver's implementation of gbm_bo_map/unmap()
1) Don't do any synchronization against in-flight work. The assumption
is that if the content is going to be read, the API writing the data has
established that coherence. Likewise, if it's going to be written, the
API readi
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.
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 infra
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 to
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 in
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
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
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
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
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
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
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_scr
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
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, Feb 21, 2018 at 1:14 AM, Chad Versace
wrote:
On Thu 21 Dec 2017, Da
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 a
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 play with.
Thanks for
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
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
wrote:
Hi,
I've had a chance to look a bit
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 layouts
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 wrote:
On 11/29/2017 04:09 PM, Miguel Angel Vico wrote:
On Wed, 29 Nov 2017 16:28:15 -0500
Rob Clark wrote:
Do we need to define both in-place and
On 11/30/2017 10:48 AM, Rob Clark wrote:
On Thu, Nov 30, 2017 at 1:28 AM, James Jones wrote:
On 11/29/2017 01:10 PM, Rob Clark wrote:
On Wed, Nov 29, 2017 at 12:33 PM, Jason Ekstrand
wrote:
On Sat, Nov 25, 2017 at 1:20 PM, Rob Clark wrote:
On Sat, Nov 25, 2017 at 12:46 PM, Jason
, James Jones
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 some time
now.
I'd
like to take this opportunity to apologize for the way I handled the
EGL
stream proposals. I understand no
2017 at 1:20 PM, Rob Clark wrote:
On Sat, Nov 25, 2017 at 12:46 PM, Jason Ekstrand
wrote:
On November 24, 2017 09:29:43 Rob Clark wrote:
On Mon, Nov 20, 2017 at 8:11 PM, James Jones
wrote:
As many here know at this point, I've been working on solving issues
related
to DMA-capable m
edesktop.org/~jekstrand/mesa/log/?h=wip/vulkan-wsi-prime
Cc: Dave Airlie
Cc: Daniel Stone
Cc: Chad Versace
Cc: James Jones
Daniel Stone (1):
vulkan/wsi: Add a wsi_image structure
Dave Airlie (4):
vulkan/wsi: use function ptr definitions from the spec.
radv/wsi: drop allocate memory spe
modifications to the nouveau kernel & userspace drivers are
needed 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
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.
Further to the above (trivi
On 09/08/2016 04:30 AM, Emil Velikov wrote:
On 7 September 2016 at 19:54, James Jones wrote:
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
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 designed with EGL streams in mind
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 wrote:
On Tue, Mar 3, 2015 at 10:07 AM, Chad Versace
wrote:
On 02/23/2015 06:32 AM, Jonny Lamb wrote:
+ static const EGLint argb_attrs
On 03/03/2015 11:05 AM, Daniel Stone wrote:
Hi,
On 3 March 2015 at 18:56, Jason Ekstrand wrote:
On Tue, Mar 3, 2015 at 10:07 AM, Chad Versace
wrote:
On 02/23/2015 06:32 AM, Jonny Lamb wrote:
+ static const EGLint argb_attrs[] = {
+ EGL_TRANSPARENT_TYPE, EGL_TRANSPARENT_ALPHA_MESA,
+
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 visua
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.
On 12/16/11 4:27 PM, Younes Manton wrote:
On Fri, Dec 16, 2011 at 7:01 PM, James Cloos wrote:
I've been trying to test out vdpau w/o success.
It turns out that libvdpau_r600.so is in /usr/lib64/vdpau/, whereas
everything looks for it in the standard ld path (ie, /usr/lib64).
With »ln -s vdpau
On 6/6/11 2:09 AM, "Thomas Hellstrom" 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 data to the dri
On 2/4/11 3:26 PM, "Benoit Jacob" 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
>>
41 matches
Mail list logo
