Just to allow to call set_is_lhs on any ast_node without a casting. Useful
when processing a ast_node list that we know it contain ast_expression.
v2: comment out new_value to avoid unused parameter warning (Ian Romanick)
---
src/compiler/glsl/ast.h | 2 ++
src/compiler/glsl/ast_to_hir.c
It executes compiler-glsl on all the available shaders, and it checks
that the outcome is the expected.
Bash code based on the already existing optimization-test
---
src/compiler/Makefile.glsl.am | 3 ++-
src/compiler/glsl/tests/warnings-test | 31 +++
2 files
Add an option in order to ask to just print the InfoLog, without any
header or separator. Useful if we want to use the standalone compiler
to track only the warning/error messages.
---
src/compiler/glsl/main.cpp | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --gi
It silence by default warnings with function parameters, as the
parameters need to be processed in order to have the actual and the
formal parameter, and the function signature. Then it raises the
warning if needed at verify_parameter_modes where other in/inout modes
checks are done.
v2: fix comme
---
.../glsl/tests/warnings/000-basic-test.vert| 10
.../tests/warnings/000-basic-test.vert.expected| 1 +
.../warnings/001-use-undefined-then-define.vert| 12 ++
.../001-use-undefined-then-define.vert.expected| 1 +
src/compiler/glsl/tests/warnings/002-loop.
This is a resubmit of the pending patches related with the uninitialized
warning, after two weeks since last comment.
This resubmit series merges two series hoping to make easier the review:
* Fix the false positive with function parameters, that got a first
review by Ian Romanick [1]
* U
On Thursday, April 28, 2016 1:40:35 PM PDT Antia Puentes wrote:
> From: "Juan A. Suarez Romero"
>
> VS Thread Payload handles attributes in URB as vec4, no matter if they
> are actually single or double precision.
>
> So with double-precision types, value ends up in the registers split in
> 32bi
On Thursday, April 28, 2016 3:21:43 PM PDT Ian Romanick wrote:
> On 04/28/2016 01:40 PM, Antia Puentes wrote:
> > From: Alejandro Piñeiro
> >
> > The HW has a restriction that only vertical stride may cross register
> > boundaries. Until now this was only handled on VGRFs at
> > rw_reg_from_fs_re
On 10/05/16 08:45, Kenneth Graunke wrote:
> On Thursday, April 28, 2016 1:40:44 PM PDT Antia Puentes wrote:
>> From: Alejandro Piñeiro
>>
>> ---
>> docs/GL3.txt | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/docs/GL3.txt b/docs/GL3.txt
>> index 95ee508..3f1f7a3 100644
On Thursday, April 28, 2016 1:40:40 PM PDT Antia Puentes wrote:
> From: "Juan A. Suarez Romero"
>
> Input attributes can require 2 vec4 or 1 vec4 depending on whether they
> are double-precision or not.
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 13 +
> src/mesa/drivers/dri/i96
On Tuesday, May 10, 2016 9:23:24 AM PDT Alejandro Piñeiro wrote:
> On 10/05/16 08:45, Kenneth Graunke wrote:
> > On Thursday, April 28, 2016 1:40:44 PM PDT Antia Puentes wrote:
> >> From: Alejandro Piñeiro
> >>
> >> ---
> >> docs/GL3.txt | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
Three Shadow of Mordor geometry shaders increase by a single
instruction, but the number of spills/fills in Orbital Explorer
is reduced from 194:1279 -> 82:454. No other programs are affected.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
1 file changed, 1 inse
On Tue, 2016-05-10 at 00:15 -0700, Kenneth Graunke wrote:
> On Thursday, April 28, 2016 1:40:35 PM PDT Antia Puentes wrote:
> >
> > From: "Juan A. Suarez Romero"
> >
> > VS Thread Payload handles attributes in URB as vec4, no matter if
> > they
> > are actually single or double precision.
> >
>
I'd originally left this off because Orbital Explorer was hanging the
GPU, but it seems to be working these days. There have been a bunch
of changes since then, so we probably fixed something.
On my Broadwell laptop, both Synmark/GSCloth and Orbital Explorer seem
to run at approximately the same
OK.
Reviewed-by: Marek Olšák
Marek
On Mon, May 9, 2016 at 10:41 PM, Bas Nieuwenhuizen
wrote:
> On Mon, May 9, 2016 at 9:55 PM, Marek Olšák wrote:
>> On Sun, May 8, 2016 at 1:00 PM, Bas Nieuwenhuizen
>> wrote:
>>> The calculated limit gave problems on SI as it was > 32 KiB
>>> and the hardwar
On Wed, 4 May 2016 10:22:35 +0100
Daniel Stone wrote:
> Hi Jonas,
>
> On 4 May 2016 at 09:53, Jonas Ådahl wrote:
> > When EGL is used on some other thread than the thread that drives the
> > main wl_display queue, the Wayland EGL dri2 implementation is
> > vulnerable to a race condition related
On 10.05.2016 13:00, Nicolai Hähnle wrote:
> On 30.04.2016 05:26, Michel Dänzer wrote:
>> On 28.04.2016 10:54, Michel Dänzer wrote:
>>> On 23.04.2016 07:24, Marek Olšák wrote:
On Fri, Apr 22, 2016 at 11:28 PM, Nicolai Hähnle
wrote:
> On 22.04.2016 12:29, Nicolai Hähnle wrote:
>>
Reviewed-by: Marek Olšák
Marek
On Sun, May 8, 2016 at 10:44 PM, Tobias Klausmann
wrote:
> This lets us safely enable or disable the extension as needed
>
> Signed-off-by: Tobias Klausmann
> Reviewed-by: Edward O'Callaghan
> ---
> src/gallium/docs/source/screen.rst | 2 ++
> src
Reviewed-by: Marek Olšák
Marek
On Sun, May 8, 2016 at 10:44 PM, Tobias Klausmann
wrote:
> Signed-off-by: Tobias Klausmann
> ---
> src/mesa/state_tracker/st_extensions.c | 1 +
> src/mesa/state_tracker/st_program.c| 40
> ++
> 2 files changed, 41 insertion
Reviewed-by: Marek Olšák
Marek
On Tue, May 10, 2016 at 5:36 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> The clamping code always clamps to 0..1, which for SNORM is
> incorrect. Just don't clamp at all in this case.
>
> This fixes a number of SNORM cases in:
> GL33-CTS.texture_size_promotion
Reviewed-by: Marek Olšák
Marek
On Tue, May 10, 2016 at 6:57 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This was colliding badly and making
> GL45-CTS.buffer_storage.map_persistent_texture
> fail on radeonsi.
>
> Signed-off-by: Dave Airlie
> ---
> src/mesa/main/dd.h | 2 +-
> 1 file chang
On 05/08/2016 10:44 PM, Tobias Klausmann wrote:
This enables ARB_cull_distance.
Signed-off-by: Tobias Klausmann
---
docs/GL3.txt| 2 +-
docs/relnotes/11.3.0.html | 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 ++
src/galli
On Monday 09 May 2016 21:25:20 Francisco Jerez wrote:
> Michel Dänzer writes:
> > On 10.05.2016 06:41, Francisco Jerez wrote:
> >> This file still only has my name on the copyright notice even though
> >> most of the code (likely more than 90% of it) was authored by various
> >> contributors -- It
On Tue, 2016-05-10 at 00:46 -0700, Kenneth Graunke wrote:
> I'd originally left this off because Orbital Explorer was hanging the
> GPU, but it seems to be working these days. There have been a bunch
> of changes since then, so we probably fixed something.
>
> On my Broadwell laptop, both Synmark
On Tue, 2016-05-10 at 00:46 -0700, Kenneth Graunke wrote:
> I'd originally left this off because Orbital Explorer was hanging the
> GPU, but it seems to be working these days. There have been a bunch
> of changes since then, so we probably fixed something.
>
> On my Broadwell laptop, both Synmark
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/05/16 20:59, Kenneth Graunke wrote:
> Other than patches 37, 56, and ones you agreed to drop, the series
> is: Reviewed-by: Kenneth Graunke
>
> I think you can go ahead and land all except those, and we can
> land new solutions for those pr
We always try to use 4-component loads, as LLVM does not combine loads
and they bypass the L1 cache.
We can't use a similar strategy for stores and this is especially
notable with the tess factors, as they are often set with separate
MOV's per component in the TGSI.
We keep storing to LDS and the
With potentially more than 1 wave working on a patch we
need the barrier.
Also adds a barrier before loading the tessellation factors to
write them to the TF ring.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_shader.c | 48 ++--
1 file changed
This patchset implements offchip tessellation after which we can finally process
more than one patch per wave without decreasing tessmark scores.
For tessmark this improves performance by ~20% for the x32 case and ~80% for the
x64 case. x8 and x16 have roughly the same performance as before. Unigi
Instead of creating a memory area per patch and per vertex, we put
the same attribute of every vertex & patch together. Most loads
and stores access the same attribute across all lanes, only for
different patches and vertices.
For the TCS this results in tightly packed data for 4-component
stores.
Setting 028B6C_DISTRIBUTION_MODE to a non-zero value and
either setting 028B6C_NUM_DS_WAVES_PER_SIMD to a non-zero
value or storing a zero control word hang my card.
The R_028B50_VGT_TESS_DISTRIBUTION value is copied from
amdgpu-pro. Smaller values in the ACCUM fields seem to
decrease the performa
They are unused.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_shader.c | 4 +---
src/gallium/drivers/radeonsi/si_shader.h | 15 ---
src/gallium/drivers/radeonsi/si_state_draw.c | 4 +---
3 files changed, 10 insertions(+), 13 deletions(-)
diff --git
Using more than 1 wave per threadgroup does increase performance
generally. Not using too many patches per threadgroup also
increases performance. Both catalyst and amdgpu-pro seem to
use 40 patches as their maximum, but I haven't really seen
any performance increase from limiting the number of pa
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_shader.c | 3 +++
src/gallium/drivers/radeonsi/si_shader.h | 12 ++--
src/gallium/drivers/radeonsi/si_state_draw.c | 9 +++--
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/src/gallium/driv
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_shader.c | 81
1 file changed, 81 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 5897149..d3df4d6 100644
--- a/src/gallium/
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_shader.c| 28 -
src/gallium/drivers/radeonsi/si_shader.h| 3 ++-
src/gallium/drivers/radeonsi/si_state_shaders.c | 9
3 files changed, 34 insertions(+), 6 deletions(-)
diff --g
This happens to be in the right position, but that changes
when TCS/TES get new parameters.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_shader.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.h
b/src/gal
This allows running the TES on different CU's than the
TCS which results in performance improvements.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_shader.c| 11 ---
src/gallium/drivers/radeonsi/si_state_shaders.c | 2 +-
2 files changed, 9 insertions(+),
The buffer is quite large, but should only be allocated if the
application uses tessellation. Most non-games don't.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_pipe.c | 1 +
src/gallium/drivers/radeonsi/si_pipe.h | 1 +
src/gallium/drivers/radeonsi/si
We need to copy the VS outputs to memory. I decided to do this
using a shader key, as the value depends on other shaders.
I also switch the fixed function TCS over to monolithic, as
otherwisze many of the user SGPR's need to be passed to the
epilog, which increases register pressure, or complexity
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_shader.c | 138 +++
1 file changed, 69 insertions(+), 69 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 29ff68f..5897149 100644
-
Hello Kenneth,
On 10 May 2016 at 03:46, Kenneth Graunke wrote:
> Three Shadow of Mordor geometry shaders increase by a single
> instruction, but the number of spills/fills in Orbital Explorer
> is reduced from 194:1279 -> 82:454. No other programs are affected.
>
> Signed-off-by: Kenneth Graunk
Hi,
nice! The windows driver has an option to limit tessellation factor to x16
etc, would it be possible to implement something similar in radeonsi? Of
course that's kindof to opposite to actually making x32 and x64 faster like
you're doing here. :-)
Regards
//Ernst
2016-05-10 12:52 GMT+02:00 Ba
On 03/05/16 19:57, Jordan Justen wrote:
> On 2016-05-03 05:21:50, Samuel Iglesias Gonsálvez wrote:
>> From: Iago Toral Quiroga
>>
>> This can happen if the register already has a non-zero subreg_offset
>> when byte_offset() is called.
>> ---
>> src/mesa/drivers/dri/i965/brw_ir_fs.h | 4
>> 1
On 03/05/16 20:30, Jordan Justen wrote:
> On 2016-05-03 05:21:51, Samuel Iglesias Gonsálvez wrote:
>> From: Iago Toral Quiroga
>>
>> We should not offset into them based on the relative offset of
>> our source and the destination of the instruction we are copy
>> propagating from, so we don't tu
On 04/05/16 00:51, Jordan Justen wrote:
> On 2016-05-03 05:21:52, Samuel Iglesias Gonsálvez wrote:
>> From: Iago Toral Quiroga
>>
>> Specifically, consider the size of the data type of the operand to compute
>> the number of registers written.
>> ---
>> src/mesa/drivers/dri/i965/brw_fs_copy_propa
On 04/05/16 01:04, Jordan Justen wrote:
> Should the subject say something about not allowing a type size
> change?
>
I don't think it is necessary but I don't have a strong opinion. What do
you think about this?
i965/fs: don't allow type change in copy-propagation if types have
different size
On Tue, May 10, 2016 at 1:49 PM, Ernst Sjöstrand wrote:
> Hi,
>
> nice! The windows driver has an option to limit tessellation factor to x16
> etc, would it be possible to implement something similar in radeonsi? Of
> course that's kindof to opposite to actually making x32 and x64 faster like
> yo
Am 10.05.2016 um 06:50 schrieb Jose Fonseca:
> On 09/05/16 18:50, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> Those aren't really interesting, however outputting them is helpful when
>> trying to feed the IR to llvm llc (or opt) for debugging.
>> ---
>> src/gallium/auxiliary/gall
Hi Kenneth,
can you update the comment too?
Michael
Am 10.05.2016 um 09:46 schrieb Kenneth Graunke:
> Three Shadow of Mordor geometry shaders increase by a single
> instruction, but the number of spills/fills in Orbital Explorer
> is reduced from 194:1279 -> 82:454. No other programs are affect
The buffer is quite large, but should only be allocated if the
application uses tessellation. Most non-games don't.
v2: Use the correct register for SI.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_pipe.c | 1 +
src/gallium/drivers/radeonsi/si_pipe.h |
Reviewed-by: Tim Rowley
> On May 9, 2016, at 11:52 PM, Jose Fonseca wrote:
>
> On 09/05/16 16:46, Vinson Lee wrote:
>> This patch fixes this build error.
>>
>> CXX rasterizer/memory/libswrAVX_la-ClearTile.lo
>> In file included from rasterizer/memory/ClearTile.cpp:34:0:
>> ./rasterizer/
From: Roland Scheidegger
Use GALLIVM_DEBUG=dumpbc for dumping of modules as bitcode.
Instead of a fixed llvmpipe.bc name, use ir_.bc so multiple
modules can be dumped (albeit it might still overwrite previous modules,
particularly the modules from draw tend to always have the same name).
---
src
To support the EGL_KHR_fence_sync extension on the DRM EGL platform,
copy the DRI2 fence extension from the GBM DRI backend.
Signed-off-by: Philipp Zabel
---
src/egl/drivers/dri2/platform_drm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/egl/drivers/dri2/platform_drm.c
b/src/egl/dri
To support the EGL_KHR_fence_sync extension on the DRM EGL platform,
add the DRI2 fence extension to the dri_core_extensions match table.
Signed-off-by: Philipp Zabel
---
src/gbm/backends/dri/gbm_dri.c| 1 +
src/gbm/backends/dri/gbm_driint.h | 1 +
2 files changed, 2 insertions(+)
diff --gi
On 10.05.2016 05:52, Bas Nieuwenhuizen wrote:
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_shader.c | 81
1 file changed, 81 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.
On 10.05.2016 05:52, Bas Nieuwenhuizen wrote:
Instead of creating a memory area per patch and per vertex, we put
the same attribute of every vertex & patch together. Most loads
and stores access the same attribute across all lanes, only for
different patches and vertices.
For the TCS this result
On Mon, 2016-05-09 at 23:37 -0700, Kenneth Graunke wrote:
> void *log_data,
> > const unsigned *assembly = NULL;
> >
> > unsigned nr_attributes = _mesa_bitcount_64(prog_data-
> >inputs_read);
> > + unsigned nr_attribute_slots = 0;
>
> Can't you just do:
>
> nir_shader *nir = vp->p
On Tue, May 10, 2016 at 6:13 PM, Nicolai Hähnle wrote:
> On 10.05.2016 05:52, Bas Nieuwenhuizen wrote:
>>
>> Signed-off-by: Bas Nieuwenhuizen
>> ---
>> src/gallium/drivers/radeonsi/si_shader.c | 81
>>
>> 1 file changed, 81 insertions(+)
>>
>> diff --git a/src/
On 10.05.2016 11:25, Bas Nieuwenhuizen wrote:
On Tue, May 10, 2016 at 6:13 PM, Nicolai Hähnle wrote:
On 10.05.2016 05:52, Bas Nieuwenhuizen wrote:
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_shader.c | 81
1 file changed, 81 inse
On Tue, May 10, 2016 at 6:28 PM, Nicolai Hähnle wrote:
> On 10.05.2016 11:25, Bas Nieuwenhuizen wrote:
>>
>> On Tue, May 10, 2016 at 6:13 PM, Nicolai Hähnle
>> wrote:
>>>
>>> On 10.05.2016 05:52, Bas Nieuwenhuizen wrote:
Signed-off-by: Bas Nieuwenhuizen
---
src/galliu
On 10.05.2016 11:25, Nicolai Hähnle wrote:
On 10.05.2016 05:52, Bas Nieuwenhuizen wrote:
Instead of creating a memory area per patch and per vertex, we put
the same attribute of every vertex & patch together. Most loads
and stores access the same attribute across all lanes, only for
different pa
On 10.05.2016 05:52, Bas Nieuwenhuizen wrote:
We need to copy the VS outputs to memory. I decided to do this
using a shader key, as the value depends on other shaders.
I also switch the fixed function TCS over to monolithic, as
otherwisze many of the user SGPR's need to be passed to the
epilog,
On 10.05.2016 05:53, Bas Nieuwenhuizen wrote:
Using more than 1 wave per threadgroup does increase performance
generally. Not using too many patches per threadgroup also
increases performance. Both catalyst and amdgpu-pro seem to
use 40 patches as their maximum, but I haven't really seen
any per
Reviewed-by: Ilia Mirkin
On Tue, May 10, 2016 at 1:54 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This fixes a crash (but not the test):
> GL45-CTS.shader_texture_image_samples_tests.functional_test
>
> Signed-off-by: Dave Airlie
> ---
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 4 ++--
On Mon, May 09, 2016 at 10:30:25AM -0700, Ben Widawsky wrote:
> On Mon, May 09, 2016 at 10:29:28AM -0700, Ben Widawsky wrote:
> > On Fri, May 06, 2016 at 11:38:25AM +0300, Topi Pohjolainen wrote:
> > > Until now mcs was associated to single sampled buffers only for
> > > fast clear purposes and it
On 10.05.2016 05:53, Bas Nieuwenhuizen wrote:
Setting 028B6C_DISTRIBUTION_MODE to a non-zero value and
either setting 028B6C_NUM_DS_WAVES_PER_SIMD to a non-zero
value or storing a zero control word hang my card.
The R_028B50_VGT_TESS_DISTRIBUTION value is copied from
amdgpu-pro. Smaller values
On Thu, Apr 21, 2016 at 02:59:04PM +0300, Topi Pohjolainen wrote:
> v2: Add support for blorp and removed the support for meta
>
> Signed-off-by: Topi Pohjolainen
> ---
> src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 3 +++
> src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 6 ++
> src/mesa
On 10.05.2016 11:36, Bas Nieuwenhuizen wrote:
On Tue, May 10, 2016 at 6:28 PM, Nicolai Hähnle wrote:
On 10.05.2016 11:25, Bas Nieuwenhuizen wrote:
On Tue, May 10, 2016 at 6:13 PM, Nicolai Hähnle
wrote:
On 10.05.2016 05:52, Bas Nieuwenhuizen wrote:
Signed-off-by: Bas Nieuwenhuizen
---
On Mon, May 9, 2016 at 12:33 PM, Rob Clark wrote:
> From: Rob Clark
>
> Prep work to reduce the noise in the next patch.
>
> Signed-off-by: Rob Clark
> ---
> src/compiler/nir/nir_lower_io_to_temporaries.c | 124
> ++---
> 1 file changed, 72 insertions(+), 52 deletions(-)
>
On Mon, May 9, 2016 at 12:34 PM, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> src/compiler/nir/nir.h | 3 +-
> src/compiler/nir/nir_lower_io_to_temporaries.c | 56
> +-
> src/mesa/drivers/dri/i965/brw_nir.c
On Tue, May 10, 2016 at 08:14:00PM +0300, Pohjolainen, Topi wrote:
> On Thu, Apr 21, 2016 at 02:59:04PM +0300, Topi Pohjolainen wrote:
> > v2: Add support for blorp and removed the support for meta
> >
> > Signed-off-by: Topi Pohjolainen
> > ---
> > src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
It seems like at least some of these recent fixes should be candidates
for stable.
On 05/09/2016 08:37 PM, Kenneth Graunke wrote:
> On Tuesday, May 10, 2016 11:07:23 AM PDT Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This fixes:
>> GL33-
> CTS.gtf33.GL3Tests.vertex_type_2_10_10_10_rev.vertex_ty
v2: Reuse the macro for bind & delete.
Note that may not be able to share the delete long-term as
pipe_compute_state contains members not in pipe_shader_state,
and we need to distinguish the pointer location if we add that
struct to the union.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/dr
https://bugs.freedesktop.org/show_bug.cgi?id=95005
--- Comment #8 from Ian Romanick ---
This seems related to a bug that was reported via the mesa-dev mailing list
back in 2013:
https://lists.freedesktop.org/archives/mesa-dev/2013-November/048843.html
--
You are receiving this mail because:
Yo
From: Rob Clark
Some optimizations, like converting integer multiply/divide into left/
right shifts, have additional constraints on the search expression.
Like requiring that a variable is a constant power of two. Support
these cases by allowing a fxn name to be appended to the search var
expres
Adam Jackson writes:
> Another attempt at syncing the GLX generator scripts with xserver.
>
> Jon mentioned a couple of issues in the last series, namely that these two
> patches were still necessary:
>
> https://lists.x.org/archives/xorg-devel/2014-April/041597.html
> https://lists.x.org/archive
On Tuesday, May 3, 2016 2:22:00 PM PDT Samuel Iglesias Gonsálvez wrote:
> From: Iago Toral Quiroga
>
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 49 ++
--
> 1 file changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
On Tuesday, May 10, 2016 2:57:03 PM PDT Rob Clark wrote:
> From: Rob Clark
>
> Some optimizations, like converting integer multiply/divide into left/
> right shifts, have additional constraints on the search expression.
> Like requiring that a variable is a constant power of two. Support
> these
On 04/30/2016 12:24 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> The old iteration casts sentinel nodes (which are mere exec_nodes) into
> whatever type we're looping over, which leads to badness (in fact, gcc's
> undefined behaviour sanitizer crashes while trying to verify that we have
>
Rob Clark writes:
> From: Jose Fonseca
>
> Signed-off-by: Rob Clark
> ---
> src/compiler/SConscript | 57
> +++--
> 1 file changed, 55 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/SConscript b/src/compiler/SConscript
> index 10c79c4..
On Tuesday, May 10, 2016 12:07:26 PM PDT Kenneth Graunke wrote:
> On Tuesday, May 3, 2016 2:22:00 PM PDT Samuel Iglesias Gonsálvez wrote:
> > From: Iago Toral Quiroga
> >
> > ---
> > src/mesa/drivers/dri/i965/brw_fs.cpp | 49 +
+
> --
> > 1 file changed, 47 insert
On Tuesday, May 3, 2016 2:22:04 PM PDT Samuel Iglesias Gonsálvez wrote:
> From: Iago Toral Quiroga
>
> There are a few places where we need to shuffle the result of a 32-bit load
> into valid 64-bit data, so extract this logic into a separate helper that we
> can reuse.
>
> Also, the shuffling n
On Tuesday, May 3, 2016 2:22:07 PM PDT Samuel Iglesias Gonsálvez wrote:
> From: Iago Toral Quiroga
>
> This does the inverse operation of SHUFFLE_32BIT_LOAD_RESULT_TO_64BIT_DATA
> and we will use it when we need to write 64-bit data in the layout expected
> by untyped write messages.
>
> Again,
On 9 May 2016 at 20:33, Rob Clark wrote:
> From: Jose Fonseca
>
> Signed-off-by: Rob Clark
> ---
> src/compiler/SConscript | 57
> +++--
> 1 file changed, 55 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/SConscript b/src/compiler/SConsc
On 08.05.2016 23:29, Tobias Klausmann wrote:
On 08.05.2016 22:50, Ilia Mirkin wrote:
What exactly gets fed into the CLIPDIST and CULLDIST semantics? e.g.
is CULLDIST[0].x the first cull distance, or is it the first entity in
the combined cull/clip distance array? If the former, then this won't
Until now mcs was associated to single sampled buffers only for
fast clear purposes and it was therefore the responsibility of the
clear logic to allocate the aux buffer when needed. Now that normal
3D render or blorp blit may render with mcs enabled also, they need
to prepare the mcs just as well.
On Tuesday, May 3, 2016 9:26:13 PM PDT Francisco Jerez wrote:
> Instead of using the LOAD_PAYLOAD instruction (emitted through the
> emit_transpose() helper that is no longer useful and this commit
> removes) which had to be marked force_writemask_all in some cases,
> emit a series of moves to appl
---
doxygen/doxy.bat | 7 +++
1 file changed, 7 insertions(+)
diff --git a/doxygen/doxy.bat b/doxygen/doxy.bat
index e566ca3..408964e 100644
--- a/doxygen/doxy.bat
+++ b/doxygen/doxy.bat
@@ -6,6 +6,9 @@ doxygen swrast_setup.doxy
doxygen tnl.doxy
doxygen core.doxy
doxygen glapi.doxy
+doxyge
On Tuesday, May 3, 2016 2:21:49 PM PDT Samuel Iglesias Gonsálvez wrote:
> Hello,
>
> This series adds the final bits to support arb_gpu_shader_fp64 in the
> i965 scalar backend for BDW+ hardware. It sits on top of the previous
> series we sent last week [0] and which is going through review at the
On Thursday, April 28, 2016 1:40:35 PM PDT Antia Puentes wrote:
> From: "Juan A. Suarez Romero"
>
> VS Thread Payload handles attributes in URB as vec4, no matter if they
> are actually single or double precision.
>
> So with double-precision types, value ends up in the registers split in
> 32bi
On Tuesday, May 10, 2016 6:24:39 PM PDT Juan A. Suarez Romero wrote:
> On Mon, 2016-05-09 at 23:37 -0700, Kenneth Graunke wrote:
> > void *log_data,
> > > const unsigned *assembly = NULL;
> > >
> > > unsigned nr_attributes = _mesa_bitcount_64(prog_data-
> > >inputs_read);
> > > + unsign
On 10.05.2016 14:17, Ian Romanick wrote:
On 04/30/2016 12:24 AM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
The old iteration casts sentinel nodes (which are mere exec_nodes) into
whatever type we're looping over, which leads to badness (in fact, gcc's
undefined behaviour sanitizer crashes whi
From: Nicolai Hähnle
The old iteration casts sentinel nodes (which are mere exec_nodes) into
whatever type we're looping over, which leads to badness (in fact, gcc's
undefined behaviour sanitizer crashes while trying to verify that we have
the correct type at hand).
These modified looping constr
On 11 May 2016 at 04:06, Ian Romanick wrote:
> It seems like at least some of these recent fixes should be candidates
> for stable.
I didn't think they were fixing any real world problems so I hadn't
really bothered,
I think I tagged one of them so far, my goal was to try and get Haswell to pass
Samuel Iglesias Gonsálvez writes:
> From: Iago Toral Quiroga
>
> Specifically, consider the size of the data type of the operand to compute
> the number of registers written.
> ---
> src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Otherwise constants which aren't live get an undefined constant location.
When we go to set up param and pull_param we end up assigning all unused
uniforms to slot 0. This cases the Vulkan driver to segfault because it
doesn't have pull_param.
This fixes bugs in the Vulkan driver introduced in c3
Samuel Iglesias Gonsálvez writes:
> From: Iago Toral Quiroga
>
> We should not offset into them based on the relative offset of
> our source and the destination of the instruction we are copy
> propagating from, so we don't turn this:
>
> mov(16) vgrf6:F, vgrf7+0.0<0>:F
> (...)
> load_payload(8)
Samuel Iglesias Gonsálvez writes:
> From: Iago Toral Quiroga
>
> When source modifiers are present and the types of the source and
> the entry's source are different, there are certain cases in which
> we allow copy-propagation to change the type of source by the type
> of the entry's source we
Reviewed-by: Mark Janes
Jason Ekstrand writes:
> Otherwise constants which aren't live get an undefined constant location.
> When we go to set up param and pull_param we end up assigning all unused
> uniforms to slot 0. This cases the Vulkan driver to segfault because it
> doesn't have pull_pa
1 - 100 of 164 matches
Mail list logo