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) {
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
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 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 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 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
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, 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
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 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
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
>
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
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
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(+)
14 matches
Mail list logo
