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
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 src/vulkan/wsi/wsi_common_display.
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 on
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 ++--
src/gallium/drivers/nouveau
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 +++
.../drivers/nouveau/nvc0/nvc0_context
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 +-
.../nouveau/codegen/nv50_ir_e
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 +
.../drivers/nouveau/c
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
nee
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 compa
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
nee
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 synchro
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 nee
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
> >>
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:
> > > >
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 disp
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 (lik
16 matches
Mail list logo
