On Thu, 2018-01-25 at 10:14 +, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
Reviewed-by: Adam Jackson
- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
___
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:
> http://www.subdiff.de/
We're not using anything in it, and we don't want to inherit struct
definitions from some other package anyway.
Signed-off-by: Adam Jackson
---
src/glx/glxconfig.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/glx/glxconfig.c b/src/glx/glxconfig.c
index e5718b1..0e1643f 10
The only difference from the EXT version is bumping the minmax to 16, so
just hit all the drivers at once.
v2: Fix driver names, add to 17.3 release notes (Ilia Mirkin)
Reviewed-by: Ilia Mirkin
Signed-off-by: Adam Jackson
---
docs/features.txt| 4 +++-
docs
Semantically identical to the EXT version (whose string is still valid
for GLES), so rename the bit but expose both extension strings.
(Suggested by Ilia Mirkin and Ian Romanick.)
Signed-off-by: Adam Jackson
---
docs/features.txt| 2 +-
docs/relnotes/17.3.0.html
The snprintf stuff here already constructs the right name for the device
node, and if it doesn't, you configured Mesa wrong, don't do that.
Signed-off-by: Adam Jackson
---
src/egl/drivers/dri2/platform_drm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/egl/dr
Semantically identical to the EXT version (whose string is still valid
for GLES), so rename the bit but expose both extension strings.
(Suggested by Ilia Mirkin and Ian Romanick.)
v3: Fix the entrypoint alias in GL4x.xml (Ilia)
Signed-off-by: Adam Jackson
---
docs/features.txt
On Thu, 2017-08-24 at 23:27 -0700, Kenneth Graunke wrote:
> > diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
> > index 21ad02a44b..2a595516ee 100644
> > --- a/src/glx/glxextensions.h
> > +++ b/src/glx/glxextensions.h
> > @@ -101,6 +101,7 @@ enum
> > GL_ARB_texture_env_combine_b
On Fri, 2017-08-25 at 14:41 +0100, Emil Velikov wrote:
> Should we drop the "if (n != -1 && n < sizeof(buf))" part as well with
> this patch?
Meh. I've got some other changes coming in the area so that'll probably
happen soon anyway. At least for this change I just wanted to make
things determini
On Thu, 2017-08-03 at 20:07 +0200, Grigori Goronzy wrote:
> diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c
> b/src/gallium/state_trackers/glx/xlib/xm_api.c
> index 828253b..508db5c 100644
> --- a/src/gallium/state_trackers/glx/xlib/xm_api.c
> +++ b/src/gallium/state_trackers/glx/xlib/x
On Thu, 2017-08-31 at 11:41 -0400, Adam Jackson wrote:
> On Thu, 2017-08-03 at 20:07 +0200, Grigori Goronzy wrote:
> > @@ -981,6 +983,8 @@ XMesaContext XMesaCreateContext( XMesaVisual v,
> > XMesaContext share_list,
> >attribs.flags |= ST_CONTEXT_FLAG_DEBUG;
>
On Thu, 2017-08-03 at 20:07 +0200, Grigori Goronzy wrote:
> @@ -592,4 +601,45 @@ dri2_convert_glx_attribs(unsigned num_attribs, const
> uint32_t *attribs,
> return true;
> }
>
> +_X_HIDDEN bool
> +dri2_check_no_error(uint32_t flags, struct glx_context *share_context,
> +
On Fri, 2017-09-01 at 15:04 +0100, Eric Engestrom wrote:
> These fields were added in 2d94601582 but never used; hasPresent was
> never set, while the other ones were set but never read.
I think this patch is wrong:
> - dri3_reply = xcb_dri3_query_version_reply(c, dri3_cookie, &error);
> - if
On Tue, 2017-09-12 at 16:08 +0100, Eric Engestrom wrote:
> On Wednesday, 2017-09-06 17:25:29 +0100, Emil Velikov wrote:
> > I'm not that much of an expert on things XCB, so perhaps a silly question.
> > Isn't the presence checked with the code just above the removed hunk?
> > Namely:
> >
> > exte
in the latter case you'd end up with an
EGLConfig 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 J
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 1.
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 d
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
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
enderer = */ -1,
0, &value);
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(-)
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
Signed-off-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
+
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
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
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
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
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
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,
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 functionali
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 val
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
ivier 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/sr
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
63a6b719d9
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
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 t
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.
>
>
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 I'
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 Fri,
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 fix
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, Oc
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
shouldn't
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 iss
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 insta
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 des
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
archives
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 can
On Thu, Jun 20, 2024 at 10:20 AM Erik Faye-Lund <
erik.faye-l...@collabora.com> wrote:
> When we did Amber, we had a lot better reason to do so than "these
> drivers cause pain when doing big tree updates". The maintenance burden
> imposed by the drivers proposed for removal here is much, much sma
On Mon, 2016-03-28 at 11:10 -0700, Ian Romanick wrote:
> > @@ -428,7 +428,7 @@ class PrintGlxReqSize_h(PrintGlxReqSize_common):
> def printBody(self, api):
> > for func in api.functionIterateGlx():
> > if not func.ignore and func.has_variable_size_request():
> > -
Signed-off-by: Adam Jackson
---
src/mapi/glapi/gen/gl_XML.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
index 2e7123e..e11f6fc 100644
--- a/src/mapi/glapi/gen/gl_XML.py
+++ b/src/mapi/glapi/gen/gl_XML.py
We're about to update the generator scripts to use these, easier not to
vary between client and server.
Signed-off-by: Adam Jackson
---
src/mapi/glapi/gen/glX_proto_send.py | 24
1 file changed, 24 insertions(+)
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
Another attempt at syncing the GLX generator scripts with xserver.
Jon mentioned a couple of issues in the last series, namely that these two
patches were still necessary:
https://lists.x.org/archives/xorg-devel/2014-April/041597.html
https://lists.x.org/archives/xorg-devel/2014-April/041919.html
Otherwise the instances in the extension XML override the core
definitions, and we stop knowing their sizes in indirect_size_get.c
Signed-off-by: Adam Jackson
---
src/mapi/glapi/gen/ARB_viewport_array.xml | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/src
Signed-off-by: Adam Jackson
---
src/mapi/glapi/gen/gl_XML.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
index 4f35343..8036a02 100644
--- a/src/mapi/glapi/gen/gl_XML.py
+++ b/src/mapi/glapi/gen/gl_XML.py
Squashes the one remaining warning in the xserver build.
v2: Also clean up some non-standard whitespace (Ian Romanick)
Reviewed-by: Ian Romanick
Signed-off-by: Adam Jackson
---
src/mapi/glapi/gen/glX_proto_recv.py | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
v2: Use == not is for equality testing (Dylan Baker)
Signed-off-by: Adam Jackson
---
src/mapi/glapi/gen/glX_XML.py| 2 +-
src/mapi/glapi/gen/glX_proto_recv.py | 2 --
src/mapi/glapi/gen/glX_proto_send.py | 2 --
src/mapi/glapi/gen/glX_proto_size.py | 24 +++-
src
From: Emil Velikov
It will allows us to find the function within 6 attempts, out of the ~80
entry long table.
Reviewed-by: Adam Jackson
Signed-off-by: Emil Velikov
---
src/glx/glxglvnd.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/src/glx/glxglvnd.c
From: Emil Velikov
Rather than checking if the function name maps to a valid entry in the
respective table, just create a dummy entry at the end of each table.
This allows us to remove some unnessesary "index >= 0" checks, which get
executed quite often.
Reviewed-by: Adam Jackso
nctions as _GLX_PUBLIC so they are not exported when
building for libglvnd. I (ajax) squashed them together both for ease of
review, and because most of the changes are un-useful intermediate
states representing the evolution of glvnd's internal API.
Co-author: Emil Velikov
Reviewed-b
On Thu, 2016-05-12 at 19:58 +0100, Emil Velikov wrote:
> > In dispatch_ChooseFBConfigSGIX, if AddFBConfigsMapping fails, should it use
> > free or XFree to free the memory?
> >
> In theory it should be XFree(). In practise that one has been a
> wrapper around free() for a long time so I've went w
creen=1 is passed to glXGetFBConfigs.
>
> Fix this typo in glXGetFBConfigs.
>
> Signed-off-by: Jiri Slaby
> Cc:
Reviewed-by: Adam Jackson
- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
fe_pad() ...", and a unary + would
coerce the result to always be positive, defeating the overflow check.
Signed-off-by: Adam Jackson
---
src/mapi/glapi/gen/glX_proto_send.py | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/ge
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 maili
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
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
> > >
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
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 resul
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,
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:
https://gitlab.freedesktop
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
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
>
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 d
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). How
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 nee
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 implementatio
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 implem
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 ide
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, whi
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
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 of
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 th
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 llvmpi
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 numbe
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
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 sin
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 becau
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 nee
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
_
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
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 o
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
I've been looking at untangling the pixel format code for big-endian.
My current theory is that blindly byte-swapping values is just wrong.
Data coming from the application is never in the "wrong" order.
Consider the first non-trivial format emitted in u_format_table.c:
/* taken from an x86 bu
On Mon, 2013-02-11 at 05:27 -0800, Jose Fonseca wrote:
> > Actually, on second thought this means it's probably better to keep the
> > current naming scheme for array formats. Maybe the component names and
> > sizes could be packed together to indicate packed formats, e.g.
> > PIPE_FORMAT_B5G6R5_U
On 11/27/11 9:13 PM, Ian Romanick wrote:
I'm starting to work on GLX_ARB_create_context. This extension and the
layered GLX_ARB_create_context_profile extension add some GLX protocol.
Is there any reason to keep supporting non-XCB protocol? Are there any
platforms that can't / don't use XCB for
On 12/7/11 4:16 AM, Michel Dänzer wrote:
On Mit, 2011-12-07 at 08:40 +, Dave Airlie wrote:
I have a feeling, since dri2 is not strictly restricted to GLX, whether this
should really be
implemented in the glx code before calling into dri2? Otoh that would mean
the server side
would need to b
idr/mesa glx-fixes
> git://anongit.freedesktop.org/~idr/xserver glx-fixes
>
> With these two branches, I observer no piglit regressions on Intel
> Ironlake hardware. I have not tested other hardware, but I would
> expect any regressions to be hardware independent.
Reviewed-by: A
On Sat, 2011-12-10 at 11:46 -0600, David Fries wrote:
> Set the close on exec flag when opening dri character devices, so they
> will be closed and free any resouces allocated in exec.
Reviewed-by: Adam Jackson
- ajax
signature.asc
Description: This is a digitally signed messag
st how old of an SGI machine would you
have to find, anyway.
Reviewed-by: Adam Jackson
- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 12/16/11 4:28 PM, Ian Romanick wrote:
On 12/16/2011 12:51 PM, Adam Jackson wrote:
Series looks good. I got a chuckle out of the GLX 1.0 thing, I'm
completely unsurprised that nobody's recently run Mesa against an OpenGL
that didn't support texturing. Just how old of an SGI ma
On Mon, 2011-12-19 at 09:40 +, Dave Airlie wrote:
> On Wed, Dec 7, 2011 at 6:32 PM, Eric Anholt wrote:
> > On Wed, 7 Dec 2011 10:24:09 +, Dave Airlie wrote:
> >> From: Dave Airlie
> >>
> >> This keeps track of the creation process and stores a drawable type,
> >> it then blocks DRI2 fro
301 - 400 of 448 matches
Mail list logo
