Re: [Mesa-dev] Why do vulkan display surfaces not support alpha blending?

2020-03-19 Thread Keith Packard
Austin Shafer writes: > I'm just curious if there is a technical reason why blending isn't > allowed, as the vulkan spec seems to permit it. Just not implemented yet. -- -keith signature.asc Description: PGP signature ___ mesa-dev mailing list

[Mesa-dev] Why do vulkan display surfaces not support alpha blending?

2020-03-19 Thread Austin Shafer
Hi all, I noticed on an intel laptop that the only supported alpha mode for any display plane is opaque. Is there a specific reason for this? I'm trying to draw interfaces and things direct to the display and it would be really nice to have alpha blending. >From

[Mesa-dev] [RFC PATCH v2 6/6] nv50: Add shader disk caching

2020-03-19 Thread Mark Menzynski
Adds shader disk caching for nv50 to reduce the need to every time compile shaders. Shaders are saved into disk_shader_cache from nv50_screen structure. It serializes the input nv50_ir_prog_info to compute the hash key and also to do a byte compare between the original nv50_ir_prog_info and the

[Mesa-dev] [RFC PATCH v2 1/6] nv50/ir: add nv50_ir_prog_info_out

2020-03-19 Thread Mark Menzynski
From: Karol Herbst Split out the output relevant fields from the nv50_ir_prog_info struct in order to have a cleaner separation between the input and output of the compilation. Signed-off-by: Karol Herbst --- .../drivers/nouveau/codegen/nv50_ir.cpp | 49 ++--

[Mesa-dev] [RFC PATCH v2 4/6] nv50/ir: Add nv50_ir_prog_info serialize

2020-03-19 Thread Mark Menzynski
Adds a function for serializing a nv50_ir_prog_info structure, which is needed for shader caching. Signed-off-by: Mark Menzynski --- .../drivers/nouveau/codegen/nv50_ir_driver.h | 4 + .../nouveau/codegen/nv50_ir_serialize.cpp | 81 +++

[Mesa-dev] [RFC PATCH v2 2/6] nv50/ir: Add nv50_ir_prog_info_out serialize and deserialize

2020-03-19 Thread Mark Menzynski
Adds functions for serializing and deserializing nv50_ir_prog_info_out structure, which are needed for shader caching. Signed-off-by: Mark Menzynski --- .../drivers/nouveau/codegen/nv50_ir_driver.h | 44 .../nouveau/codegen/nv50_ir_emit_gk110.cpp| 14 +-

[Mesa-dev] [RFC PATCH v2 3/6] nv50/ir: Add prog_info_out print

2020-03-19 Thread Mark Menzynski
Adds a function for printing nv50_ir_prog_info_out structure in JSON-like format, which could be used in debugging. Signed-off-by: Mark Menzynski --- .../nouveau/codegen/.nv50_ir_from_nir.cpp.swp | Bin 0 -> 16384 bytes .../drivers/nouveau/codegen/nv50_ir_driver.h | 3 +

[Mesa-dev] [RFC PATCH v2 5/6] nv50: Add separate functions for varying bits

2020-03-19 Thread Mark Menzynski
This separation will be needed for shader disk caching. The reason for it is that when loading shaders from cache, data in info structure already gets loaded. That means varying bits for info is needed only when compiling shaders and not needed when loading from cache. Varying bits for prog are

[Mesa-dev] [RFC PATCH 2/2] nv50: Add shader disk caching

2020-03-19 Thread Mark Menzynski
Adds shader disk caching for nv50 to reduce the need to every time compile shaders. Shaders are saved into disk_shader_cache from nv50_screen structure. It can be disabled with MESA_GLSL_CACHE_DISABLE=1. It serializes the input nv50_ir_prog_info to compute the hash key and also to do a byte

[Mesa-dev] [RFC PATCH 1/2] nv50: Add separate functions for varying bits

2020-03-19 Thread Mark Menzynski
This separation will be needed for shader disk caching. The reason for it is that when loading shaders from cache, data in info structure already gets loaded. That means varying bits for info is needed only when compiling shaders and not needed when loading from cache. Varying bits for prog are

Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem

2020-03-19 Thread Marek Olšák
On Thu., Mar. 19, 2020, 06:51 Daniel Vetter, wrote: > On Tue, Mar 17, 2020 at 11:01:57AM +0100, Michel Dänzer wrote: > > On 2020-03-16 7:33 p.m., Marek Olšák wrote: > > > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer > wrote: > > >> On 2020-03-16 4:50 a.m., Marek Olšák wrote: > > >>> The

Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem

2020-03-19 Thread Adam Jackson
On Tue, 2020-03-17 at 10:12 -0700, Jacob Lifshay wrote: > One related issue with explicit sync using sync_file is that combined > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the > rendering in userspace (like llvmpipe but for Vulkan and with extra > instructions for GPU tasks) but

Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem

2020-03-19 Thread Daniel Vetter
On Tue, Mar 17, 2020 at 11:01:57AM +0100, Michel Dänzer wrote: > On 2020-03-16 7:33 p.m., Marek Olšák wrote: > > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer wrote: > >> On 2020-03-16 4:50 a.m., Marek Olšák wrote: > >>> The synchronization works because the Mesa driver waits for idle (drains >

Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem

2020-03-19 Thread Daniel Vetter
On Tue, Mar 17, 2020 at 11:27:28AM -0500, Jason Ekstrand wrote: > On Tue, Mar 17, 2020 at 10:33 AM Nicolas Dufresne > wrote: > > > > Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit : > > > Hi Jason, > > > > > > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote: > > > >

Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem

2020-03-19 Thread Daniel Vetter
On Wed, Mar 18, 2020 at 11:05:48AM +0100, Michel Dänzer wrote: > On 2020-03-17 6:21 p.m., Lucas Stach wrote: > > That's one of the issues with implicit sync that explicit may solve: > > a single client taking way too much time to render something can > > block the whole pipeline up until the

Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem

2020-03-19 Thread Daniel Vetter
On Tue, Mar 17, 2020 at 12:18:47PM -0500, Jason Ekstrand wrote: > On Tue, Mar 17, 2020 at 12:13 PM Jacob Lifshay > wrote: > > > > One related issue with explicit sync using sync_file is that combined > > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the > > rendering in userspace