Hi Stephen,
I don't have any time to spend on Mesa these days, so a bit of a late answer.
On Wed, 27 Oct 2021 at 08:46, Stephen Crowell
wrote:
>
> To whom it may concern,
>
> I am attempting to use Mesa with EGL for a project and I have run into an
> issue when initializing a device. My setup u
Hi Dylan,
On Sat, 30 Jan 2021 at 04:12, Dylan Baker wrote:
>
> Hi list,
>
> Better late than never, mesa 20.3.4 is now available for your
> consumption. Sorry for the brief announcment, I'm a little short on
> time.
>
The website lists 20.3.3 as the latest version. Did you forget to push
those or
Hey Keith,
Most of the cool kids prefer gitlab MR, can you open one going forward?
That aside, here is some long overdue input on the patch itself.
My biggest concern that we expose the extension, even when it's not implemented.
The rest are rather minor - more documentation/comments, style fixes
Hi Mark,
On Fri, 21 Feb 2020 at 12:20, Mark Menzynski wrote:
> - ret = nv50_ir_generate_code(info);
> + /* these fields might be overwritten by the compiler */
> + info_out.bin.smemSize = prog->cp.smem_size;
> + info_out.io.genUserClip = prog->vp.num_ucps;
> +
I suspect that these two sh
Hi Mark,
Above all - welcome to nouveau. Glad to see fresh blood joining.
On Mon, 17 Feb 2020 at 17:41, Mark Menzynski wrote:
>
> Adds shader disk caching for nvc0 to reduce the need to every time compile
> shaders. Shaders are saved into disk_shader_cache from nvc0_screen structure.
>
> It seri
On Fri, 1 Nov 2019 at 14:32, Chris Wilson wrote:
>
> Quoting Eric Engestrom (2019-10-31 14:06:40)
> > On Thursday, 2019-10-31 07:35:04 +, Chris Wilson wrote:
> > > The system can be disabling HW acceleration unbeknowst to the user,
> > > leading to a long debug session trying to work out which
g to work out which component is
> failing. A quick mention that it is the environment override would be
> very useful.
Reviewed-by: Emil Velikov
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
From: Emil Velikov
Earlier commit refactored common code into the loader, yet did not set
the custom logger (one that honours LIBGL_DEBUG).
Thus LIBGL_DEBUG=verbose was working only with DRI3.
Fixes: d971a4230d5 ("loader: Factor out the common driver opening logic from
each loader."
7 Eduardo Lima Mitev
13 Emil Velikov
90 Eric Anholt
169 Eric Engestrom
26 Erico Nunes
89 Erik Faye-Lund
5 Francisco Jerez
38 Gert Wollny
8 Greg V
20 Guido Günther
8 Gurchetan Singh
1 Haihao Xiang
2 Harish Krupo
1 Heinrich Fink
On Sunday, 18 August 2019, Matt Turner wrote:
> On Thu, Aug 8, 2019 at 2:56 AM Emil Velikov
> wrote:
> >
> > On Wed, 7 Aug 2019 at 21:43, Mark Janes wrote:
> > >
> > > Eric Engestrom writes:
> > >
> > > > On 2019-07-31 at 09:38, Emil
On Wed, 7 Aug 2019 at 21:43, Mark Janes wrote:
>
> Eric Engestrom writes:
>
> > On 2019-07-31 at 09:38, Emil Velikov wrote:
> >> Hi all,
> >>
> >> Here is the tentative release plan for 19.2.0.
> >>
> >> As many of you are well awa
Hi all,
On Wed, 31 Jul 2019 at 09:37, Emil Velikov wrote:
>
> Hi all,
>
> Here is the tentative release plan for 19.2.0.
>
> As many of you are well aware, it's time to the next branch point.
> The calendar is already updated, so these are the tentative dates:
>
&g
On Thu, 1 Aug 2019 at 16:03, Emil Velikov wrote:
>
> On Thu, 1 Aug 2019 at 14:26, Michel Dänzer wrote:
> > On 2019-08-01 2:32 p.m., Emil Velikov wrote:
>
> > > Sure I'll do that in a moment.
> >
> > Why don't you just follow my suggestion above?
>
On Thu, 1 Aug 2019 at 14:26, Michel Dänzer wrote:
> On 2019-08-01 2:32 p.m., Emil Velikov wrote:
> > Sure I'll do that in a moment.
>
> Why don't you just follow my suggestion above?
>
That's what I was planning to do :-)
-Emil
___
On Thu, 1 Aug 2019 at 09:35, Michel Dänzer wrote:
>
> On 2019-07-31 11:47 p.m., Eric Engestrom wrote:
> > On Wednesday, 2019-07-31 16:07:45 +0200, Michel Dänzer wrote:
> >> On 2019-07-31 3:26 p.m., Emil Velikov wrote:
> >>> On Wed, 31 Jul 2019 at 14:16, Michel Dän
On Wed, 31 Jul 2019 at 14:16, Michel Dänzer wrote:
>
> On 2019-07-31 3:04 p.m., Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Currently we use the python package to manage repositories. At the same
> > time we also do that by hand - since it's a t
On Fri, 5 Jul 2019 at 22:58, Eric Engestrom wrote:
>
> On Friday, 2019-07-05 11:21:41 +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Currently, if we error out before gbm_dri is set (say due to a different
> > name of the backing GBM implementation, or
From: Emil Velikov
Currently we use the python package to manage repositories. At the same
time we also do that by hand - since it's a trivial echo to a file.
Stay consistent, remove the package and manage things manually.
Cc: Eric Engestrom
Signed-off-by: Emil Velikov
---
.gitlab-ci/d
Hi all,
Here is the tentative release plan for 19.2.0.
As many of you are well aware, it's time to the next branch point.
The calendar is already updated, so these are the tentative dates:
Aug 06 2019 - Feature freeze/Release candidate 1
Aug 13 2019 - Release candidate 2
Aug 20 2019 - Release
0 piglit tests from crash to skip on NV18.
Thanks Ian.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109524
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110955
Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Emil Velikov
-Emil
_
From: Emil Velikov
Currently, if we error out before gbm_dri is set (say due to a different
name of the backing GBM implementation, or otherwise) the tear down will
trigger a NULL ptr deref and crash out.
Move the gbm_dri initialization as early as possible. To be on the extra
safe side add a
On Wed, 3 Jul 2019 at 08:16, Drew DeVault wrote:
>
> Instead of assuming the first will be suitable. kmscube fails to start
> for me without this change.
Yes please. Picking the first one is rarely the correct thing to do.
Especially when we have platform specific attributes which are exempt
from
welcome to feedback. With my mesa hat on:
Acked-by: Emil Velikov
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
xport path
> android: anv: eliminate libmesa_anv_entrypoints
> android: anv: import include path of libmesa_nir
> android: radv: import include paths from used libraries
>
From a quick look the series looks great. For the lot:
Acked-by: Emil Velikov
Mauro, feel free to merge this if you
On 2019/06/28, mathias.froehl...@gmx.net wrote:
> From: Mathias Fröhlich
>
> Hi,
>
> Ilia mentioned that there are drm rendernode only drivers out there.
> To support an egl device on those platforms, make the EGL_EXT_device_drm
> device extension optional.
>
Currently DRM core mandates that pr
From: Emil Velikov
Currently libdrm_amdgpu provides a typedef of the various handles. While
the goal was to make those opaque, it effectively became part of the API
To the best of my knowledge there are two ways to have opaque handles:
- "typedef void *foo;" - rather messy IMHO
-
On Mon, 17 Jun 2019 at 19:16, Ilia Mirkin wrote:
>
> On Mon, Jun 17, 2019 at 6:37 AM wrote:
> >
> > From: Mathias Fröhlich
> >
> >
> > Emil,
> >
> > that one probably matches your original intent then.
> >
> > please review
> > Thanks
> >
> > Mathias
> >
> >
> > Do not offer a hardware drm backe
On 2019/06/06, mathias.froehl...@gmx.net wrote:
> From: Mathias Fröhlich
>
> Align classic swrast with galliums software renderer with respect
> to front buffer creation.
> In case of front buffers swrast uses the __DRI_SWRAST_LOADER extensions
> getImage/putImage callbacks to keep the front buff
pening the drm device and see if there is a usable driver associated
> with the device. The taken approach avoids a full probe and fixes at
> least this kind of problem on kvm virtualization hosts I observe here.
>
Thanks
Fixes: dbb4457d985 ("
On Fri, 7 Jun 2019 at 00:30, Ian Romanick wrote:
>
> From: Ian Romanick
>
> This makes the wrapper work on glibc 2.29 on Fedora 30.
> ---
AFAICT this patch is for shader-db and looks spot on.
Reviewed-by: Emil Velikov
-Emil
___
mesa-d
From: Emil Velikov
The title of the release notes says 19.0.5 while the rest of the file
(correctly) says 19.0.6
Cc: Dylan Baker
Fixes: fe79d75ccf9 ("docs: Add relnotes for 19.0.6")
Signed-off-by: Emil Velikov
---
Aside: Dylan seems like the relnotes were not chery-pick -x hence the
From: Emil Velikov
Earlier commit converted ES1 and ES2 to a new, much simpler, dispatch
generator. At the same time, GL/glapi and the driver side are still
using the old code.
There is a hidden ABI between GL*.so and glapi.so, former referencing
entry-points by offset in the _glapi_table
From: Emil Velikov
As elaborated in the next patch, there is some hidden ABI that
effectively require most entrypoints to be listed in the file.
Cc: Marek Olšák
Fixes: d2906293c43 ("mesa: EXT_dsa add selectorless matrix stackfunctions")
Signed-off-by: Emil Velikov
---
New patch in
From: Emil Velikov
As elaborated in the next patch, there is some hidden ABI that
effectively require most entrypoints to be listed in the file.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110302
Cc: Marek Olšák
Fixes: c5c38e831ee ("mesa: implement ARB/KHR_parallel_shader_co
On Thu, 6 Jun 2019 at 12:10, wrote:
>
> From: Mathias Fröhlich
>
> Do not offer a hardware drm backed egl device if no render node
> is available.
As far as I can see current implementation does _not_ add the DRM
device if its missing render node (and a primary one).
Looking at the change below,
before
> using it.
>
Makes sense. Thanks for following up Marek.
Fwiw the patch is
Reviewed-by: Emil Velikov
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
From: Emil Velikov
As elaborated in the next patch, there is some hidden ABI that
effectively require most entrypoints to be listed in the file.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110302
Cc: Marek Olšák
Fixes: c5c38e831ee ("mesa: implement ARB/KHR_parallel_shader_co
From: Emil Velikov
Earlier commit converted ES1 and ES2 to a new, much simpler, dispatch
generator. At the same time, GL/glapi and the driver side are still
using the old code.
There is a hidden ABI between GL*.so and glapi.so, former referencing
entry-points by offset in the _glapi_table
From: Emil Velikov
Cc: Brian Paul
Cc: Jose Fonseca
Cc: Roland Scheidegger
Signed-off-by: Emil Velikov
---
src/gallium/winsys/svga/drm/vmw_screen_dri.c | 29
1 file changed, 6 insertions(+), 23 deletions(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_dri.c
b
y putting those hand full lines of code into a helper does
> as well not gain much. So I implemented that for the swrast case
> directly.
>
>
For the patch:
Reviewed-by: Emil Velikov
Here is a quick and dirty example. Feel free to follow-up if you like
the idea.
Note: it also
From: Emil Velikov
By default, the user is likely to pick the first device so it should
not be the least performant (aka software) one.
v2: Drop odd comment (Marek)
Suggested-by: Marek Olšák
Reviewed-by: Mathias Fröhlich (v1)
Reviewed-by: Marek Olšák (v1)
Signed-off-by: Emil Velikov
eck
- use the dri2_create_drawable() helper
v5:
- enhance comment around fd checks (Mathias)
- rebase for dri2_init_surface() changes
Cc: Mathias Fröhlich
Acked-by: Marek Olšák (v4)
Signed-off-by: Emil Velikov
---
src/egl/Android.mk | 1 +
src/egl/drivers/dri2/egl_dri2.c
From: Emil Velikov
Wrap the loader->createNewDrawable() dance into a helper and use it
throughout the codebase.
This addresses a cases like surfaceless (SL) on swrast (SL on kms_swrast
is fine) where we'd attempt using the wrong driver and crash out.
v2: fixup quirky GBM (Mathias)
patches
- Use EGLBoolean over int masked as such
- Don't return free'd pointed on calloc failure
Reviewed-by: Mathias Fröhlich
Reviewed-by: Marek Olšák
Signed-off-by: Emil Velikov
---
src/egl/main/eglapi.c | 2 +-
src/egl/main/egldisplay.c | 61 +-
From: Emil Velikov
Reviewed-by: Mathias Fröhlich
Reviewed-by: Marek Olšák
Signed-off-by: Emil Velikov
---
src/egl/main/eglapi.c | 12 +++-
src/egl/main/egldisplay.h | 13 +
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/src/egl/main/eglapi.c b/src/egl
From: Emil Velikov
Since we no longer need special handling for X11, refactor the code to
follow the style used by all other platforms.
Reviewed-by: Mathias Fröhlich
Reviewed-by: Marek Olšák
Signed-off-by: Emil Velikov
---
src/egl/main/egldisplay.c | 45
From: Adam Jackson
The full set of attributes is already handled with previous patches.
Thus all this is not dead code.
v2 (Emil) - split from a larger patch.
Reviewed-by: Mathias Fröhlich
Reviewed-by: Marek Olšák
Signed-off-by: Emil Velikov
---
src/egl/main/egldisplay.c | 13
function only as needed
Reviewed-by: Mathias Fröhlich
Reviewed-by: Marek Olšák
Signed-off-by: Emil Velikov
---
src/egl/drivers/dri2/platform_x11.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/egl/drivers/dri2/platform_x11.c
b/src/egl/drivers/dri2
On Thu, 16 May 2019 at 10:59, Jean Hertel wrote:
>
> On 8th May you Wrote:
> >Hi Emil,
> >
> >>This is the tricky part - wish I could find my notes they have better
> >>brain-dump.
> >>It's OK to have the library as both front (config tool) and backend
> >>(used by mesa) although:
> >> - special c
Hi all,
On Tue, 14 May 2019 at 08:18, Tapani Pälli wrote:
>
>
> On 5/13/19 6:52 PM, Haehnle, Nicolai wrote:
> > This approach seems entirely incompatible with si_debug_options.h, and
> > will be an absolute maintenance nightmare going forward for adding /
> > removing options, because you're intr
On Wed, 15 May 2019 at 08:26, wrote:
>
> From: Mathias Fröhlich
>
> Hi all,
>
> One small fix below.
>
> Please review!
>
> best
>
> Mathias
>
>
>
>
>
> Running swrast with the new device egl extensions piglit test
> brings up this failure. Fix that by adding some NULL pointer
> checks.
>
From a
he stable tag so we get this in the 19.0
and 19.1 series.
Reviewed-by: Emil Velikov
Cc:
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
query
>
> Signed-off-by: Tomeu Vizoso
> ---
Reviewed-by: Emil Velikov
At some point we could consider adding a float version of
u_pipe_screen_get_param_defaults()
HTH
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists
On Thu, 9 May 2019 at 07:35, Tomeu Vizoso wrote:
>
> These tests add too much time to the total run time, and some of them
> even hang the DUTs, even if I haven't been able to reproduce it locally.
>
> Signed-off-by: Tomeu Vizoso
> ---
> src/gallium/drivers/panfrost/ci/deqp-runner.sh | 2 ++
> 1
On Thu, 9 May 2019 at 15:49, Emil Velikov wrote:
>
> On Thu, 9 May 2019 at 07:35, Tomeu Vizoso wrote:
> >
> > NIR_PASS will only set lower_flrp_progress if there's progress, and if
> > there isn't its value will be undefined.
> >
> > Fixes this Val
ed int, void const*) (in
> /home/tomeu/deqp-build/modules/gles2/deqp-gles2)
>
> Signed-off-by: Tomeu Vizoso
There is no clear commit for "fixes" - so I'd add a stable tag here.
CC: 19.1
Reviewed-by: Emil Velikov
HTH
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
es const&) (in
> /home/tomeu/deqp-build/modules/gles2/deqp-gles2)
>
> Signed-off-by: Tomeu Vizoso
> Fixes: d41cdef2a591 ("nir: Use the flrp lowering pass instead of
> nir_opt_algebraic")
> Cc: Ian Romanick
Reviewed-by: Emil Velikov
Thanks
Em
On Thu, 9 May 2019 at 07:35, Tomeu Vizoso wrote:
>
> Valgrind was complaining of those.
>
> NIR_PASS only sets progress to TRUE if there was progress.
>
> nir_const_load_to_arr() only sets as many constants as components has
> the instruction.
>
> This was causing some dEQP tests to flip-flop, suc
:)
> >
Ahem, totally meant to do that :-)
> > > On Mon, May 06, 2019 at 04:32:38PM +0100, Emil Velikov wrote:
> > > > Alyssa this should resolve the failure with minimal churn. Please let
> > > > me know if it works on your end or no
On Tue, 7 May 2019 at 09:27, Michel Dänzer wrote:
>
> On 2019-05-07 5:55 a.m., Timothy Arceri wrote:
> > This reverts commit e91ee763c378d03883eb88cf0eadd8aa916f7878.
> >
> > This seems to have broken a number of wine games.
> >
> > Cc: Adam Jackson
> > Cc: Ian Romanick
> > Cc: Hal Gentz
> > Bu
On Fri, 19 Apr 2019 at 16:36, Hota, Alok wrote:
>
> Just wanted to give a quick update on this. We have agreed on moving forward
> with this patch.
> I'm working on it now to get it through our CI and run some basic tests. I'll
> keep you updated.
> Thanks again for the patch, Emil!
>
Thanks Alo
On Sun, 28 Apr 2019 at 19:38, Jean Hertel wrote:
>
> >Could not find my original notes, but the idea is roughly as follows:
> >- introduce a separate (user only?) library - say libmesa-config.so
> > - ^^ provides an API to query/set attributes, via numerical tokens
> > - any localisation is built
From: Emil Velikov
The X11 specific code uses libdrm, yet we are missing the dependency.
This has gone unnoticed since all drivers which use VL already mandate
the library.
Note: this is applicable only for the stable branches.
Cc: Alyssa Rosenzweig
Cc:
Signed-off-by: Emil Velikov
On Sat, 4 May 2019 at 04:18, Marek Olšák wrote:
>
> On Fri, May 3, 2019 at 1:58 AM Mathias Fröhlich
> wrote:
>>
>> Good Morning,
>>
>> On Wednesday, 1 May 2019 21:43:08 CEST Marek Olšák wrote:
>> > BTW, swrast doesn't have to exist on the system. It's not uncommon for me
>> > to have no swrast o
From: Emil Velikov
Wrap the loader->createNewDrawable() dance into a helper and use it
throughout the codebase.
This addresses a cases like surfaceless (SL) on swrast (SL on kms_swrast
is fine) where we'd attempt using the wrong driver and crash out.
Cc: mesa-sta...@lists.freedes
eck
- use the dri2_create_drawable() helper
Cc: Mathias Fröhlich
Cc: Marek Olšák
Signed-off-by: Emil Velikov
---
src/egl/Android.mk | 1 +
src/egl/drivers/dri2/egl_dri2.c| 3 +
src/egl/drivers/dri2/egl_dri2.h| 13 +-
src/egl/drivers/dri2/platform_device.c | 432
From: Emil Velikov
By default, the user is likely to pick the first device so it should
not be the least performant (aka software) one.
Suggested-by: Marek Olšák
Signed-off-by: Emil Velikov
---
src/egl/main/egldevice.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion
For some extreme corner-cases where you'd want to do it.
---
src/egl/main/egldevice.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/egl/main/egldevice.c b/src/egl/main/egldevice.c
index 3e8c0e5aeb5..4a3127d7d62 100644
--- a/src/egl/main/egldevice.c
+++ b/src/egl/mai
function only as needed
Signed-off-by: Emil Velikov
---
src/egl/drivers/dri2/platform_x11.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/egl/drivers/dri2/platform_x11.c
b/src/egl/drivers/dri2/platform_x11.c
index c8c676d2f00..ba0379c1177 100644
--- a/src
From: Adam Jackson
The full set of attributes is already handled with previous patches.
Thus all this is not dead code.
v2 (Emil) - split from a larger patch.
Signed-off-by: Emil Velikov
---
src/egl/main/egldisplay.c | 13 -
src/egl/main/egldisplay.h | 1 -
2 files changed, 4
From: Emil Velikov
Since we no longer need special handling for X11, refactor the code to
follow the style used by all other platforms.
Signed-off-by: Emil Velikov
---
src/egl/main/egldisplay.c | 45 ++-
1 file changed, 11 insertions(+), 34 deletions
patches
- Use EGLBoolean over int masked as such
- Don't return free'd pointed on calloc failure
Signed-off-by: Emil Velikov
---
src/egl/main/eglapi.c | 2 +-
src/egl/main/egldisplay.c | 61 +--
src/egl/main/egldisplay.h | 3 +-
3 files c
Fröhlich
Cc: Marek Olšák
[1] https://patchwork.freedesktop.org/series/60018/
Adam Jackson (3):
egl: handle the full attrib list in display::options
egl/x11: pick the user requested screen
egl: remove Options::Platform handling
Emil Velikov (6):
egl: flesh out a _eglNumAttribs() helper
From: Emil Velikov
Signed-off-by: Emil Velikov
---
src/egl/main/eglapi.c | 12 +++-
src/egl/main/egldisplay.h | 13 +
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 588c6a5f1eb..4481eb9cd0f 100644
On Mon, 29 Apr 2019 at 22:50, Marek Olšák wrote:
>
> On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen wrote:
>>
>> On Sat, 27 Apr 2019 09:38:27 -0400
>> Marek Olšák wrote:
>>
>> > Those are all valid reasons, but I don't wanna expose swrast for AMD's
>> > customers.
>>
>> Hi Marek,
>>
>> is you ob
From: Emil Velikov
To avoid pulling the latest libdrm we copy the helper locally. Document
when it was introduced, making it easier to purge in the future.
Cc: Eric Engestrom
Suggested-by: Eric Engestrom
Signed-off-by: Emil Velikov
---
Thanks for the suggestion Eric.
---
src/vulkan/wsi
On Fri, 26 Apr 2019 at 08:13, Rain_Kuper wrote:
>
> Hello,does Mesa 3D have support for NVIDIA Tegra K1 SoC and Android?
>
Tegra K1 should work with the nouveau kernel and mesa drivers. Android
is also amongst the platforms where Mesa runs.
IIRC since Android makes heavy use of MT, you might need
things might still break horribly there.
>
> Rbs welcome,
>
Thanks for sorting these our Marek.
With Mathias' comment addressed the series is:
Reviewed-by: Emil Velikov
Can I ask you to run these against the QT test suite - it did
high-light a large number of issues in the past.
Pleas
On Thu, 25 Apr 2019 at 11:44, Bas Nieuwenhuizen
wrote:
>
> r-b
>
Thank you Bas. Pushed both fixes to master.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, 25 Apr 2019 at 19:24, Gustaw Smolarczyk wrote:
>
> czw., 25 kwi 2019 o 20:11 Gustaw Smolarczyk napisał(a):
> >
> > czw., 25 kwi 2019 o 19:42 Emil Velikov
> > napisał(a):
> > >
> > > The function is analogous to lp_fence_wait() while taking at t
Currently if the timeout differs from 0, we'll end up with infinite
wait... even if the user is perfectly clear they don't want that.
Use the new lp_fence_timedwait() helper guarding both waits in an
!lp_fence_signalled block like the rest of llvmpipe.
Signed-off-by: Emil Velikov
R
The function is analogous to lp_fence_wait() while taking at timeout
(ns) parameter, as needed for EGL fence/sync.
v2:
- use absolute UTC time, as per spec (Gustaw)
- bail out on cnd_timedwait() failure (Gustaw)
Cc: Gustaw Smolarczyk
Cc: Roland Scheidegger
Signed-off-by: Emil Velikov
From: Tomasz Figa
If there is no last fence, due to no rendering happening yet, just
create a new signaled fence and return it, to match the expectations of
the EGL sync fence API.
Fixes random "Could not create sync fence 0x3003" assertion failures from
Skia on Android, coming from the followin
On Tue, 16 Apr 2019 at 11:50, Gustaw Smolarczyk wrote:
>
> wt., 16 kwi 2019 o 12:11 Emil Velikov napisał(a):
> >
> > On Thu, 11 Apr 2019 at 17:55, Gustaw Smolarczyk
> > wrote:
> > >
> > > czw., 11 kwi 2019 o 18:06 Emil Velikov
> > > napis
On Fri, 19 Apr 2019 at 16:01, Emil Velikov wrote:
>
> From: Emil Velikov
>
> As effectively required by the extension, we need to ensure we're master
>
> Currently drivers employ vendor specific solutions, which check if the
> device behind the fd is capable*, yet
On Fri, 19 Apr 2019 at 16:03, Emil Velikov wrote:
>
> From: Emil Velikov
>
> Currently we get normal GEM handles from PrimeFDToHandle, yet we close
> then with DUMB_CLOSE. Use GEM_CLOSE instead.
>
> Cc: Keith Packard
> Cc: Jason Ekstrand
> Cc: Bas Nieuwenhuizen
&g
On Wed, 24 Apr 2019 at 13:09, Emil Velikov wrote:
>
> On Tue, 23 Apr 2019 at 23:10, Alyssa Ross wrote:
> >
> > > Off the top of my head - none of the VL code should be build when we
> > > have only a swrast driver.
> > > Can you try and kill that bug, o
On Tue, 23 Apr 2019 at 23:10, Alyssa Ross wrote:
>
> > Off the top of my head - none of the VL code should be build when we
> > have only a swrast driver.
> > Can you try and kill that bug, or shall I?
>
> Isn't that what this patch does?
>
> If there's only swrast, this patch prevents enabling an
On Fri, 19 Apr 2019 at 19:53, Alyssa Ross wrote:
>
> The meson build system already has these checks. I've just copied them
> to autotools.
>
> Without this, state trackers could be enabled when building with the
> following set of options, which resulted in a compile error due to VL
> being built
From: Emil Velikov
Currently we get normal GEM handles from PrimeFDToHandle, yet we close
then with DUMB_CLOSE. Use GEM_CLOSE instead.
Cc: Keith Packard
Cc: Jason Ekstrand
Cc: Bas Nieuwenhuizen
Fixes: da997ebec92 ("vulkan: Add KHR_display extension using DRM [v10]")
Signed-of
From: Emil Velikov
The fd is -1, thus the block of if (fd != -1) close(fd) is dead code.
Cc: Chad Versace
Cc: Chia-I Wu
Signed-off-by: Emil Velikov
---
src/freedreno/vulkan/tu_device.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/freedreno/vulkan/tu_device.c b/src/freedreno
From: Emil Velikov
As effectively required by the extension, we need to ensure we're master
Currently drivers employ vendor specific solutions, which check if the
device behind the fd is capable*, yet none of them do the master check.
*In the radv case, if acceleration is available.
In
Hi Adam,
On Wed, 17 Apr 2019 at 19:57, Adam Jackson wrote:
>
> 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
On Wed, 17 Apr 2019 at 19:25, Bas Nieuwenhuizen
wrote:
>
> This will not work as-is for radv, as failure to initialize from
> wsi_display_init_wsi (->wsi_device_init -> radv_init_wsi) will cause
> us to fail initializing the whole device.
>
Indeed - same applies across the board.
I'll send out v
From: Emil Velikov
As effectively required by the extension, we need to ensure we're master
Currently drivers employ vendor specific solutions, which check if the
device behind the fd is capable*, yet none of them do the master check.
*In the radv case, if acceleration is available.
In
On Thu, 11 Apr 2019 at 17:55, Gustaw Smolarczyk wrote:
>
> czw., 11 kwi 2019 o 18:06 Emil Velikov napisał(a):
> >
> > The function is analogous to lp_fence_wait() while taking at timeout
> > (ns) parameter, as needed for EGL fence/sync.
> >
> > Cc: Roland
The function is analogous to lp_fence_wait() while taking at timeout
(ns) parameter, as needed for EGL fence/sync.
Cc: Roland Scheidegger
Signed-off-by: Emil Velikov
---
src/gallium/drivers/llvmpipe/lp_fence.c | 22 ++
src/gallium/drivers/llvmpipe/lp_fence.h | 3 +++
2
From: Tomasz Figa
If there is no last fence, due to no rendering happening yet, just
create a new signaled fence and return it, to match the expectations of
the EGL sync fence API.
Fixes random "Could not create sync fence 0x3003" assertion failures from
Skia on Android, coming from the followin
Currently if the timeout differs from 0, we'll end up with infinite
wait... even if the user is perfectly clear they don't want that.
Use the new lp_fence_timedwait() helper guarding both waits in an
!lp_fence_signalled block like the rest of llvmpipe.
Cc: Roland Scheidegger
Signed-of
On Thu, 4 Apr 2019 at 18:05, Adam Jackson wrote:
>
> 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
1 - 100 of 8584 matches
Mail list logo
