Makes sense to me.
Acked-by: Nicolai Hähnle
-Original Message-
From: Connor Abbott
Sent: Dienstag, 18. Juni 2019 15:21
To: mesa-dev@lists.freedesktop.org
Cc: Marek Olšák ; Haehnle, Nicolai ;
Connor Abbott
Subject: [PATCH] ac,radeonsi: Always mark buffer stores as inaccessiblememonly
The following hunk needs to be added:
> @@ -503,7 +521,9 @@ static bool resolve_symbol(const struct
> ac_rtld_upload_info *u,
>unsigned part_idx, const Elf64_Sym *sym,
>const char *name, uint64_t *value)
> {
> - if (sym->st_shndx ==
On 14.06.19 18:46, Mauro Rossi wrote:
> Fix android building errors in winsys/amdgpu and radv
> due to 'amdgfxregs.h' not found.
Thanks!
Reviewed-by: Nicolai Hähnle
>
> Changelog:
> amd/common - generated $(intermediated)/common path is added to exports
> winsys/amdgpu - libmesa_amd_common
This approach seems entirely incompatible with si_debug_options.h, and
will be an absolute maintenance nightmare going forward for adding /
removing options, because you're introducing a second location where
options are defined.
Quite frankly, this seems like a terrible idea as-is.
If you
This is basically the same issue as with patch #3... it's not so clear
what the best policy actually is.
Cheers,
Nicolai
On 05.05.19 01:24, Caio Marcelo de Oliveira Filho wrote:
> Hi,
>
>>> diff --git a/src/util/u_dynarray.h b/src/util/u_dynarray.h
>>> index b30fd7b1154..f6a81609dbe 100644
>>>
On 04.05.19 17:55, Gustaw Smolarczyk wrote:
> sob., 4 maj 2019 o 15:25 Nicolai Hähnle napisał(a):
>> static inline void
>> util_dynarray_clone(struct util_dynarray *buf, void *mem_ctx,
>> struct util_dynarray *from_buf)
>> {
>> util_dynarray_init(buf, mem_ctx);
>>
On 05.05.19 01:19, Bas Nieuwenhuizen wrote:
>> /* use util_dynarray_trim to reduce the allocated storage */
>> static inline void *
>> -util_dynarray_resize(struct util_dynarray *buf, unsigned newsize)
>> +util_dynarray_resize_bytes(struct util_dynarray *buf, unsigned nelts,
>> size_t
On 03.05.19 12:36, Nicolai Hähnle wrote:
> On 25.04.19 13:18, Nicolai Hähnle wrote:
>> @@ -4618,21 +4648,27 @@ static void si_bind_vertex_elements(struct
>> pipe_context *ctx, void *state)
>> struct si_vertex_elements *old = sctx->vertex_elements;
>> struct si_vertex_elements *v =
On 25.04.19 13:18, Nicolai Hähnle wrote:
> @@ -4618,21 +4648,27 @@ static void si_bind_vertex_elements(struct
> pipe_context *ctx, void *state)
> struct si_vertex_elements *old = sctx->vertex_elements;
> struct si_vertex_elements *v = (struct si_vertex_elements*)state;
>
>
Thanks!
On 06.02.19 01:27, Timothy Arceri wrote:
> On 4/2/19 11:26 pm, Nicolai Hähnle wrote:
>> On 01.02.19 05:25, Timothy Arceri wrote:
>>> On 26/1/19 11:56 am, Marek Olšák wrote:
Timothy, can you please test the attached fix?
>>>
>>> I'm having trouble compiling 32bit mesa on my machine at
On 17.12.18 04:23, Marek Olšák wrote:
> The definitions weren't changed, but the values were. The names need to
> be different, so that si_debug.c prints both the GFX6 and GFX9 values.
You're right. I have some larger changes of the debug printing that is
smarter about which fields to print
On 18.12.18 00:02, Bas Nieuwenhuizen wrote:
> Exactly what title says, the new addrlib does not allow the above with
> certain dimensions that the CTS seems to hit. Work around it by not
> allowing the app to render to it via compat with other 128bpp formats
> and do not render to it ourselves
On 18.12.18 18:36, Bas Nieuwenhuizen wrote:
> Hi Nicolai,
>
> I happened to be writing something similar which also fixes up radv to
> never render to those surfaces as r32g32b32a32:
> https://patchwork.freedesktop.org/series/54172/ I can split out the
> radv specific stuff and this one is r-b
On 10.12.18 12:36, Emil Velikov wrote:
> Hi Nicolai,
>
> On Thu, 6 Dec 2018 at 13:49, Nicolai Hähnle wrote:
>>
>> From: Nicolai Hähnle
>>
>> Linking against LLVM built with BUILD_SHARED_LIBS fails otherwise,
>> as the component is required for the draw module.
>
> I'd imagine we'd want this
On 06.12.18 15:20, Connor Abbott wrote:
> Is this going to be used by an extension? If you don't have a use for
> it yet, it would probably be better to wait.
Well, I have been using it quite extensively in a branch I've been
working on, but that's not quite ready yet.
Cheers,
Nicolai
> On
We really need to reduce the number of build systems in Mesa :/
Reviewed-by: Nicolai Hähnle
On 30.11.18 23:48, Mauro Rossi wrote:
> Needed to fix build error in addrlib in mesa for Android
>
> Fixes: 776b911 ("amd/addrlib: update Mesa's copy of addrlib")
> Signed-off-by: Mauro Rossi
> ---
>
Both patches:
Reviewed-by: Nicolai Hähnle
On 26.11.18 20:18, Ian Romanick wrote:
> From: Ian Romanick
>
> Ralloc has a feature that all allocations from a temporary memory
> context can be whisked away in a single call without fear of leaks. As
> the slab allocator is designed for use in
Thanks. Any comments on the addrlib change itself?
Cheers,
Nicolai
On 21.11.18 21:32, Marek Olšák wrote:
> See what Gustaw said. Other than that:
>
> Reviewed-by: Marek Olšák mailto:marek.ol...@amd.com>>
>
> Marek
>
> On Wed, Nov 21, 2018 at 10:21 AM Nicolai Hähnle
On 22.11.18 06:40, Tomasz Figa wrote:
> Hi Brian, Keith,
>
> +Some more Chromium folks for visibility.
>
> On Wed, Aug 22, 2018 at 4:21 PM Tomasz Figa wrote:
>>
>> Hi Michel,
>>
>> On Thu, Aug 16, 2018 at 6:43 PM Michel Dänzer wrote:
>>>
>>> On 2018-08-16 11:34 AM, Tomasz Figa wrote:
If
On 21.11.18 22:23, Ian Romanick wrote:
> On 11/21/2018 12:23 PM, Haehnle, Nicolai wrote:
>> On 21.11.18 19:19, Ian Romanick wrote:
>>> On 11/21/2018 03:08 AM, Haehnle, Nicolai wrote:
>>>> On 21.11.18 01:39, Ian Romanick wrote:
>>>>> From: Ian Romani
On 21.11.18 19:19, Ian Romanick wrote:
> On 11/21/2018 03:08 AM, Haehnle, Nicolai wrote:
>> On 21.11.18 01:39, Ian Romanick wrote:
>>> From: Ian Romanick
>>>
>>> Ralloc has a feature that all allocations from a temporary memory
>>> context can
On 21.11.18 12:08, Nicolai Hähnle wrote:
> On 21.11.18 01:39, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Ralloc has a feature that all allocations from a temporary memory
>> context can be whisked away in a single call without fear of leaks. As
>> the slab allocator is designed for use in
On 21.11.18 01:39, Ian Romanick wrote:
> From: Ian Romanick
>
> Ralloc has a feature that all allocations from a temporary memory
> context can be whisked away in a single call without fear of leaks. As
> the slab allocator is designed for use in multhreaded scenarios with a
> child pool per
On 08.11.18 20:39, Samuel Pitoiset wrote:
>
>
> On 11/8/18 4:15 PM, Nicolai Hähnle wrote:
>> From: Nicolai Hähnle
>>
>> Helpful for debugging compiler backend problems: this allows us to
>> easily retrieve the LLVM IR from RenderDoc.
>> --
>> For the peanut gallery: AMD's official stance on
On 31.10.18 21:41, Marek Olšák wrote:
> Instead of saying that, you should say "Mesa should be slower with most
> apps, so that we don't decrease perf for 2 apps too much", because
> that's what you are saying. It seems like you have some limited belief
> that only allows you to see the problem
On 05.11.18 05:48, Veluri Mithun wrote:
> Sry for the late, I had internal exams last month.
>
> the EGL version of the extension to the new document. The EGL enums
> will probably be different, so maybe replace the enum values with 0x
> for now.
>
> What are these tokens(enum
Hi Veluri,
On 07.10.2018 21:31, Veluri Mithun wrote:
> All these days I worked on packaging since I didn't find much time last
> month in my new academic schedule, I finished it if you wish you may
> download it
> here(https://flathub.org/apps/details/br.com.jeanhertel.adriconf).
> Currently,
27 matches
Mail list logo
