well.
One important note: do _not_ use LIBGL_ALWAYS_SOFTWARE=1 when trying
to use EGL devices. It may or may not work and is not something we
want to support if we can avoid it.
HTH
-Emil
d you forget to push
those or is something broken on my end?
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
truct x11_swapchain
> *chain,
>
> case XCB_PRESENT_EVENT_COMPLETE_NOTIFY: {
>xcb_present_complete_notify_event_t *complete = (void *) event;
> - if (complete->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP)
> + if (complete->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP) {
> + uint64_t frames = complete->msc - chain->last_present_msc;
> + uint64_t present_nsec = complete->ust * 1000;
> +
> + /*
> + * Well, this is about as good as we can do -- measure the refresh
> + * instead of asking for the current mode and using that. Turns out,
> + * for eDP panels, this works better anyways as they use the builtin
> + * fixed mode for everything
> + */
What is wrong with checking the current mode and using the data? Let's
document that reasoning.
Apart from the initial 60Hz, the refresh period returned will vary
during the initial 10 frames. Are we confident that either of those
assumptions won't back-fire with applications?
> @@ -1480,6 +1543,8 @@ x11_surface_create_swapchain(VkIcdSurfaceBase
> *icd_surface,
> + chain->threaded = false;
Unrelated, yet again it's missing all together in master.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
;NOUVEAU_ERR("shader translation failed: %i\n", ret);
>goto out;
> }
>
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
mSize = prog->cp.smem_size;
> + info->io.genUserClip = prog->vp.num_ucps;
> +
> + blob_init(&blob);
> + nv50_ir_prog_info_serialize(&blob, info);
> +
> + if (disk_shader_cache) {
Will this work correctly, if the cache is explicitly disabled?
It's been year
; set EGL_LOG_LEVEL.
> >
> > I think most users don't want to disable their hardware, so the annoyance
> > if this warning showing up for users who want it should be completely
> > offset by the usefulness of this information for those who don't.
>
> Is t
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."
one here
- GL4.6 is a worthy addition :-)
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
ou have noticed I've rolled our RC1 just after your email went out.
From a quick look we are talking about 20 or so patches. I'm fine with
cherry-picking the work for RC2 if we get a couple of acks.
We had the odd exception in the past, I see no reason why we cannot do one here
GL4.6 is a wo
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
Depends on" for each work you have planned.
Alternatively you can reply to this email and I'll add them for you.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=111265
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://l
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
gbm->dev, NULL);
> } else {
> egl->display = eglGetDisplay((void *)gbm->dev);
> @@ -106,8 +143,9 @@ int init_egl(struct egl *egl, const struct gbm *gbm)
> return -1;
> }
>
&g
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
ving a pretty reasonable assumption, that's why I did
before digging deeper, as opposed to saying there _are_ such cases.
HTH
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
> &
_FALSE);
> _mesa_attach_and_own_rb(fb, BUFFER_FRONT_LEFT, &frontrb->Base.Base);
>
Doubt I'll be able to look at the classic swrast, anytime soon. Sorry :-\
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 2019/06/17, mathias.froehl...@gmx.net wrote:
> From: Mathias Fröhlich
>
>
> Emil,
>
> that one probably matches your original intent then.
>
> please review
> Thanks
>
> Mathias
>
>
> Do not offer a hardware drm backed egl device if
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
he change below, it's effectively making the primary node optional.
Hence the comment does not alight with the code - old and new. Can you
elaborate?
I have not thought exactly how primary node-less DRM will work out
esp. since the EGL_EXT_device_drm extension explicitly
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
On 2019/05/27, mathias.froehl...@gmx.net wrote:
> From: Mathias Fröhlich
>
> Hi Emil,
>
> thanks for that hint to look at _mesa_get_incomplete_framebuffer.
> That one seems definitely more appropriate!
>
> Though, I miss a bit the idea how I can create either a sensib
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)
From: Adam Jackson
Earlier spec is vague, although EGL 1.5 makes it clear:
Multiple calls made to eglGetPlatformDisplay with the same
parameters will return the same EGLDisplay handle.
With this commit we store and compare the full attrib list.
v2 (Emil):
- Split into separate
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
From: Adam Jackson
At the moment the user will pass the screen number via attribs, yet we
would throw that away. Reason being that the int *screen passed to
xcb_connect() is output only.
v2 (Emil):
- split from a larger patch
- use xcb_connect() returned screen, as fallback
- use helper
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 b
c ones, yet neither(?) of these apps is
present on Android
- libexpat is not available, but libFOO is - investigate into a compat wrapper
- cannot use external libraries (libexpat or equivalent) - static link
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
out some helper and fixing the drivers instead?
Note !intel classic drivers may also struggle with (draw xor read)
surfaces. It could be handled in the upper layers (dri/common or DRI
loaders - GLX/EGL/GBM) but haven't checked.
Thanks
Emil
___
mesa-dev
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
ES2.functional.fbo.render.depth./d' /tmp/case-list.txt
>
Pretty sure you or Alyssa will get to fixing these.
Wondering if one cannot use a trivial visual reminder about these.
Say printing some FIXME + tests in the logs. Or using an amber
indication on successful pipeline - a green one when the
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
ome dEQP tests to flip-flop, such as:
>
> dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.add_src_color_constant_color
>
Please add a Fixes tag or a cc: mesa-stable@ one at least. This way
we'll pick this fix for stable.
-Emil
_
:)
> >
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
will re-introduce
> https://bugs.freedesktop.org/show_bug.cgi?id=99781 . That one was about
> __glXSendErrorForXcb, while the regressions are about __glXSendError, so
> maybe only revert the __glXSendError hunk for now?
>
Could not agree more.
Can I suggest adding inline comment + even a bugzilla link? Otherwise
we're bound to copy/paste and break it again.
HTH
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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 f
sily
> > - translation lives outside of the driver - the driver doesn't care
> >about it, so don't bloat
> > - translators do not need access to mesa - one less hurdle/obstacle
> >
> >
> >Hope it makes sense, not sure if coffee has kicked in fully ;-)
>
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
> drivers - to catch bad interactions with those.
>>
>> Anyhow, with a very old swrast I think you will get test failures.
>> But else if the system swrast is found in the hopefully not so distant future
>> the tests should even pass - well depends on what Emil now doe
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
From: Adam Jackson
At the moment the user will pass the screen number via attribs, yet we
would throw that away. Reason being that the int *screen passed to
xcb_connect() is output only.
v2 (Emil):
- split from a larger patch
- use xcb_connect() returned screen, as fallback
- use helper
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
From: Adam Jackson
Earlier spec is vague, although EGL 1.5 makes it clear:
Multiple calls made to eglGetPlatformDisplay with the same
parameters will return the same EGLDisplay handle.
With this commit we store and compare the full attrib list.
v2 (Emil):
- Split into separate
the last device
- get platform_device + swrast working - architecturally hacky, but will do
for now
- HACK: POC drop the software devices from QueryDevices
Meant for Marek, if their stack does not build/ship swrast_dri.so
Review and comments are appreciated :-)
Thanks
Emil
Cc: Mathias
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
k
- flip the order so SW is always the last one in the list
- add a hack that disables SW all-together?
The first two should be OK to upstream, although I'd suggest keeping
the last one in AMDGPU-PRO.
Reason being is that the pro packaging can enforce that radeonsi is
always present. While we cannot do that for distributions :-\
/me starts working on the patches
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
ight need to
rebase/apply these [1] nouveau patches.
That said, best thing is to try if yourself - yet YMMV.
I would start with Android-x86.
HTH
Emil
[1] https://patchwork.freedesktop.org/series/53595/
Note: there might be a newer revision, haven&
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
s only swrast, this patch prevents enabling any of the state
> trackers, so need_gallium_vl won't be set, and VL won't be built.
How about instead of tracking each driver and combination do somethings like:
if no_gallium_drivers or galliu
ess the above use-case, we don't need to reinstate the tracking
- it causes a lot of churn.
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?
-Emil
___
mesa-dev
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
e corner-cases
4. update platform_x11.c to honour the attribs
5. Kill off Options::Platform - _eglParseX11DisplayAttribList and elsewhere.
6. Optional: move _eglParseX11DisplayAttribList validation before the
_eglFindDisplay() ... just like all !X11 platforms do.
Nit: Make _eglSameAttribs retur
board.
I'll send out v2 tomorrow - after testing it on ANV and RADV.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
1 - 100 of 8586 matches
Mail list logo
