Quoting Adam Jackson (2018-09-28 12:59:16)
> s390 doesn't have working llvm, so llvmpipe isn't an option. softpipe
> might be more featureful but classic swrast is faster. s390x has working
> llvm so we can build llvmpipe there.
>
> ppc doesn't have working llvm either (so give it classic swrast
On Fri, Sep 28, 2018 at 4:27 PM Samuel Pitoiset
wrote:
>
> Like we disable DCC/CMASK for small color surfaces as well.
> Serious Sam 2017 creates a 1x1 depth surface and I think
> it should be faster to decompress compared to the benefit
> of fast clears.
I don't think the last sentence rolls
s390 doesn't have working llvm, so llvmpipe isn't an option. softpipe
might be more featureful but classic swrast is faster. s390x has working
llvm so we can build llvmpipe there.
ppc doesn't have working llvm either (so give it classic swrast too),
but at least it has a PCI bus you could maybe
For gallium drivers where you want to do some linking at variant compile
time, you don't have the other producer/consumer shader on hand to modify.
By exposing the inner function, the driver can have the used varyings in
the compiled shader cache key and still do linking.
This is also useful for
Fixes assertion failures when calling nir_remove_unused_varyings() or
nir_remove_unused_io_vars().
---
src/compiler/nir/nir_linking_helpers.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/compiler/nir/nir_linking_helpers.c
b/src/compiler/nir/nir_linking_helpers.c
index
> > Where should new contributions go?
> >
> > - pig...@lists.freedesktop.org
> > - mesa-dev@lists.freedesktop.org
> > - merge requests in GitLab
>
> Yes; I believe GitLab MR are now used for crucible development.
Thanks for the clarification.
Created
On Fri, Sep 21, 2018 at 10:37:38PM +0200, Jason Ekstrand wrote:
> Wiring up TCS in some other driver?
Pushed early this week. It was for Iris :-)
Thanks,
Caio
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On 09/25/2018 11:12 PM, Thomas Helland wrote:
> Hi Ian,
>
> Do you have these in a branch somewhere?
> Do you also have a branch somewhere of the PRE for compares?
Both patch series are in the partial-redundancy-elimination-compares of
my fd.o repo.
> I'll try to have a look at these, and the
On Fri 28 Sep 2018, Jason Ekstrand wrote:
> We don't support the protected memory feature but it's easy enough to
> fill out the properties struct to say that we don't support no-fault
> either.
>
> Fixes: 9c8b40001dde9 "anv: Support querying for protected memory"
> ---
>
Reviewed-by: Bas Nieuwenhuizen
On Fri, Sep 28, 2018 at 5:02 PM Jason Ekstrand wrote:
>
> We don't support the protected memory feature but it's easy enough to
> fill out the properties struct to say that we don't support no-fault
> either.
>
> Fixes: 9c8b40001dde9 "anv: Support querying for
We don't support the protected memory feature but it's easy enough to
fill out the properties struct to say that we don't support no-fault
either.
Fixes: 9c8b40001dde9 "anv: Support querying for protected memory"
---
src/intel/vulkan/anv_device.c | 7 +++
1 file changed, 7 insertions(+)
tl;dr VK_EXT_image_drm_format_modifier will be in the next weekly
release of the Vulkan spec. But only in the git repo (asciidoc + xml)
not the official html spec nor headers. It should be enabled in the html
and headers in the following week.
...
Hi everyone, VK_EXT_image_drm_format_modifier is
Like we disable DCC/CMASK for small color surfaces as well.
Serious Sam 2017 creates a 1x1 depth surface and I think
it should be faster to decompress compared to the benefit
of fast clears.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_image.c | 4 +++-
1 file changed, 3
If apps use the MUTABLE bit and the same formats as the image one
in the list, we can still enable TC-compat HTILE. I don't think
this happens often but given the fact that TC-compat HTILE allows
a nice boost in some situations, it's worth checking.
Signed-off-by: Samuel Pitoiset
---
Last time I tried these nothing change, but
Reviewed-by: Bas Nieuwenhuizen
for the series.
On Fri, Sep 28, 2018 at 12:28 PM Samuel Pitoiset
wrote:
>
> Other drivers set these two as well, just apply the same rule.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_pipeline.c | 4
Unnecessary. While we are at it, remove the check for pre-VI
because it's already checked earlier.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
Hi all,
On Fri, 21 Sep 2018 at 20:59, Daniel Stone wrote:
> On Wed, 29 Aug 2018 at 11:13, Juan A. Suarez Romero
> wrote:
> > This is a first part, version 2, of a more complete proposal to use GitLab
> > CI to
> > build and test Mesa. This first part just adds the required pieces to build
> >
I don't think this is required by Vulkan too.
Ported from RadeonSI (AMDVLK doesn't set it either).
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index
Other drivers set these two as well, just apply the same rule.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 94688997b4..4b626a59af
19 matches
Mail list logo
