From: Michel Dänzer <michel.daen...@amd.com>
Without this, the X server may accumulate stale Present event contexts
if a client ends up creating and destroying DRI drawables for the same
window.
v2: Based on Chris Wilson's review:
* Use xcb_present_select_input_checked so that protocol
LIBS="$LLVM_LIBS `$LLVM_CONFIG --system-libs`"
> fi
> fi
Pushed, thanks!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
gl flavor" (reproducible with
LIBGL_ALWAYS_SOFTWARE=1) and spec@egl_khr_fence_sync@conformance in turn.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
From: Michel Dänzer <michel.daen...@amd.com>
Without this, the X server may accumulate stale Present event contexts
if a client ends up creating and destroying DRI drawables for the same
window.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/loader/loader_dri3_
From: Michel Dänzer <michel.daen...@amd.com>
Without this, the X server may accumulate stale Present event contexts
if a client creates and destroys multiple swapchains using the same
window.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
NOTE: This patch is complet
From: Michel Dänzer <michel.daen...@amd.com>
Without this, the X server may accumulate stale Present event contexts
if a client performs several video decoding sessions using the same
window.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/auxiliary/vl/vl_w
Running XTS (the X test suite) on Xephyr using glamor running on Xorg,
I stumbled upon an issue:
* XTS causes Xephyr to keep resetting and starting new server generations
* glamor creates a new GLX context for each server generation but re-uses
the same window
This caused Xorg to accumulate
hing is always better than none. So fwiw I'd just
>> keep this file.
>
> Fine with me.
FWIW, editorconfig supports different settings on a per-file basis.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
On 21.07.2016 18:17, Matt Arsenault wrote:
>> On Jul 21, 2016, at 01:03, Michel Dänzer <mic...@daenzer.net
>> <mailto:mic...@daenzer.net>> wrote:
>>
>> On 21.07.2016 00:04, Michel Dänzer wrote:
>>> On 15.07.2016 05:15, Marek =?UNKNOWN?B?T2zFocOhaw==?=
caused the piglit test
shaders@glsl-fs-vec4-indexing-temp-dst-in-loop (and possibly others) to
hang my Kaveri. Any ideas for how we can get out of this conundrum?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software
paths are used first or
>> not. Or something along those lines...
>
> I believe we use llvm-config to get include dirs and put them on
> commandline, so both should work. For consistency sake <> is better.
Indeed. AFAIK, the main (only?) difference between "" and <&
ad value 8.3
#expected[5] = 3. Read value 1
PIGLIT: {"result": "fail" }
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 01.07.2016 23:11, Emil Velikov wrote:
> On 28 June 2016 at 04:00, Michel Dänzer <mic...@daenzer.net> wrote:
>>
>> FWIW, +1 for adding .editorconfig files corresponding to the existing
>> .dir-locals.el files as a first step, so users of other editors can also
>&
size, ws->info.gart_size);
The radeon driver in kernels older than 3.17 can't allocate BOs larger
than 256MB.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
single texture failed (at tfbo.cpp:781)
mode = 0
fbo: FAIL rgba8, db, z24, s8, win+pmap, id 100
5 tests passed, 1 tests failed.
P.S. The tex3d-maxsize regression I reported earlier is also still
unresolved.
--
Earthling Michel Dänzer |
rconfig files corresponding to the existing
.dir-locals.el files as a first step, so users of other editors can also
get the benefit of their code getting formatted correctly by default.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
On 24.06.2016 19:21, Emil Velikov wrote:
> On 24 June 2016 at 03:32, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 23.06.2016 22:25, Emil Velikov wrote:
>>> On 23 June 2016 at 03:49, Michel Dänzer <mic...@daenzer.net> wrote:
>>>> On 22.06.2016 21:04, Em
77b20995 in piglit_gl_test_run (argc=8, argv=0x7fffe6c8,
config=0x7fffe590) at tests/util/piglit-framework-gl.c:199
#20 0x00401b17 in main (argc=8, argv=0x7fffe6c8) at
tests/texturing/shaders/textureGather.c:10
--
Earthling Michel Dänzer |
On 23.06.2016 22:25, Emil Velikov wrote:
> On 23 June 2016 at 03:49, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 22.06.2016 21:04, Emil Velikov wrote:
>>> From: Emil Velikov <emil.veli...@collabora.com>
>>>
>>> Do not rely on the git sha1:
>&g
tals from affected shaders:
> SGPRS: 547280 -> 547280 (0.00 %)
> VGPRS: 269132 -> 262059 (-2.63 %)
> Code Size: 15709604 -> 15349748 (-2.29 %) bytes
> LDS: 198 -> 198 (0.00 %) blocks
> Scratch: 74752 -> 72704 (-2.74 %) bytes per wave
> Max Waves: 47840 -> 49145
One technique used by such
efforts is to replace any timestamps with all 0s.
Would it be possible to generate a hash over all source files listed in
any Makefile.sources, or something like that?
--
Earthling Michel Dänzer | http://www.amd.com
Libre s
On 21.06.2016 18:49, Emil Velikov wrote:
> On 21 June 2016 at 07:39, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 21.06.2016 15:24, Axel Davy wrote:
>>> On 21/06/2016 01:26, Michel Dänzer wrote:
>>>> On 20.06.2016 20:06, Frank Binns wrote:
>>
On 21.06.2016 15:24, Axel Davy wrote:
> On 21/06/2016 01:26, Michel Dänzer wrote:
>> On 20.06.2016 20:06, Frank Binns wrote:
>>> On 20/06/16 10:48, Michel Dänzer wrote:
>>>> On 18.06.2016 02:41, Frank Binns wrote:
>>>>> Up until now, DRI3 was
iple(triple),
> c.getPreprocessorOpts(),
> #endif
> clang::LangStandard::lang_opencl11);
>c.createDiagnostics(
>
Pushed, thanks!
P.S. I recommend adding your Signed-off-by for patches you want to be
applied.
--
Earthling Michel Dänzer
On 20.06.2016 20:06, Frank Binns wrote:
> On 20/06/16 10:48, Michel Dänzer wrote:
>> On 18.06.2016 02:41, Frank Binns wrote:
>>> Up until now, DRI3 was only used for devices that have render nodes,
>>> unless
>>> overridden via an environment variable, with i
Isn't that a kernel bug?
--
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
.am
> @@ -7,6 +7,7 @@ AM_CPPFLAGS = \
> -I$(top_srcdir)/src/gallium/drivers \
> -I$(top_srcdir)/src/gallium/auxiliary \
> -I$(top_srcdir)/src/gallium/winsys \
> + -I$(top_builddir)/src \
> -I$(srcdir)
>
> if HAVE_CLOVER_ICD
>
Pushed, thanks.
-
t;front_buffer);
> +scrn->front_buffer = NULL;
> + }
> + }
> free(error);
> } else
>scrn->special_event =
>
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | h
On 09.06.2016 22:39, Alex Deucher wrote:
> On Thu, Jun 9, 2016 at 2:44 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> This makes sure that dri_set_tex_buffer2 -> dri_drawable_validate_att
>> will re-cre
From: Michel Dänzer <michel.daen...@amd.com>
This makes sure that dri_set_tex_buffer2 -> dri_drawable_validate_att
will re-create the front left attachment buffer after the drawable got
invalidated.
Fixes window contents not updating until the window is resized when
using DRI2 PRIME.
S
AFAIK the term is "luma keying", not "luma keyring".
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev m
surface->npix_z == 1 &&
> +surface->last_level == 0 &&
> +!(surface->flags & RADEON_SURF_Z_OR_SBUFFER));
FWIW, it's generally better to have use separate assert() stanzas for
each individual condition, so that it'll be immediate
On 02.06.2016 21:20, Michel Dänzer wrote:
> On 02.06.2016 00:35, Marek =?UNKNOWN?B?T2zFocOhaw==?= wrote:
>> Module: Mesa
>> Branch: master
>> Commit: fc1479a95432f291623fa5bafe524701e77af3ca
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=fc1479a
On 06.06.2016 23:12, Marek Olšák wrote:
> On Tue, May 10, 2016 at 10:20 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 10.05.2016 13:00, Nicolai Hähnle wrote:
>>> On 30.04.2016 05:26, Michel Dänzer wrote:
>>>> On 28.04.2016 10:54, Michel Dänzer wrote:
&g
On 06.06.2016 18:44, Axel Davy wrote:
> On 06/06/2016 11:37, Michel Dänzer wrote :
>> With DRI3, st/dri could (re-)allocate buffers with the scanout flag
>> first and after any window geometry changes, then re-allocate without
>> the flag if the present complete event indicat
On 06.06.2016 18:14, Marek Olšák wrote:
> On Mon, Jun 6, 2016 at 10:58 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 03.06.2016 19:52, Marek Olšák wrote:
>>> From: Marek Olšák <marek.ol...@amd.com>
>>>
>>> Simply ignore the "scanout"
On 04.06.2016 00:10, Marek Olšák wrote:
> On Fri, Jun 3, 2016 at 4:33 PM, Dieter Nützel <die...@nuetzel-hh.de> wrote:
>> Am 03.06.2016 11:47, schrieb Michel Dänzer:
>>>
>>> On 03.06.2016 18:34, Marek =?UNKNOWN?B?T2zFocOhaw==?= wrote:
>>>>
>
AA surfaces.
If there's any code setting PIPE_BIND_SCANOUT for such surfaces, it's
buggy and should be fixed.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_
amor, which is fixed by
https://patchwork.freedesktop.org/patch/91214/
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@l
ances came up bad. With the commit before
this one, 20 Xephyr instances came up good.
Since the problem doesn't always occur and looks basically random, maybe
some synchronization isn't quite correct yet.
--
Earthling Michel Dänzer | http://www.a
roke the piglit test spec@!opengl 1.2@tex3d-maxsize on my
Kaveri (radeon driver, 1GB VRAM, 2GB GTT). It prints lots of lines
radeon: Not enough memory for command submission.
to stderr, with corresponding lines
[drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse relocation -12!
in dmesg.
--
E
i.haeh...@amd.com>
> Reviewed-by: Bas Nieuwenhuizen <b...@basnieuwenhuizen.nl>
This commit broke the piglit test spec@arb_shader_image_load_store@level
on my Kaveri and Tonga.
--
Earthling Michel Dänzer | http://www.amd.com
Libre
do stripped
binaries compare?
I'm asking because I heard that LTO negatively affects debugability, so
I wonder if the difference isn't mostly due to the debugging symbols.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
product=freedesktop.org=Bugzilla
--
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
return dri2_create_image_from_winsys(_screen, width, height, format,
> , loaderPrivate);
>
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
Do you need somebody to push this patch for you?
--
Earthling Michel Dänzer | http://www
On 25.05.2016 09:09, Mike Lothian wrote:
> Do you need the DRM version number if you'll be displaying the kernel
> version anyway?
Yes, because the DRM version depends on the kernel driver being used.
The patch is
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling M
On 20.05.2016 19:23, Marek Olšák wrote:
> From: Marek Olšák <marek.ol...@amd.com>
This series is
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
neral.
Also note that Nvidia developers were talking about possibly creating an
nvidia specific GBM backend recently on the wayland-devel mailing list.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Me
On 11.05.2016 18:08, Marek Olšák wrote:
> On Wed, May 11, 2016 at 8:22 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> This should make its meaning clearer.
>>
>> The value it holds is the CPU page
From: Michel Dänzer <michel.daen...@amd.com>
This should make its meaning clearer.
The value it holds is the CPU page size, which can be different from
the GART page size.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/drivers/r300/r300_query.c |
unsigned slc)
Looks like the lines for the second and later parameters aren't properly
aligned to the opening parenthesis.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_
On 10.05.2016 13:00, Nicolai Hähnle wrote:
> On 30.04.2016 05:26, Michel Dänzer wrote:
>> On 28.04.2016 10:54, Michel Dänzer wrote:
>>> On 23.04.2016 07:24, Marek Olšák wrote:
>>>> On Fri, Apr 22, 2016 at 11:28 PM, Nicolai Hähnle
>>>> <nhaeh...@gmail.c
obably shouldn't be in the commit log. Either way
though,
Acked-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
On 09.05.2016 17:02, Bas Nieuwenhuizen wrote:
> On Mon, May 9, 2016 at 5:59 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 08.05.2016 21:21, Marek Olšák wrote:
>>> From: Marek Olšák <marek.ol...@amd.com>
>>>
>>> ---
>>> src/gallium
changing
the shortlog to something like
radeonsi: Add support for PIPE_FORMAT_x8R8G8B8_*
and in the remaining log don't talk about "fixing" big endian support
but just mention that this allows r300g to at least run at all again on
big endian hosts, and reference the bug report.
With those cha
racks BOs at CPU page size granularity, so all BOs implicitly have
this alignment. For GPUVM, since we're aligning the BO size, all VM
address spaces we assign are implicitly aligned as well.
I'd say "gart_page_size" is a bit misleading in general, it's simply the
CPU page size and appli
On 06.05.2016 19:09, Marek Olšák wrote:
> On Fri, May 6, 2016 at 12:01 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 06.05.2016 02:01, Marek Olšák wrote:
>>>> There is one more hardware limitation that can cause VM faults with T2L
>>>> copies and n
's a good idea,
it'll probably result in bug reports.
Apart from that, the series looks great to me.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
On 02.05.2016 20:01, Daniel Stone wrote:
> On 2 May 2016 at 11:44, Rob Clark <robdcl...@gmail.com> wrote:
>> On Mon, May 2, 2016 at 2:15 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>>> So, what is this based on? Maybe I'm not looking in the right place, but
>>
On 04.05.2016 00:11, Rob Clark wrote:
> On Tue, May 3, 2016 at 9:56 AM, Daniel Vetter <dan...@ffwll.ch> wrote:
>> On Mon, May 02, 2016 at 06:44:34AM -0400, Rob Clark wrote:
>>> On Mon, May 2, 2016 at 2:15 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>>>&g
review of Wayland related patches obviously carries a lot
of weight. But I'd expect to see a very different footprint in the Git
history from somebody who calls himself maintainer.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
n this means that it is encountering an undefined attribute.
This happens because the driver doesn't support the format chosen by
st/dri (the DRI state tracker). Please try Marek's latest patch attached
to https://bugs.freedesktop.org/show_bug.cgi?id=71789 .
--
Earthling M
t; There are some winsys cleanups at the end.
>
> Please review.
The series is
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
On 02.05.2016 00:12, Marek Olšák wrote:
> On Sun, May 1, 2016 at 4:34 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 01.05.2016 23:11, Marek Olšák wrote:
>>> From: Marek Olšák <marek.ol...@amd.com>
>>>
>>> The problem was that A8R8G8B8 was not
IW: The xf86-video-ati EXA code actually programs the
hardware to B8G8R8A8 for the same buffers for which st/dri sets the
format to A8R8G8B8. The EXA code always swaps bytes with the CPU for
CPU<->GPU transfers. Is this patch consistent with that?
--
Earthling Michel Dänzer
On 01.05.2016 23:01, Marek Olšák wrote:
> On Sun, May 1, 2016 at 2:43 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 24.04.2016 20:27, Marek Olšák wrote:
>>> From: Marek Olšák <marek.ol...@amd.com>
>>>
>>> ---
>>> src/gallium/dr
dencies though). Memory
> migrations always wait for idle.
Note that TTM BO migration always waits for idle due to a limitation of
the current implementation, which may be lifted at some point. Not by
design.
--
Earthling Michel Dänzer | http://www.a
On 01.05.2016 22:35, Marek Olšák wrote:
> From: Marek Olšák <marek.ol...@amd.com>
This series is
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
T_UV1010 (1 << 21)
> #define R500_COLOR_FORMAT_CI8 (2 << 21) /* 2D only */
Did you or anyone else test this patch? Back when I fixed the classic
r300 driver to work on big endian hosts, none of these bits seemed
On 28.04.2016 10:54, Michel Dänzer wrote:
> On 23.04.2016 07:24, Marek Olšák wrote:
>> On Fri, Apr 22, 2016 at 11:28 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
>>> On 22.04.2016 12:29, Nicolai Hähnle wrote:
>>>> On 20.04.2016 23:02, Michel Dänzer wrote:
&g
ally stricter than that with the radeonsi driver: It sets the
RADEON_GEM_NO_CPU_ACCESS/AMDGPU_GEM_CREATE_NO_CPU_ACCESS flag when
allocating non-linear buffers, signalling to the kernel driver that CPU
access to the buffer doesn't need to work. At least the amdgpu kernel
driver actually enforces thi
he option will be "helpfully" removed from the linker flags and
> linking will fail.
>
> You can find the entire series at
> https://cgit.freedesktop.org/~nh/mesa/log/?h=ubsan
> Please review!
Patches 1, 2, 6, 8 & 9 are
Reviewed-by: Michel Dänzer <michel.daen..
On 23.04.2016 07:24, Marek Olšák wrote:
> On Fri, Apr 22, 2016 at 11:28 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
>> On 22.04.2016 12:29, Nicolai Hähnle wrote:
>>> On 20.04.2016 23:02, Michel Dänzer wrote:
>>>> On 21.04.2016 02:42, Marek Olšák wrote:
&
of LLVM a
while ago, worked fine. (I also confirmed that it breaks with older
versions of LLVM which didn't use versioned symbols)
There may be other cases which still break even with versioned symbols
though.
--
Earthling Michel Dänzer | http://www.amd.com
Libre
Egbert Eich <e...@suse.com>
Please set the Git author field itself to Egbert Eich <e...@suse.com> then.
With that fixed,
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
Do you need somebody to push this patch for you?
P.S. Looks like at least glx_dri3_get_dri_context may need t
From: Michel Dänzer <michel.daen...@amd.com>
Fixes make check.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/egl/egl-symbols-check | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/egl/egl-symbols-check b/src/egl/egl-symbols-check
index 5d46fed..fd20948 1007
On 21.04.2016 02:42, Marek Olšák wrote:
> On Thu, Apr 14, 2016 at 9:29 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 14.04.2016 11:37, Michel Dänzer wrote:
>>> On 12.04.2016 21:33, Marek =?UNKNOWN?B?T2zFocOhaw==?= wrote:
>>>>
>>>> URL:
&
On 20.04.2016 17:48, Oded Gabbay wrote:
> On Wed, Apr 20, 2016 at 11:28 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 20.04.2016 03:13, Oded Gabbay wrote:
>>> On Tue, Apr 19, 2016 at 5:59 PM, Marek Olšák <mar...@gmail.com> wrote:
>>>> On Tue, Apr
On 19.04.2016 00:55, Nicolas Dufresne wrote:
> Le lundi 18 avril 2016 à 11:40 +0900, Michel Dänzer a écrit :
>> On 17.04.2016 09:49, nico...@ndufresne.ca wrote:
>>>
>>> From: Nicolas Dufresne <nicolas.dufre...@collabora.com>
>>>
>>> Sorry for
gt;> second field). This would be a very far-reaching change though, and I
>>>> doubt you'll want to do it. What we're left with is having a format
>>>> and an *implicit* endianness. Which means that the consumers of the
>>>> format need to be
s Tom mentioned, I kindly ask to leave the possibility
of dynamically linking LLVM.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-d
specify an instruciton can only produce the values
Typo: instruciton -> instruction
It would also be nice to always write LDS instead of lds in the commit
log of patch 4, but either way, with the above typo fixed, the series is
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
Nice work
4
PIGLIT: {"result": "fail" }
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedeskt
in which case there's a bug that needs to be
fixed, not hacked around), endianness doesn't come into play for that.
Also, what you're describing above isn't really necessary (from a
make-it-work POV, as opposed to a
make-the-format-model-complete-and-consistent POV) for formats such as
R
2 to PIPE_FORMAT conversion
> gallium/dri2: Fix RGB565 EGLImage creation
>
> src/gallium/state_trackers/dri/dri2.c | 105
> +-
> 1 file changed, 51 insertions(+), 54 deletions(-)
The series is
Reviewed-by: Michel Dänzer <michel.daen...@a
On 16.04.2016 19:20, Marek Olšák wrote:
> On Sat, Apr 16, 2016 at 8:04 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 16.04.2016 14:51, Michel Dänzer wrote:
>>> On 16.04.2016 11:39, Tom Stellard wrote:
>>>> The ds_bpermute instruction allows threads to tr
On 16.04.2016 14:51, Michel Dänzer wrote:
> On 16.04.2016 11:39, Tom Stellard wrote:
>> The ds_bpermute instruction allows threads to transfer data directly
>> to or from the vgprs of other threads. These instructions use the lds
>> hardware to transfer data, but do not rea
| LDS: 0 blocks
Nice.
Were these intrinsics already available in LLVM 3.6? If not, the old
code needs to be kept for backwards compatibility.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X
where, instead of adding partial hacks
on top of each other. I'm sorry that this is painful (I did warn you
before you started on this journey that it could be long and painful),
but I don't see any clean way around it.
[0] See the PIPE_ARCH_BIG/LITTLE_ENDIAN sections in p_format.h for
endian d
On 14.04.2016 11:37, Michel Dänzer wrote:
> On 12.04.2016 21:33, Marek =?UNKNOWN?B?T2zFocOhaw==?= wrote:
>>
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=5a4b74d1ba2c156766a7a5dbfef099c7db5d6694
>> Author: Marek Olšák <marek.ol...@amd.com>
&g
On 14.04.2016 03:59, Francisco Jerez wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> createInternalizePass now takes a callback instead of a StringSet.
>>
>> Signed-off-by: Michel Dänzer
quot;: {"image1DArray max size test/8x2048x1x1" : "fail"}}
PIGLIT: {"subtest": {"image2DArray max size test/16384x8x8x1" : "pass"}}
PIGLIT: {"subtest": {"image2DArray max size test/8x16384x8x1" : "pass"}}
PIGLIT: {&qu
;> +
>> + if (shader->config.scratch_bytes_per_wave)
>> + min_sgprs += 2; /* scratch wave offset */
>
> Sorry, this should be += 1.
With that fixed, this series is
Reviewed-and-Tested-by: Michel Dänzer <michel.daen...@amd
XTURE_GATHER_COMPONENTS:
> return 4;
> + case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> + return HAVE_LLVM >= 0x0309 ? 4 : 0;
>
> case PIPE_CAP_GLSL_FEATURE_LEVEL:
> return HAVE_LLVM >= 0x0309 ? 420 :
>
Reviewed-by: Michel Dänzer <michel.da
thling 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
From: Michel Dänzer <michel.daen...@amd.com>
createInternalizePass now takes a callback instead of a StringSet.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 17 +
1 file changed, 17 insertions(+)
but that's orthogonal to Ian's request (which I support), which
is that this setting should be controllable via ~/.drirc, mostly because
that allows per-app configuration.
It doesn't seem like many people are still using or even know about the
driconf app anymore.
--
Earthling Michel Dänzer
On 12.04.2016 16:31, Oded Gabbay wrote:
> On Tue, Apr 12, 2016 at 10:21 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 11.04.2016 23:34, Oded Gabbay wrote:
>>> This patch adds a new field, called "endian_format", to
>>> "struct pipe_resou
s (state tracker layer).
That shouldn't matter if the formats are defined completely and their
usage is consistent across the board. Sounds like either or both of
those conditions aren't completely true yet. I agree with Roland that
this should be addressed fundamentally rather than adding more hac
K for this one too.
I'd be interested in a specific justification for NAKing this version.
Seems to me like this might be the best that can be done.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
701 - 800 of 2182 matches
Mail list logo
