eap debug code for these builds.
> > I only chose those occurences that I care about.
> >
> > Reviewed-by: Mathias Fröhlich
> >
> > src/gallium/auxiliary/tgsi/tgsi_ureg.c | 2 +-
> > src/gallium/drivers/radeonsi/si_descri
Emil,
Ok, I thought Ilja is a reference here. In this case forget that change!
Thanks!
best
Mathias
On Friday, 28 June 2019 18:26:07 CEST Emil Velikov wrote:
> On 2019/06/28, mathias.froehl...@gmx.net wrote:
> > From: Mathias Fröhlich
> >
> > Hi,
> >
> >
On Monday, 17 June 2019 19:33:26 CEST Emil Velikov wrote:
> On 2019/06/17, mathias.froehl...@gmx.net wrote:
> > From: Mathias Fröhlich
> >
> >
> > Emil,
> >
> > that one probably matches your original intent then.
> >
> > please review
>
Hi Emil,
On Monday, 17 June 2019 19:35:10 CEST Emil Velikov wrote:
> 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
On Monday, 10 June 2019 12:11:40 CEST Mathias Fröhlich wrote:
> Hi Emil,
>
> On Friday, 7 June 2019 15:43:48 CEST Emil Velikov wrote:
> > On Thu, 6 Jun 2019 at 12:10, wrote:
> > >
> > > From: Mathias Fröhlich
> > >
> > > Do not offer a hardwa
Hi Emil,
On Friday, 7 June 2019 15:43:48 CEST Emil Velikov wrote:
> 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 i
Kenneth,
> Ouch. Thanks for letting me know. Fixed by:
>
> commit 53878f7a8989879b0f3ca37df9fd1fb37f2525ca
> Author: Kenneth Graunke
> Date: Wed May 29 23:20:31 2019 -0700
>
> iris: Be lazy about cleaning up purged BOs in the cache.
>
Thanks for fixing! Works again!
best
Mathias
___
Hi Kenneth,
since your recent changes, I get a zero pointer dereference in
alloc_bo_from_cache on one workload here:
What I get is
Thread 2 "" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffef776700 (LWP 20924)]
list_del (item=0x7fffe8ae4020) at ../src/util/list.h:91
91
Pushed that.
Thanks!
best
Mathias
On Monday, 27 May 2019 17:34:29 CEST Marek Olšák wrote:
> Reviewed-by: Marek Olšák
>
> M.
>
> On Mon, May 27, 2019, 4:17 AM wrote:
>
> > From: Mathias Fröhlich
> >
> > Hi Emil,
> >
> > thanks for that
Marek,
sure, for that part:
Reviewed-by: Mathias Fröhlich
Well, there are really magnitudes of DEBUG defines that are inactive since
meson.
Either let meson builds also define DEBUG or lets
sed -i 's,#ifdef DEBUG,#ifndef NDEBUG,g'
them now?
best
Mathias
On Friday, 10 May 201
ta...@lists.freedesktop.org
> Cc: Mathias Fröhlich
> Reviewed-by: Mathias Fröhlich (v1)
> Reviewed-by: Marek Olšák (v1)
> Signed-off-by: Emil Velikov
> ---
> src/egl/drivers/dri2/egl_dri2.c | 39 +
> src/egl/drivers/dri2/egl_dri2.h
Hi Marek,
> Reviewed-by: Marek Olšák
Thanks for the review!
Pushed!
best
Mathias
>
> Marek
>
> On Sun, May 12, 2019 at 9:05 AM wrote:
>
> > From: Mathias Fröhlich
> >
> > Signed-off-by: Mathias Fröhlich
> > ---
> > src/mesa/main/s
Hi Emil,
The patches 1-7 are as well:
Reviewed-by: Mathias Fröhlich
plenty thanks and best
Mathias
On Monday, 6 May 2019 17:01:30 CEST Emil Velikov wrote:
> From: Emil Velikov
>
> By default, the user is likely to pick the first device so it should
> not be the least per
Hi Brian,
On Friday, 3 May 2019 14:40:26 CEST Brian Paul wrote:
> All your suggested changes look good.
>
> Reviewed-by: Brian Paul
>
> Thanks.
Pushed Thanks!
best
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freede
cluding oss i965 and the closed nvidia
bumblebee device - on my laptop for example.
Means - if that works fine AMD could hook into that mechanism and
provide further devices. Well - in the long term.
Thinking ...
best
Mathias
>
> Marek
>
> On Wed, May 1, 2019 at 4:30 AM Mathias
Hi Brian,
On Friday, 3 May 2019 00:17:51 CEST Brian Paul wrote:
> On 05/02/2019 03:27 AM, mathias.froehl...@gmx.net wrote:
> > From: Mathias Fröhlich
> >
> > In glArrayElement, use the bitmask trick to just walk the enabled
> > vao arrays. This should be about equi
On Friday, 3 May 2019 00:17:45 CEST Brian Paul wrote:
> On 05/02/2019 03:27 AM, mathias.froehl...@gmx.net wrote:
> > From: Mathias Fröhlich
> >
> > In the glArrayElement implementation, use glVertexAttrib*NV type
> > functions for fixed function attributes
Good Morning,
On Friday, 3 May 2019 00:17:38 CEST Brian Paul wrote:
> On 05/02/2019 03:27 AM, mathias.froehl...@gmx.net wrote:
> > From: Mathias Fröhlich
> >
> > For access to glArrayElement methods factor out a function to
> > get the table lookup index for norma
M, "%s(invalid buffer %s)",
> caller, _mesa_enum_to_string(buffers[output]));
> return;
If we finally go that route by this series then this patch looks good to me.
Lets see if we need a better overall fix for pbuffers.
best
Mathias
>
> Mar
Hi Marek, Emil,
On Tuesday, 30 April 2019 15:36:08 CEST Emil Velikov wrote:
> 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 reaso
Adam, Marek,
On Monday, 29 April 2019 18:28:21 CEST Adam Jackson wrote:
> 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
Hi Marek,
one comment/failure inline:
On Saturday, 27 April 2019 05:31:45 CEST Marek Olšák wrote:
> From: Marek Olšák
>
> It's needed by the next pbuffer fix, which changes the behavior of
> draw_buffer_enum_to_bitmask, so it can't be used to help with error
> checking.
> ---
> src/mesa/main/b
Hi Marek,
On Wednesday, 24 April 2019 02:01:42 CEST Marek Olšák wrote:
> Adam, did you notice my original suggestion "If there is at least 1 drm
> device, swrast won't be in the list."? which means swrast would be in the
> list for your "dumb" GPUs.
Imagine a box with a low end drm capable hardwa
Hi,
On Tuesday, 23 April 2019 22:23:45 CEST Marek Olšák wrote:
> On Tue, Apr 23, 2019 at 4:05 PM Mathias Fröhlich
> wrote:
>
> > Hi Marek,
> >
> > On Tuesday, 23 April 2019 20:22:15 CEST Marek Olšák wrote:
> > > I'd like to remove swrast from devices. I
Apr 17, 2019 at 12:38 AM Mathias Fröhlich
> wrote:
>
> >
> > Hi,
> >
> > On Tuesday, 16 April 2019 17:50:33 CEST Marek Olšák wrote:
> > > On Wed, Apr 10, 2019 at 5:37 AM Mathias Fröhlich <
> > mathias.froehl...@gmx.net>
> > > wrote:
&g
Hi,
On Tuesday, 16 April 2019 17:50:33 CEST Marek Olšák wrote:
> On Wed, Apr 10, 2019 at 5:37 AM Mathias Fröhlich
> wrote:
>
> > Hi Emil,
> >
> > On Monday, 8 April 2019 12:28:55 CEST Emil Velikov wrote:
> > > > Now that I have been putting together
Hi Emil,
On Monday, 8 April 2019 12:28:55 CEST Emil Velikov wrote:
> > Now that I have been putting together a test case for the the actual use
> > I do see some issues with the pbuffer code path. Well - still investigating
> > if the test is wrong or the result.
> >
> Actually I do recall some is
eanups
> - close and free when destroying the dpy
> - sprinkle a few _eglDeviceSupports
> - split fd handling into separate function
> - use directly the render node if no FD is given (Mathias)
>
> Cc: Mathias Fröhlich
> Cc: Marek Olšák
> Signed-off-by: Emil Velikov
Good morning,
On Wednesday, 3 April 2019 16:51:03 CEST Marek Olšák wrote:
> On Wed, Apr 3, 2019 at 10:13 AM Mathias Fröhlich
> wrote:
>
> > > What is missing for merging this?
> >
> > I saw the pbuffer swrast crash and proposed to disable them via the
> > 3r
;
> Thanks,
> Marek
>
> On Wed, Apr 3, 2019 at 12:30 AM Mathias Fröhlich
> wrote:
>
> > Marek,
> >
> > On Tuesday, 2 April 2019 23:07:50 CEST Marek Olšák wrote:
> > > Do you have a branch with patch 7/8 and 8/8? I'm interested in
> > > EGL_E
3, 2018 at 4:36 AM Mathias Fröhlich
> wrote:
>
> > Hi Emil,
> >
> > Ok, thanks for picking that up.
> >
> > On Tuesday, 2 October 2018 12:23:30 CEST Emil Velikov wrote:
> > > On Thu, 20 Sep 2018 at 15:13, Mathias Fröhlich
> > > wrote:
> > >
Hi Brian,
On Thursday, 14 March 2019 15:04:28 CET Brian Paul wrote:
> > Ok, so basically you are saying that you improve the current situation with
> > this
> > current series, still leaving a race condition open. But a good final fix
> > to the race
> > condition is underway.
>
> Yeah, I can p
Hi Brian,
the full package looks great and makes a lot of sense!
Reviewed-by: Mathias Fröhlich
best
Mathias
On Thursday, 14 March 2019 20:37:09 CET Brian Paul wrote:
> When st_texture_release_all_sampler_views() is called the texture may
> have sampler views belonging to several co
Hi Brian,
On Thursday, 14 March 2019 14:55:11 CET Brian Paul wrote:
> yeah, looks good. Thanks.
>
> Reviewed-by: Brian Paul
>
> I don't remember- do you need me to push your patches for you?
Thanks for the review!
I have rights to push.
Thanks for asking!!
best
Mathias
__
accept that.
> >
> > Could that solve our problem??
> >
> > best
> > Mathias
> >
> >
> > >
> > > Marek
> > >
> > > On Tue, Mar 12, 2019, 1:59 AM Marc-André Lureau
> > >
> > > wrote:
> > >
> &g
Hi Brian,
On Sunday, 10 March 2019 21:32:39 CET Brian Paul wrote:
> > On Friday, 8 March 2019 23:52:09 CET Brian Paul wrote:
> > > After a while of running google-chrome and viewing Bing maps, we'd see
> > > "context mismatch in svga_sampler_view_destroy()" messages and
> > > eventually crash beca
rek
>
> On Tue, Mar 12, 2019, 1:59 AM Marc-André Lureau
> wrote:
>
> > Hi
> >
> > On Fri, Mar 1, 2019 at 12:13 PM Mathias Fröhlich
> > wrote:
> > >
> > > On Friday, 1 March 2019 12:15:08 CET Eero Tamminen wrote:
> > > > Hi,
> &g
Hi,
On Tuesday, 12 March 2019 09:59:17 CET Marc-André Lureau wrote:
> Hi
>
> On Fri, Mar 1, 2019 at 12:13 PM Mathias Fröhlich
> wrote:
> >
> > On Friday, 1 March 2019 12:15:08 CET Eero Tamminen wrote:
> > > Hi,
> > >
> > > On 1.3.2019 11.12,
Brian,
One question also for my own education inline below:
On Friday, 8 March 2019 23:52:09 CET Brian Paul wrote:
> After a while of running google-chrome and viewing Bing maps, we'd see
> "context mismatch in svga_sampler_view_destroy()" messages and
> eventually crash because we leaked too man
Hi Brian,
Both of these fixes:
Reviewed-by: Mathias Fröhlich
best
Mathias
On Friday, 8 March 2019 23:53:32 CET Brian Paul wrote:
> Fixes:
> ../src/gallium/winsys/sw/dri/dri_sw_winsys.c: In function
> ‘dri_sw_displaytarget_display’:
> ../src/gallium/winsys/sw/dri/dri_sw_win
Hi Brian,
For both, if you need:
Reviewed-by: Mathias Fröhlich
best
Mathias
On Monday, 4 March 2019 18:20:57 CET Brian Paul wrote:
> MinGW release builds warns about use of a possbily uninitialized
> variable here.
> ---
> src/gallium/drivers/svga/svga_pipe_rasterizer.c | 2
Hi,
On Friday, 1 March 2019 16:50:13 CET Brian Paul wrote:
> The series looks OK to me.
>
> Reviewed-by: Brian Paul
Thanks!
Pushed!
Mathias
>
> On 02/28/2019 11:18 PM, mathias.froehl...@gmx.net wrote:
> > From: Mathias Fröhlich
> >
> > Now that the buffer
On Friday, 1 March 2019 12:15:08 CET Eero Tamminen wrote:
> Hi,
>
> On 1.3.2019 11.12, Michel Dänzer wrote:
> > On 2019-02-28 8:41 p.m., Marek Olšák wrote:
> >>> On Thu, Feb 28, 2019 at 1:37 PM Eero Tamminen
> Why distro versions of Qemu filter sched_setaffinity() syscall?
> >>>
> >>> (https
Hi,
Thanks, Brian and Marek for the review!
best
Mathias
On Monday, 25 February 2019 22:44:37 CET Marek Olšák wrote:
> Reviewed-by: Marek Olšák
>
> Marek
>
> On Sun, Feb 24, 2019 at 1:46 AM wrote:
>
> > From: Mathias Fröhlich
> >
> > Hi Brian,
> >
Emil,
indeed this is easier to read.
For patch #1 and #2 you get
Reviewed-by: Mathias Fröhlich
For patch #3, I don't know vgem good enough to judge the big picture.
The change within mesa itself looks technically correct.
best
Mathias
On Tuesday, 5 February 2019 16:31:06 CET Emil Ve
Hi,
On Saturday, 29 December 2018 17:05:16 CET Ilia Mirkin wrote:
> On Sat, Dec 29, 2018 at 6:17 AM Mathias Fröhlich
> wrote:
> > In Emils patches building on top, _eglGetDRMDeviceRenderNode is only called
> > from
> > code paths guarded with HAVE_LIBDRM.
>
>
Hi all,
given what I see in Emils patches and in the assumption that this helps already
for haiku.
For both:
Reviewed-by: Mathias Fröhlich
best
Mathias
On Thursday, 27 December 2018 21:41:46 CET Alexander von Gluck IV wrote:
> ---
> src/egl/main/egldevice.c | 6 +-
> 1 file c
Good morning,
On Thursday, 27 December 2018 21:59:47 CET Ilia Mirkin wrote:
> I don't see this function used anywhere... it's not exported either.
>
> It was added in dbb4457d9858fa977246aa5e9cabe83455022dfe by Emil as
> part of EGL_EXT_device_drm, but appears unused in that commit as well.
>
>
Hi,
On Thursday, 13 December 2018 17:40:49 CET Jason Ekstrand wrote:
> On Thu, Dec 13, 2018 at 9:56 AM Ilia Mirkin wrote:
>
> > On Thu, Dec 13, 2018 at 10:52 AM Alex Deucher
> > wrote:
> > >
> > > On Wed, Dec 12, 2018 at 3:42 AM Samuel Pitoiset
> > > wrote:
> > > >
> > > > Personally, I will c
Good Morning,
> > One thing, may be. Do you want to add some documentation beside the
> > git log message why we do something surprising like replicating out
> > the
> > buffers and assigning new buffer indices? Just something that allows
> > a reader to get an idea why non straight forward things
nd to vanish
over time behind further changes in the code.
> I suppose this should have had:
>
> Fixes: 19a91841c34 "st/mesa: Use Array._DrawVAO in st_atom_array.c."
Probably at least for patch #3 and #4.
With or without such comment and for the series:
Reviewed-by: Mathi
Erik,
> Yeah, in both D3D11 and D3D12, InstanceDataStepRate is per element, not
> per input slot. So I guess this is the most flexible way of describing
> this, and we'll have to duplicate the bindings in cases like these.
More an answer to your below question.
But I think you are giving the answe
Hey,
On Tuesday, 11 December 2018 10:19:47 CET Erik Faye-Lund wrote:
> On Mon, 2018-12-10 at 18:23 +0100, Mathias Fröhlich wrote:
> > Hi Erik,
> >
> > Not sure if this is our problem as I think that I only saw simple
> > bindings with a zero instance divisor wh
Hi Erik,
Not sure if this is our problem as I think that I only saw simple
bindings with a zero instance divisor while debugging supertux kart.
But at least I think that this is a problem in virglrenderer. The
glVertexBindingDivisor is per binding and not per vertex attribute
in OpenGL.
... you p
Good Morning,
Again sorry, but since I only work here in the spare time, I did not find
enough to respond earlier.
On Tuesday, 4 December 2018 10:35:58 CET Erik Faye-Lund wrote:
> > Sounds to me like that, or even worse something with the
> > supertuxkart.
> > I have not yet understood what they
Good Morning,
On Tuesday, 4 December 2018 13:33:29 CET Gert Wollny wrote:
> Am Dienstag, den 04.12.2018, 10:35 +0100 schrieb Erik Faye-Lund:
> >
> > But looking through both virgl and virglrenderer, I can't spot
> > anything obviously wrong with the way inputs are being set up...
> >
> > > May b
Hey,
On Monday, 3 December 2018 12:15:17 CET Erik Faye-Lund wrote:
> Yeah. An important thing to note is that virgl is pretty widely tested
> by now, and we don't see this pop up in other places... And that sounds
> a bit strange to me.
Good to know, I don't actually know how wide virgl is alread
Good Morning,
On Tuesday, 27 November 2018 10:17:07 CET Erik Faye-Lund wrote:
> On Tue, 2018-11-27 at 07:11 +0100, Mathias Fröhlich wrote:
> > Hi Erik,
> >
> > > > On Monday, 26 November 2018 19:39:50 CET Erik Faye-Lund wrote:
> > > > > I know this is
Hi Erik,
> > On Monday, 26 November 2018 19:39:50 CET Erik Faye-Lund wrote:
> > > I know this is *very* late notice, but this commit broke Super Tux
> > > Kart
> > > on VirGL. Both the player-models as as well as the level data
> > > renders
> > > with gibberish vertex positions since this commit.
Hi,
On Monday, 26 November 2018 19:39:50 CET Erik Faye-Lund wrote:
> I know this is *very* late notice, but this commit broke Super Tux Kart
> on VirGL. Both the player-models as as well as the level data renders
> with gibberish vertex positions since this commit.
>
> The fix that Rob Clark did
On Saturday, 24 November 2018 04:03:06 CET Marek Olšák wrote:
> For the series:
>
> Reviewed-by: Marek Olšák
Thank You!
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,
On Friday, 23 November 2018 18:38:26 CET Chris Wilson wrote:
> > I tried to reproduce this, but valgrind does not show any failures with
> > drawoverhead
> > on radeonsi.
> > What driver backend do you use?
>
> iris, but we don't hit backends before the error on this path.
I know, I thought
Hi Chris,
On Friday, 23 November 2018 16:12:38 CET Chris Wilson wrote:
>
> Something to note here is that valgrind reports
> (piglit/bin/drawoverhead):
>
> ==492== Use of uninitialised value of size 8
> ==492==at 0x6EB8FA9: cso_hash_find_node (cso_hash.c:198)
> ==492==by 0x6EB9026: cso_h
Hi Erik,
The series looks very reasonable and I could not spot loosing any negating ! in
the
query logic. Even if I have not been able time wise to double checked every
move when
which texture format got introduced in which ES GL version.
So, what can I tell now? Is that already a reviewed by?
Hi,
On Monday, 19 November 2018 20:17:38 CET Roland Scheidegger wrote:
> FWIW this looks like a rather similar incident to me what happened when mesa
> began to verify the max vertex stride (which needs to be 2048 with GL 4.4
> whereas r600 can only do 2047) where I argued it's a much better ide
Good Morning,
On Tuesday, 20 November 2018 23:49:28 CET Marek Olšák wrote:
> For the series:
>
> Reviewed-by: Marek Olšák
Thanks!
and pushed now!
best
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/m
Hi Timothy,
On Tuesday, 20 November 2018 12:16:58 CET Timothy Arceri wrote:
> I have mixed feeling about the comment as things like that tend to get
> out of date. I think this change is fine as is.
Ok, so I will leave that as is.
> By the way thanks for all your work cleaning all this stuff up.
Hi,
> Yes thank you. In more actively changed code I guess it would make more
> sense to leave the bitfield width but as this is unlikely to change much
> in future you have convinced me its probably not worth leaving it. Thanks.
Oh, you mean as it would have documented what value ranges you ca
est
Mathias
>
> On 20/11/18 6:24 pm, mathias.froehl...@gmx.net wrote:
> > From: Mathias Fröhlich
> >
> > With the current VAO layout we do not need to make these
> > fields a bitfield. We get a tight struct layout with this change
> > for VAO attributes.
>
Hi Brian,
On Sunday, 18 November 2018 20:54:50 CET Brian Paul wrote:
> The series looks great. Just a few minor things below.
>
> Reviewed-by: Brian Paul
Thank you!
For reference, the requested changes in the following mail.
I have also used GLubyte for Patch #10 then.
best
Mathias
Good Morning,
I can confirm that the new build gcc-8.2.1-5 from jakub already
available in *-testing fixes the problem for me.
Thanks!!
Mathias
On Saturday, 3 November 2018 15:31:32 CET Mathias Fröhlich wrote:
> Hi,
>
> > > Before filing a bug report at gcc I wanted to verify
Hi,
> > Before filing a bug report at gcc I wanted to verify that we are not doing
> > anything
> > wrong like with aliasing for example. Which is the reason the bug is not
> > filed yet.
>
> FYI I filed a bug in fedora, and Jakub tracked it down and is working
> it upstream at:
> https://gcc.g
Hi,
On Friday, 2 November 2018 06:22:13 CET Dave Airlie wrote:
> On Tue, 23 Oct 2018 at 10:57, Eric Anholt wrote:
> >
> > Eric Engestrom writes:
> >
> > > Fixes errors thrown by GCC's Undefined Behaviour sanitizer (ubsan) every
> > > time this macro is used.
>
> This seems to be causing problem
Hi Brian,
On Thursday, 1 November 2018 17:02:38 CET Brian Paul wrote:
> Reviewed-by: Brian Paul
Thanks!
there is more in the queue.
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-
Hi,
On Thursday, 1 November 2018 17:28:48 CET Eric Engestrom wrote:
> Pushed now, but travis still fails:
> https://travis-ci.org/mesa3d/mesa/jobs/449405406
>
> I'm really confused here, because the LANG is now fixed, so it shouldn't
> behave differently on different environments?
>
> If anyone
Hi Michel,
> > There seems to be a failure with the latest patches you pushed.
> > The patch fixes a failure with the sort order in egl symbols.
>
> Well, now it's broken with other locales. :)
>
> I guess src/egl/egl-entrypoint-check itself should make sure sort runs
> with locale settings resu
Hi,
On Thursday, 1 November 2018 16:35:30 CET Eric Engestrom wrote:
> Fixes: 68dc591af16ebb36814e "egl: Fix eglentrypoint.h sort order."
> Cc: Emil Velikov
> Cc: Mathias Fröhlich
> Cc: Tapani Pälli
> Signed-off-by: Eric Engestrom
> ---
> src/egl/egl-entrypoint
Hi,
On Thursday, 1 November 2018 11:04:27 CET Pekka Paalanen wrote:
> On Wed, 31 Oct 2018 16:41:47 -0400
> Marek Olšák wrote:
>
> > On Wed, Oct 31, 2018 at 11:26 AM Michel Dänzer wrote:
> >
> > > On 2018-10-31 12:39 a.m., Gustaw Smolarczyk wrote:
> > > > śr., 31 paź 2018 o 00:23 Marek Olšák
Hi Brian,
On Tuesday, 30 October 2018 13:06:50 CET Brian Paul wrote:
> The series looks great, Mathias.
>
> Reviewed-by: Brian Paul
Thanks for that one!
> > @@ -2072,7 +2073,7 @@ vbo_initialize_exec_dispatch(const struct gl_context
> > *ctx,
> > void GLAPIENTRY
> > _mesa_DrawArrays(GLenum
Good Morning,
On Tuesday, 30 October 2018 13:24:50 CET Eric Engestrom wrote:
> > @@ -1294,7 +1294,7 @@ static void GLAPIENTRY
> > _save_OBE_Rectf(GLfloat x1, GLfloat y1, GLfloat x2, GLfloat y2)
> > {
> > GET_CURRENT_CONTEXT(ctx);
> > - vbo_save_NotifyBegin(ctx, GL_QUADS);
> > + vbo_save_
Hi,
> > On finishing a display list playback the VBO_SAFE_FALLBACK bit
> >
>
> s/SAFE/SAVE/g (here and in the title)
>
> Regards,
> Gustaw Smolarczyk
Thanks, changed locally ...
best
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
c patch
>
> At this point we should be pretty much set, so any formal Ack/Rb will
> be appreciated.
Sure and sorry for the long delay!
Patch #1-#6 is:
Reviewed-by: Mathias Fröhlich
The #7 is already reviewed by Dylan, so the series should be complete now.
Thanks for iterating on that.
An
Hi Emil,
Ok, thanks for picking that up.
On Tuesday, 2 October 2018 12:23:30 CEST Emil Velikov wrote:
> On Thu, 20 Sep 2018 at 15:13, Mathias Fröhlich
> wrote:
>
> >
> > If I replace the above with
> >
> > EGLint surface_type = 0;
> > /*
Hi Emil,
On Tuesday, 2 October 2018 11:59:23 CEST Emil Velikov wrote:
> > > + return dev->device->nodes[DRM_NODE_PRIMARY];
> > ... we probably want
> > return _eglGetDRMDeviceRenderNode(dev);
> >
> That isn't quite possible, as discussed in 2016's thread
> "EGL_EXT_*_drm - primary vs rende
Hi Emil,
some comments below:
On Tuesday, 4 September 2018 20:33:05 CEST Emil Velikov wrote:
> From: Emil Velikov
>
> This new 'platform' is added by default with no guards.
>
> It is effectively a copy of the surfaceless one, with updated function
> names and brand new probe function.
>
> Du
Hi Emil,
There are some comments inline below:
On Tuesday, 4 September 2018 20:33:00 CEST Emil Velikov wrote:
> From: Emil Velikov
>
> Add implementation based around the drmDevice API. As such it's only
> available only when building with libdrm. With the latter already a
> requirement when us
Hi Emil,
Some comments inline below:
On Tuesday, 4 September 2018 20:32:59 CEST Emil Velikov wrote:
> From: Emil Velikov
>
> Add a plain software device, which is always available.
>
> We can safely assign it as the first/initial device in _eglGlobals,
> although we ensure that's the case with
Hi Emil,
On Tuesday, 4 September 2018 20:32:58 CEST Emil Velikov wrote:
> From: Emil Velikov
>
> Introduce the API for device query and enumeration. Those at the moment
> produce nothing useful since zero devices are actually available.
>
> That contradicts with the spec, so the extension isn't
Hi Brian,
> gl.xml doesn't seem relevant to this. In GL/glext.h we have:
I thought that somewere at khronos the headers are
generated from the xml. And the new headers are usually
imported then together with the matching xml into mesa?
> typedef khronos_ssize_t GLsizeiptr;
> [...]
> typedef ptrd
riate driver function pointers.
This one as well as the other two warning fixes:
Reviewed-by: Mathias Fröhlich
best
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
The patches are pushed now.
Thanks for the review!
best
Mathias
On Thursday, 6 September 2018 16:42:51 CEST Brian Paul wrote:
> The series looks good to me.
>
> Reviewed-by: Brian Paul
>
> On 09/06/2018 08:31 AM, mathias.froehl...@gmx.net wrote:
> > From: Mathias Fröhlic
Hi,
On Thursday, 6 September 2018 23:43:41 CEST Roland Scheidegger wrote:
> Looks alright to me, albeit seems a bit weird your hw can have offset of
> 255 but only max stride of 128 - max offset being larger than max stride
> doesn't really make a whole lot of sense. (Could you handle stride 255
>
; was reproducible using xonotic-glx -benchmark demos/the-big-keybench.dem.
> >
> > This patch survives intels CI system without changes in the tests.
> >
> > Tested-by: Ville Syrjälä
> > Signed-off-by: Mathias Fröhlich
> > ---
> > src/mesa/tnl/t_s
Hi Emil,
On Tuesday, 4 September 2018 20:32:57 CEST Emil Velikov wrote:
> Hi all,
>
> Here is a re-spin of the EGLDevice series.
>
> Changelog highlights:
> - rebased on top of "egl/android: rework device probing"
> - better patch split
> - surfaceless cleanups are left to another series
> -
Hi Emil,
On Tuesday, 4 September 2018 22:16:18 CEST Emil Velikov wrote:
> Aaand it out, yet I forgot to CC you :-\
Never mind.
I have seen that but did not find the time so far to test and review.
But that's on my list.
best
Mathias
___
mesa-dev maili
aaad7e62ea0 draw_cube_smooth (kmscube)
>#18 0xd7e64160 atomic_run (kmscube)
>#19 0xa93306e0 __libc_start_main (libc.so.6)
>#20 0xd7e621fc $x (kmscube)
>#21 0xd7e621fc $x (kmscube)
>
> I've traced this back to this commit:
&g
Hi,
On Monday, 3 September 2018 03:11:37 CEST Ian Romanick wrote:
> I don't know this code very well, but this seems to better match the
> original (before 64d2a204805). Since it works for Ville and passes the
> Intel CI,
>
> Reviewed-by: Ian Romanick
Thanks for looking into that!
I have chang
Hi Emil,
On Tuesday, 4 September 2018 16:21:49 CEST you wrote:
> > ssh different-machine.somewhere
> >
> > Then you will see that you are not added to the card0 acl as you are not
> > logged to any console.
>
> Ouch, I should have noticed the "rw" for "other" of your render node.
> Looking at a
Hi,
On Wednesday, 22 August 2018 06:57:57 CEST mathias.froehl...@gmx.net wrote:
> From: Mathias Fröhlich
>
> Hi Ville, Brian,
>
> The below patch fixes the regression to tnl drivers that Ville reported
> a hand full weeks ago.
> Please review!
Ping?
Or is the habit in
; I've traced this back to this commit:
>
> 19a91841c347107d877bc750371c5fa4e9b4de19 is the first bad commit
> commit 19a91841c347107d877bc750371c5fa4e9b4de19
> Author: Mathias Fröhlich
> Date: Sun Apr 1 20:18:36 2018 +0200
>
> st/mesa: Use
1 - 100 of 435 matches
Mail list logo