The compiler configuration was hardened to fail on format warnings and
things stopped building.
Fixes: c9c1e2610647 ("mesa: prevent common string formatting security issues")
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/bifrost/disassemble.c | 2 +-
1 file changed, 1 insertion(+)
https://bugs.freedesktop.org/show_bug.cgi?id=110345
Riikka changed:
What|Removed |Added
CC|princessrii...@gmail.com|
--- Comment #39 from Riikka ---
To my embarr
Most of the series looks reasonable to me besides the few comments added.
That said looking back at the patch you committed I don't think we
revert to the default locations the right way.
We return early from radv_update_multisample_state if the old pipeline
has the same number of samples, which
On Thu, May 30, 2019 at 4:02 PM Samuel Pitoiset
wrote:
>
> From the Vulkan spec 1.1.109:
>
>"Some implementations may need to evaluate depth image values
> while performing image layout transitions. To accommodate this,
> instances of the VkSampleLocationsInfoEXT structure can be
>
On Thu, May 30, 2019 at 4:02 PM Samuel Pitoiset
wrote:
>
> This will be used for the depth decompress pass that might need
> to emit variable sample locations during layout transitions.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_meta.c | 20
> src/amd/vul
From: Marek Olšák
It skipped slab allocators and the buffer cache.
v2: use only 1 domain for texture allocation
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110781
Cc: 19.1
---
src/gallium/drivers/r300/r300_query.c | 3 ++-
src/gallium/drivers/r300/r300_render.c|
On Tue, Jun 4, 2019 at 12:59 AM Juan A. Suarez Romero
wrote:
>
> On Thu, 2019-05-30 at 21:48 +, Vinson Lee wrote:
> > ../src/freedreno/vulkan/tu_device.c:900:4: error: initializer element is
> > not constant
> > .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
> > ^
> >
>
> Sh
Repacking components in certain pixel formats before compression
shouldn't be done for EHL to keep the compatibility with decompression
capability in its display controller.
Signed-off-by: Dongwon Kim
---
src/gallium/drivers/iris/iris_state.c | 10 +
src/intel/dev/gen_device_info.c
On Tue, 2019-06-04 at 16:52 +0200, Connor Abbott wrote:
> On Tue, Jun 4, 2019 at 4:24 PM Juan A. Suarez Romero
> wrote:
> > On Fri, 2019-05-31 at 14:55 +0200, Connor Abbott wrote:
> > > Bindless handles in GL are 64-bit. This fixes an assert failure in LLVM.
> >
> > Does it make sense to nominate
On Tue, Jun 4, 2019 at 4:24 PM Juan A. Suarez Romero
wrote:
>
> On Fri, 2019-05-31 at 14:55 +0200, Connor Abbott wrote:
> > Bindless handles in GL are 64-bit. This fixes an assert failure in LLVM.
>
> Does it make sense to nominate this for stable release?
I don't think so, since radeonsi NIR sti
On Fri, 2019-05-31 at 14:55 +0200, Connor Abbott wrote:
> Bindless handles in GL are 64-bit. This fixes an assert failure in LLVM.
Does it make sense to nominate this for stable release?
J.A.
> ---
>
> With this patch, we now have Piglit parity in debug mode.
>
> src/gallium/drivers/r
On Tue, Jun 4, 2019, 1:29 AM Jan Vesely wrote:
> On Tue, 2019-06-04 at 00:20 -0400, Marek Olšák wrote:
> > This series will probably conflict with the new linker, which will
> > also
> > handle relocations and more:
> >
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork
On Thu, 2019-05-30 at 21:48 +, Vinson Lee wrote:
> ../src/freedreno/vulkan/tu_device.c:900:4: error: initializer element is not
> constant
> .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
> ^
>
Shouldn't this be nominated to stable?
J.A.
> Suggested-by: Kristian
I don't see the code question, but I do see uses of the "inline" keyword in
ImageMagick. C99 inline does not mean what everyone seems to think it means,
and is not really a demand or even request to inline the function.
For example at -O1 on x86, this gives:
inline void bar(global int* arg) {
14 matches
Mail list logo
