https://bugs.freedesktop.org/show_bug.cgi?id=105444
Tapani Pälli changed:
What|Removed |Added
CC||lem...@gmail.com
--
From: Dave Airlie
In order to deal with conversions properly we need to extract
non-64bit sources from vectors instead of expanding them as
the 64-bit code does.
We need non-64bit sources for the 32->64 conversion functions.
Signed-off-by: Dave Airlie
From: Dave Airlie
In order to handle d2u etc we need to handle the case where the dest
is 32-bit. Instead of compacting things, we just want to mere
the results into a single vector.
Signed-off-by: Dave Airlie
---
src/compiler/glsl/lower_64bit.cpp | 27
From: Elie Tournier
This can also be used to lower some double ops.
[airlied:
this is extract from Elie's work into a standalone patch]
Signed-off-by: Dave Airlie
---
src/compiler/Makefile.sources | 2 +-
From: Dave Airlie
This picks the correct double packing and unpacking function,
and type to unpack into.
Signed-off-by: Dave Airlie
---
src/compiler/glsl/lower_64bit.cpp | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff
From: Dave Airlie
This will ensure the upcoming changes don't start lowering
doubles using int64 functions.
Signed-off-by: Dave Airlie
---
src/compiler/glsl/lower_64bit.cpp | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
From: Dave Airlie
If this function saw a 32-bit source it would just return the
IR without doing any conversion, this adds the ability to denote
where 32-bit sources are expected and will be used in subsequent
patches to add 32->64 conversions.
Signed-off-by: Dave Airlie
I've been fixing up Elie's work and although the produced shaders are large,
and really show up the copy prop and sb liveness passes as horrible inefficent
when you have lots of if statements, I think we should start angling towards
upstreaming it.
It now passes 99% of the piglit tests on r600
Did anything ever comes of this series, trying some soft fp64 shaders,
and glsl copy opt is taking 2-3 seconds on the big ones.
Nearly all spent in hash table insertions.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
From: Dave Airlie
This fixes an illegal command buffer on the host seen with
piglit arb_internalformat_query2-max-dimensions
Signed-off-by: Dave Airlie
---
src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 8 ++--
https://bugs.freedesktop.org/show_bug.cgi?id=105444
Jordan Justen changed:
What|Removed |Added
Status|NEW |NEEDINFO
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=105444
Jordan Justen changed:
What|Removed |Added
CC||jljus...@gmail.com,
https://bugs.freedesktop.org/show_bug.cgi?id=105444
Bug ID: 105444
Summary: Enable GL disk shader cache when transform feedback is
enabled
Product: Mesa
Version: git
Hardware: Other
OS: All
This change allows the disk shader cache to work with programs loaded
with ProgramBinary. Drivers check for LINKING_SKIPPED, and if set,
then they try to use the shader cache.
Since the program loaded by ProgramBinary is similar to loading the
shader from the disk cache, this is probably more
git://people.freedesktop.org/~jljusten/mesa program-binary-shader-cache
I found that when running DOTA2, most programs were skipping the
shader cache. It appears that since DOTA2 uses ARB_get_program_binary,
the programs loaded with ProgramBinary set the LinkStatus to
LINKING_SUCCESS.
Currently
When the shader cache is used, this can be generated. In fact, the
shader cache uses this sha1 to lookup the serialized GL shader
program.
If a GL shader program is restored with ProgramBinary, the shaders are
not available, and therefore the correct sha1 cannot be generated. If
this is restored,
From: Dave Airlie
I'm not sure everyone wants to be updating their dri3 in a forced
march setting, this allows a nicer approach, esp when you want
to build on distro that aren't brand new.
I'm sure there are plenty of ways this patch could be cleaner,
and I've also not built
On 10 March 2018 at 02:21, Bas Nieuwenhuizen wrote:
> The vulkan API is not ideal as it does not allow us have a
> shared limit.
>
> Feral needs 15+6 for one of their games, and I'm not a fan
> of overcommitting the limits, so increase the number of
> dynamic uniform
From: Dave Airlie
I'm not sure everyone wants to be updating their dri3 in a forced
march setting, this allows a nicer approach, esp when you want
to build on distro that aren't brand new.
I'm sure there are plenty of ways this patch could be cleaner,
and I've also not built
https://bugs.freedesktop.org/show_bug.cgi?id=100259
Daniel Stone changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=105441
Daniel Stone changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=105441
Humberto Israel Perez Rodriguez changed:
What|Removed |Added
Priority|medium
https://bugs.freedesktop.org/show_bug.cgi?id=105441
Bug ID: 105441
Summary: [MESA] unable to compile mesa with latest commits
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Please ignore patches 4 & 5. Patch 5 breaks gl-1.0-readpixsanity.
Marek
On Sun, Mar 11, 2018 at 2:11 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/auxiliary/util/u_blitter.c | 14 ++
> src/gallium/auxiliary/util/u_blitter.h
From: Marek Olšák
---
src/gallium/auxiliary/util/u_blitter.c | 14 ++
src/gallium/auxiliary/util/u_blitter.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/auxiliary/util/u_blitter.c
index
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_test_dma.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_test_dma.c
b/src/gallium/drivers/radeonsi/si_test_dma.c
index 779572e..76a3193 100644
From: Marek Olšák
The improvement is +3.5%, not much.
---
src/gallium/drivers/radeonsi/si_pipe.h | 9 +
src/gallium/drivers/radeonsi/si_state.c | 22 ++
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git
From: Marek Olšák
This should improve the score for the GpuTest Triangle benchmark.
Vulkan doesn't use this either.
---
src/gallium/drivers/radeon/r600_pipe_common.h | 1 -
src/gallium/drivers/radeon/r600_texture.c | 11 +---
src/gallium/drivers/radeonsi/si_clear.c
From: Marek Olšák
---
src/amd/common/ac_surface.c| 85 +-
src/amd/common/ac_surface.h| 6 +-
src/gallium/drivers/radeon/r600_texture.c | 1 +
src/gallium/winsys/amdgpu/drm/amdgpu_surface.c | 2 +
4
On 2018-02-20 — 22:02, Karol Herbst wrote:
> v4: treat imul as unsigned
> v5: remove pointless !!
>
> Signed-off-by: Karol Herbst
> ---
> .../drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 117
> +
> 1 file changed, 117 insertions(+)
>
> diff --git
Quoting Alejandro Piñeiro (2018-03-08 07:00:16)
> Ideally this should be generated somehow. One option would be gather
> all the extension dependencies listed on the core grammar, but there
> would be the possibility of not including some of the extensions.
>
> Note that spirv-tools is doing it
https://bugs.freedesktop.org/show_bug.cgi?id=103852
Sven Arvidsson changed:
What|Removed |Added
CC||s...@whiz.se
---
Reviewed-by: Marek Olšák
Marek
On Thu, Mar 8, 2018 at 3:20 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This fixes a memory trashing crash (not the test) seen with
> dEQP-GLES3.stress.draw.unaligned_data.random.203
> on virgl.
>
>
On 2018-02-20 — 22:02, Karol Herbst wrote:
> v2: add constant_folding
>
> Signed-off-by: Karol Herbst
> ---
> .../drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 40
> ++
> 1 file changed, 40 insertions(+)
>
> diff --git
On Thu, Mar 8, 2018 at 5:48 PM, Ian Romanick wrote:
> On 03/08/2018 06:50 AM, Samuel Pitoiset wrote:
>> This pass moves load UBO operations just before their first use,
>> loosely based on nir_opt_move_comparisons.
>
> If I'm reading this correctly, it moves UBO loads closer
FWIW, this is the patch that Im more interested to get a review. It is
also the one that probably would need some discussion. Fortunately this
one can be reviewed independently of the rest of the patches, so the
others can wait a little. Getting this into would make the rebase of
this series more
https://bugs.freedesktop.org/show_bug.cgi?id=105436
Ilia Mirkin changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop.
On Thu, Mar 8, 2018 at 9:08 AM, Samuel Pitoiset
wrote:
> RadeonSI does something similar, the VGPRs decrease is a win
> but not sure if we really want to implement that.
>
> Polaris10:
> Totals from affected shaders:
> SGPRS: 116376 -> 116768 (0.34 %)
> VGPRS: 76556 ->
https://bugs.freedesktop.org/show_bug.cgi?id=105436
Bug ID: 105436
Summary: Blinking textures in UT2004
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority:
39 matches
Mail list logo