b. value is incorrect.
>
> Fixes: 3ee2be4113d ("egl: split _eglParseImageAttribList into per
> extension functions")
> Cc: Michel Dänzer <mic...@daenzer.net>
> Reported-by: Michel Dänzer <mic...@daenzer.net>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.
IBUTE 0x3004
Unexpected EGL error: EGL_BAD_PARAMETER 0x300c
Expected EGL error: EGL_BAD_ATTRIBUTE 0x3004
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa
From: Michel Dänzer <michel.daen...@amd.com>
st_framebuffer_create returns NULL if stfbi == NULL or
st_framebuffer_add_renderbuffer returns false for the colour buffer.
Fixes Xorg crashing on startup using glamor on radeonsi.
Fixes: 147d7fb772a7 ("st/mesa: add a winsys b
ot; refers only to src/gallium/auxiliary/gallivm/ , an
auxiliary module for LLVM related things. The paragraph above is about
the Gallium3D (or just Gallium) framework.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
its
f1be3d8cdde1 ("radeonsi: don't flush an empty IB if the only thing we
need is a fence")
800efb0690e9 ("radeonsi: Flush when we're asked to return a fence but
don't have one yet")
for how the radeonsi driver handles this.
--
Earthling Michel Dänz
On 07/07/17 12:29 PM, Michel Dänzer wrote:
> From: Thomas Hellstrom <thellst...@vmware.com>
>
> If the application hasn't done any drawing since the last call, we
> would reuse the same back buffer which was used for the previous swap,
> which may not have completed y
hangs.
In the normal case, the behaviour is unchanged.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97957
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101683
Cc: mesa-sta...@lists.freedesktop.org
[Michel Dänzer: Make Thomas' fix from bugzilla actually work as
intended, write comm
ld be some sort of version
>> number and probably needs to be provided by the actual driver.
>>
>
> This is something I've been on the fence about for a while, mostly
> because the vulkan and gl driver for mesa come out of the same source
> base.
o what you're proposing
>>> sounds like a nice simplification of the code as well as something
>>> that might expose more configs to the client.
>>>
>>> Kristian
>>
>>
>> OK. Thanks Kristian.
>>
>> FWIW, from what I can tell, dri3 only
On 30/06/17 04:47 AM, Marek Olšák wrote:
> From: Marek Olšák <marek.ol...@amd.com>
>
> https://lists.freedesktop.org/archives/amd-gfx/2017-June/010591.html
This is premature. The discussion on amd-gfx hasn't concluded yet.
--
Earthling Michel Dänzer |
nds like dumping resources is useful, so...
FWIW, after my previous post it occurred to me that resource dumping
might not be necessary after all; dumping transfers might be sufficient
for a replayable trace.
Adding José, I hope he can clarify.
--
Earthling Michel Dänzer |
On 27/06/17 04:10 AM, Marek Olšák wrote:
> In my opinion, dumping resources isn't very useful. I think it would
> be better to remove that completely.
You'd have to remove the whole trace driver along with it, since its
purpose is to generate a trace which can be replayed.
--
Earthling
: don't flag _NEW_TRANSFORM for st/mesa if possible
>
> It also optimizes the case slightly for GL core.
>
> It doesn't try to fix that glEnable might be a bad place to do the
> clip plane transformation.
Thanks for this fix.
Tested-by: Michel Dänzer <michel.daen...@amd.com>
--
other
tests in the same group.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On 22/06/17 05:58 PM, Jack Mitchell wrote:
> On 22/06/17 03:32, Michel Dänzer wrote:
>> On 22/06/17 02:56 AM, Grazvydas Ignotas wrote:
>>> Looks like nobody tested radeonsi on BE for 5 months at least. You can
>>> try the attached patch, but I suspect ther
it from the relaxed semantics, and
> applications that get it wrong in one shader are rather likely to get it
> wrong everywhere.
>
> Since GLSL simply says derivatives are undefined after non-uniform
> discard, and this option makes it defined instead, se
41
PIGLIT: {"result": "fail" }
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-de
tly can't (and never could) work on big endian hosts.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freede
hat doesn't really stop us from front rendering to it or
> reading from it if so desired?
You mean turn the back buffer being swapped into the new fake front
buffer, right?
I guess that could work, but I'm not sure it's quite as simple as your
patch, e.g. related to buffer age or draw->is_
)(int drm_fd, unsigned flags);
If you use an enum for the flags, gdb should be able to print the
symbolic flag names.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_
correct after all but the fix is in the fact it
> introduces a GL stream read barrier rather than an X barrier. But since
> it also introduces an X barrier, it corrects the glXWaitGL behavior as
> well.
While your patch fixes the problem, I think it's not quite correct (the
same problem co
>BorderColor.ui[1] ||
msamp->BorderColor.ui[2] ||
msamp->BorderColor.ui[3])) {
No need to test the BorderColor.ui array when the border colour isn't used.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
On 15/06/17 01:08 AM, Samuel Pitoiset wrote:
> Fixes: 5f249b9f05e ("mapi: add GL_ARB_bindless_texture entry points")
> Reported-by: Mark Janes <mark.a.ja...@intel.com>
> Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
Pushed, thanks
On 14/06/17 05:42 PM, Nicolai Hähnle wrote:
> On 14.06.2017 10:05, Michel Dänzer wrote:
>> On 14/06/17 04:42 PM, Nicolai Hähnle wrote:
>>> On 14.06.2017 05:39, Michel Dänzer wrote:
>>>> From: Michel Dänzer <michel.daen...@amd.com>
>>>>
>>
From: Michel Dänzer <michel.daen...@amd.com>
It calling itself recursively prevented it from being inlined, resulting
in a copy being generated in every compilation unit referencing it. This
bloated the text segment of the Gallium mega-driver *_dri.so by ~4%,
and might also have im
On 14/06/17 04:42 PM, Nicolai Hähnle wrote:
> On 14.06.2017 05:39, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> It calling itself recursively prevented it from being inlined, resulting
>> in a copy being generated in e
On 14/06/17 07:36 AM, Marek Olšák wrote:
> On Tue, Jun 13, 2017 at 5:18 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 13/06/17 01:31 AM, Marek Olšák wrote:
>>> From: Marek Olšák <marek.ol...@amd.com>
>>>
>>> ---
>>> src/gallium/auxi
On 13/06/17 08:08 PM, Gustaw Smolarczyk wrote:
> 2017-06-13 12:07 GMT+02:00 Michel Dänzer <mic...@daenzer.net>:
>> On 13/06/17 06:51 PM, Timothy Arceri wrote:
>>> On 13/06/17 19:22, Michel Dänzer wrote:
>>>> From: Michel Dänzer <michel.daen...@amd.com&g
From: Michel Dänzer <michel.daen...@amd.com>
It calling itself recursively prevented it from being inlined, resulting
in a copy being generated in every compilation unit referencing it. This
bloated the text segment of the Gallium mega-driver *_dri.so by ~4%,
and might also have im
On 13/06/17 06:51 PM, Timothy Arceri wrote:
> On 13/06/17 19:22, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> It calling itself recursively prevented it from being inlined, resulting
>> in a copy being generated in e
From: Michel Dänzer <michel.daen...@amd.com>
It calling itself recursively prevented it from being inlined, resulting
in a copy being generated in every compilation unit referencing it. This
bloated the text segment of the Gallium mega-driver *_dri.so by ~5%,
and might also have im
From: Michel Dänzer <michel.daen...@amd.com>
It calling itself recursively prevented it from being inlined, resulting
in a copy being generated in every compilation unit referencing it. This
bloated the text segment of the Gallium mega-driver *_dri.so by ~5%,
and might also have im
>
The patch didn't apply cleanly as-is, but fixing it up manually,
Reviewed-and-Tested-by: Michel Dänzer <michel.daen...@amd.com>
Thanks Sam.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
adeonsi_dri.so
10001218 271176 2062272 12334666 bc364a
/tmp/radeonsi_dri.so.patched
It might also help for other pipe_resource_reference callers.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
On 12/06/17 06:32 PM, Gert Wollny wrote:
> Am Montag, den 12.06.2017, 15:44 +0900 schrieb Michel Dänzer:
>> On 10/06/17 08:15 AM, Gert Wollny wrote:
>>>
>>> Piglit shows 7 fixes and 6 regressions compared to git 8fac894f,
>>> but they don't
>>> see
patches)? Do they
consistently pass without your patches and fail with them?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing l
On 10/06/17 12:43 AM, Aaron Watry wrote:
> On Wed, Jun 7, 2017 at 11:12 PM, Aaron Watry <awa...@gmail.com> wrote:
>> On Wed, Jun 7, 2017 at 9:15 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>>> On 08/06/17 03:42 AM, Marek Olšák wrote:
>>>> On Wed
f (ws->info.drm_minor < 40)
>> ws->info.max_alloc_size = MIN2(ws->info.max_alloc_size,
>> 256*1024*1024);
>
> Yes, feel free to push that.
That also affects PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE, is that intended?
--
Earthling Michel Dänzer |
;Gallium on". The
length of the renderer string seems irrelevant (though you could shorten
it more by shortening the kernel version string :).
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 07/06/17 06:34 PM, Thomas Hellstrom wrote:
> Module: Mesa
> Branch: fdo_master
Oops? :)
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
}
>
> @@ -493,6 +498,7 @@ dri3_flush_front_buffer(__DRIdrawable *driDrawable, void
> *loaderPrivate)
>
> loader_dri3_flush(draw, __DRI2_FLUSH_DRAWABLE,
> __DRI2_THROTTLE_FLUSHFRONT);
>
> + (*psc->f->invalidate)(driDrawable);
> loader_dri
if (blit.src.resource == blit.dst.resource &&
> +screen->get_param(screen, PIPE_CAP_TEXTURE_BARRIER))
> + pipe->texture_barrier(pipe, PIPE_TEXTURE_BARRIER_SAMPLER);
> +
> pipe->blit(pipe, );
Maybe this should be handled within the pipe->bl
testing libclc and clover as part of
my daily "build current Git of everything, run piglit and check for
regressions" script/routine. I've been reporting regressions and
submitted patches to fix them if it's trivial, but I don't have the time
/ interest to do more than that.
--
Ear
an peruse the data any way
they like. (Unfortunately, current sysprof 3.y.z can no longer read data
from older 1.y.z, but 1.2.0 can still be built quite easily from
git://git.gnome.org/sysprof)
--
Earthling Michel Dänzer | http://www.amd.com
Libre software e
in (main=0x55d1c439c8b0 ,
argc=3, argv=0x7ffc12f6f2a8, init=, fini=,
rtld_fini=, stack_end=0x7ffc12f6f298) at ../csu/libc-start.c:291
#9 0x55d1c439c8ea in _start ()
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 10/05/17 11:31 PM, Kai Wasserbäch wrote:
> Michel Dänzer wrote on 10.05.2017 10:27:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> deregisterEHFrames doesn't take any parameters anymore.
>>
>> Signed-off-by: Michel Dänzer <michel.daen...@amd.c
From: Michel Dänzer <michel.daen...@amd.com>
deregisterEHFrames doesn't take any parameters anymore.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff
On 09/05/17 07:28 PM, Thomas Hellstrom wrote:
> On 05/09/2017 11:29 AM, Michel Dänzer wrote:
>> On 09/05/17 06:12 PM, Thomas Hellstrom wrote:
>>> On 05/09/2017 10:47 AM, Michel Dänzer wrote:
>>>> On 09/05/17 05:32 PM, Thomas Hellstrom wrote:
>>>>>
On 09/05/17 06:12 PM, Thomas Hellstrom wrote:
> On 05/09/2017 10:47 AM, Michel Dänzer wrote:
>> On 09/05/17 05:32 PM, Thomas Hellstrom wrote:
>>> On 05/09/2017 10:05 AM, Michel Dänzer wrote:
>>>> On 05/05/17 11:02 PM, Thomas Hellstrom wrote:
>>>>>
On 09/05/17 05:32 PM, Thomas Hellstrom wrote:
> On 05/09/2017 10:05 AM, Michel Dänzer wrote:
>> On 05/05/17 11:02 PM, Thomas Hellstrom wrote:
>>> Increases performance on vmwgfx since we're avoiding full buffer damage and
>>> since we can't sync to vertical retrace
+137,11 @@ TODO: document the other workarounds.
>
>
>
> +
> +
> +
> +
> +
> +
> +
>
>
Why restrict this to gnome-shell? Wouldn't any application using these
extensions be affected
acking
spec@glsl-1.50@execution@interface-blocks-complex-vs-fs
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.
On 28/04/17 09:11 PM, Marek Olšák wrote:
> On Thu, Apr 27, 2017 at 8:47 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 27/04/17 10:15 AM, Timothy Arceri wrote:
>>> Modern disks are extremely large and are only going to get bigger.
>>> Usage has shown
e aggressively.
>
> Cc: "17.1" <mesa-sta...@lists.freedesktop.org>
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X develope
On 26/04/17 07:06 PM, Gregory Hainaut wrote:
> On 4/26/17, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 26/04/17 05:07 PM, Gregory Hainaut wrote:
>>> Following the discussion in "[PATCH v4 0/3] asynchronous pbo transfer with
>>> glthread"
>&
e = MAX2(1024*1024*1024, vfs.f_blocks * vfs.f_bsize / 10);
> + max_size = MAX2(1024*1024*1024, vfs.f_blocks * vfs.f_bsize / 20);
> }
5% can still be quite a lot (what if every library on the system tried
using that much for itself?). How about 1%?
Anyway, thi
;17.1" <mesa-sta...@lists.freedesktop.org>
[...]
> - if (sb.st_size)
> - p_atomic_add(cache->size, - (uint64_t)sb.st_size);
> + if (sb.st_blocks * 512)
> + p_atomic_add(cache->size, - (uint64_t)sb.st_blocks * 512);
No need to multiply by 512 here. With that r
From: Michel Dänzer <michel.daen...@amd.com>
Hardcode the OpenCL InputKind in compat::set_lang_defaults.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/state_trackers/clover/llvm/compat.hpp | 10 ++
src/gallium/state_trackers/clover/llvm/invocat
On 26/04/17 07:11 PM, Gregory Hainaut wrote:
> On 4/26/17, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 26/04/17 05:07 PM, Gregory Hainaut wrote:
>>>
>>> Note: those dri2* functions are typically called by gallium/mesa state
>>> tracker to hand
ted to vsync.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop
in multicore CPU
> era)
> * Track gl call that will use X11 API to force a sync
Until either of the latter two happens, glthread should only be enabled
with DRI3.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusia
t a success. The dri2_drawable pdraw object is correctly populated
> with good value but I have tons of piglit failure. Debug is on-going
> but I'm afraid that it might not be possible to use XCB.
Can you share the patch you're testing?
--
Earthling Michel Dänzer |
let radeonsi (and other gallium
> drivers) access drirc directly?
Yeah, something like that would be a better approach. This patch is too
hackish.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
regory hainaut
>>> <gregory.hain...@gmail.com> wrote:
>>>> On Thu, 20 Apr 2017 11:57:08 +0200
>>>> Marek Olšák <mar...@gmail.com> wrote:
>>>>
>>>>> On Thu, Apr 20, 2017 at 10:28 AM, gregory hainaut
>>>&
On 20/04/17 05:28 PM, gregory hainaut wrote:
> On Thu, 20 Apr 2017 12:29:11 +0900
> Michel Dänzer <mic...@daenzer.net> wrote:
>
>> On 20/04/17 01:54 AM, Gregory Hainaut wrote:
>>> Hello,
>>>
>>> Please find the latest version that include a sma
not make any libX11 API calls.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.fre
1 library.
> If performance of X11 is critical, it would be better to switch to xcb anyway.
There has been talk about making that change, but there's not even a
specific plan yet for making it happen upstream. It doesn't change the
situation with currently shipping libX11.
so won't play nice with this extension.
>
> Finally it seem it is no longer used by gstreamer.
FWIW, cairo still has code to use this extension, but AFAIK the cairo GL
backend isn't really used in the wild.
--
Earthling Michel Dänzer | http://www.amd.com
L
XT_FLAG_NO_ERROR_BIT_KHR;
>> +
>
> This seems like the kind of setting that should be ignored for setuid
> processes. Not that we're particularly clean about this in general, and
> GL apps really shouldn't be setuid in the first place, but still...
Also
On 18/04/17 09:52 PM, Ilia Mirkin wrote:
> On Tue, Apr 18, 2017 at 2:21 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 18/04/17 01:02 PM, Ilia Mirkin wrote:
>>> On Tue, Apr 18, 2017 at 12:00 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>>>> val_bool
On 18/04/17 05:04 PM, gregory hainaut wrote:
> On Tue, 18 Apr 2017 08:51:24 +0200
> gregory hainaut <gregory.hain...@gmail.com> wrote:
>
>> On Mon, 17 Apr 2017 11:17:42 +0900
>> Michel Dänzer <mic...@daenzer.net> wrote:
>>
>>> On 15/04/17 05:08 PM,
action is to
only call libX11 APIs from one thread (at least for the time being;
there are plans to make libX11 always behave as if XInitThreads was
called first, but I'm not sure when it'll happen).
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusia
loader_ops pipe_loader_drm_ops;
>>
>> #ifdef GALLIUM_STATIC_TARGETS
>> static const struct drm_conf_ret throttle_ret = {
>> - DRM_CONF_INT,
>> - {2},
>> + .type = DRM_CONF_INT,
>> + .val.val_int = 2,
>> };
This (whole hunk?) looks unrelated, s
tMainLoop () from /usr/lib64/libglut.so.3
>> #10 0x004019fc in ?? ()
>> #11 0x7fbda957e541 in __libc_start_main () from /lib64/libc.so.6
>> #12 0x00401afa in ?? ()
>>
>> Should I do more or not worth it?
>>
>> Dieter
>
> Hello Dieter,
>
>
On 13/04/17 11:57 PM, Alan Swanson wrote:
> On Thu, 2017-04-13 at 13:00 +0900, Michel Dänzer wrote:
>> On 13/04/17 03:15 AM, Francisco Jerez wrote:
>>> Michel Dänzer <mic...@daenzer.net> writes:
>>>
>>>> From: Michel Dänzer <michel.daen...@
On 13/04/17 03:15 AM, Francisco Jerez wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> clang::LangAS::Offset is gone, the behaviour is as if it was 0.
>> Signed-off-by: Michel Dänzer <m
From: Michel Dänzer <michel.daen...@amd.com>
clang::LangAS::Offset is gone, the behaviour is as if it was 0.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/state_trackers/clover/llvm/codegen/common.cpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
FWIW, Mesa already supports 2c) with DRI3, via the device_id option.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lis
Kaveri. Example report
from R600_DEBUG=check_vm attached.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
VM fault report.
Command: /home/daenzer/src/piglit-git/piglit/bin/amd_pinned_memory
incre
On 06/04/17 11:50 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle <nicolai.haeh...@amd.com>
>
> The system value only has an X component, and radeonsi started
> checking that in debug builds.
>
> Reported-by: Michel Dänzer <michel.daen...@amd.com>
> Fixes: 4c
On 30/03/17 05:09 PM, Thomas Hellstrom wrote:
> On 03/30/2017 05:48 AM, Michel Dänzer wrote:
>> On 30/03/17 12:56 AM, Thomas Hellstrom wrote:
>>> On 03/29/2017 02:34 PM, Emil Velikov wrote:
>>>> On 29 March 2017 at 13:02, Thomas Hellstrom <thellst...@vmware.com>
t; should perhaps make them up-to-date with the flush extension.
>>>
>> Of the above:
>>
>> - nouveau: Does not support DRI_IMAGE, thus it doesn't work even
>> before the patch.
>> - i915: I have some untested ancient patches. Will see if I can rebase
>>
(at least).
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman
6b7f1d49 ("glsl: fix lower jumps for returns when loop is
inside an if")
Also add
Bugzilla: https://bugs.freedesktop.org/100441
and you can add
Tested-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | ht
On 20/03/17 06:40 AM, Timothy Arceri wrote:
> On 17/03/17 18:38, Michel Dänzer wrote:
>> On 17/03/17 09:02 AM, Timothy Arceri wrote:
>>> Fixes a bunch of piglit crashes that hit an assert() when trying
>>> to delete the framebuffer. The assert() was triggered because
&
On 22/03/17 09:20 PM, Serge Pavlov wrote:
> Hi Michel,
>
> Thank you for analysis. Should be fixed in r298498.
Indeed, it's fixed, thanks!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X
the build of at least libclc and Mesa, because
llvm-config --cxxflags contains multiple flags concatenated without
spaces, e.g. "-fdata-sections-O3" or "-fno-rtti-DLLVM_BUILD_GLOBAL_ISEL".
--
Earthling Michel Dänzer | http://www.amd.com
Libre software
on
(https://addons.mozilla.org/addon/toggle-word-wrap/) works quite well
for me in Thunderbird. The only gotcha is that it still breaks lines at
the window border, so you have to make the compositor window wide enough
for all lines to fit.
--
Earthling Michel Dänzer | http://ww
ist.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mail
Oh yes, very good point there!
> My r-b now stands with this fix applied :)
>
> This will lead to a bunch of unnecessary whitespace in the middle, but
> I'm not sure I'd recommend addressing this:
> A simple 's/[[[:space:]]]+/ /g' at the end should trivially fix this,
> [...]
In addition to other comments, the Git shortlog no longer matches the
patch itself.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev
0)
> +ctx->eg_interpolators[k].enabled =
> true;
> }
> }
> }
>
Looks like this patch replaces tabs with spaces for indentation, please fix.
--
Earthling Michel Dänzer |
On 17/03/17 09:02 AM, Timothy Arceri wrote:
> Fixes a bunch of piglit crashes that hit an assert() when trying
> to delete the framebuffer. The assert() was triggered because
> WinSysDrawBuffer was set to NULL before glDeleteFramebuffers()
> was called.
Tested-by: Michel Dänzer
1` " | sed -E \
Other than that, I agree replacing \> with [[[:space:]]] is probably the
best solution, since the former wouldn't work as intended anyway with
hypothetical switches containing one we're matching for as a prefix,
e.g. -DNDEBUG-THANKS / -D_GNU_SOURCE-PLEASE / -
On 17/03/17 07:42 AM, Vinson Lee wrote:
> Fixes: fe56c745b8cb ("Convert sed(1) syntax to be compatible with FreeBSD and
> OpenBSD")
Not sure how, since \> was already used (way) before that.
--
Earthling Michel Dänzer | http://www.amd.com
Libre
On 16/03/17 03:01 PM, Timothy Arceri wrote:
> glNewList() swaps dispatch tables, and we don't have anything in
> place to handle that in glthread.
This prevents three piglit tests from crashing with mesa_glthread=true.
(Many more left though, as discussed on IRC)
Tested-by: Michel
On 16/03/17 12:20 PM, Emil Velikov wrote:
> On 16 March 2017 at 02:57, Matt Turner <matts...@gmail.com> wrote:
>> On Wed, Mar 15, 2017 at 7:55 PM, Emil Velikov <emil.l.veli...@gmail.com>
>> wrote:
>>> On 2 March 2017 at 03:44, Michel Dänzer <mic...@daenze
On 16/03/17 11:57 AM, Matt Turner wrote:
> On Wed, Mar 15, 2017 at 7:55 PM, Emil Velikov <emil.l.veli...@gmail.com>
> wrote:
>> On 2 March 2017 at 03:44, Michel Dänzer <mic...@daenzer.net> wrote:
>>> On 02/03/17 03:35 AM, Emil Velikov wrote:
>>
>>>
From: Michel Dänzer <michel.daen...@amd.com>
Can fail to link otherwise if libdrm is in a non-standard location.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/targets/opencl/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/ta
status: 1)
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
401 - 500 of 2182 matches
Mail list logo
