Patches 1,3,4
Reviewed-by: Tapani Pälli
On 07/27/2015 04:22 PM, Marta Lofstedt wrote:
From: Marta Lofstedt
Signed-off-by: Marta Lofstedt
---
src/mesa/main/get.c | 6 ++
src/mesa/main/get_hash_params.py | 17 +++--
2 files changed, 17 insertions(+), 6 delet
> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Samuel Iglesias Gonsálvez
> Sent: Tuesday, July 28, 2015 7:24 AM
> To: Marta Lofstedt; mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH v6 1/4] mesa/es3.1: enable
> GL_ARB_sha
On 28/07/15 09:20, Lofstedt, Marta wrote:
>> -Original Message-
>> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
>> Behalf Of Samuel Iglesias Gonsálvez
>> Sent: Tuesday, July 28, 2015 7:24 AM
>> To: Marta Lofstedt; mesa-dev@lists.freedesktop.org
>> Subject: Re: [Mesa-d
> -Original Message-
> From: Samuel Iglesias Gonsálvez [mailto:sigles...@igalia.com]
> Sent: Tuesday, July 28, 2015 9:25 AM
> To: Lofstedt, Marta; Marta Lofstedt; mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH v6 1/4] mesa/es3.1: enable
> GL_ARB_shader_image_load_store for
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 2775d98..57e4dd7 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_
demote_pull_constants() was ignoring the execution size and channel
selects of the instruction that wanted the constant, which doesn't
matter for uniform pull constant loads because all channels get the
same scalar value, but it might for varying pull constant loads. Fix
it by using the new fs_bui
This could have led to somewhat increased bandwidth usage for lowered
texturing instructions on Gen4 (which is the only case in which
lower_width may be greater than inst->exec_size). After the previous
patches the invariant mentioned in the comment should no longer be
assumed by any of the other
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 8bc9372..2775d98 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/
It's not guaranteed to have the same width as the instruction
generating the spilled variable.
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/br
We have a number of optimization passes that repeat the same pattern
before inserting new instructions into the program based on some
previous instruction: They point the default builder at the original
instruction, then call exec_all() and group() to select the same
execution controls the original
Not a typo. Replace the default builder with one of bogus width to
catch cases in which optimization passes assume that the default
dispatch width is good enough. The execution controls of instructions
emitted during optimization should in general match the original code
that is being manipulated
opt_sampler_eot() was relying on the default builder to have the same
width as the sampler and FB write opcodes it was eliminating, the
channel selects didn't matter because the builder was only being used
to allocate registers, no new instructions were being emitted with it.
A future commit will c
This wasn't taking into account the execution controls of the original
instruction, but it was most likely not a bug because control flow
instructions are typically full width.
---
src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp | 8 +---
1 file changed, 5 insertions(+), 3 delet
---
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
index e33fe6a..a123ff2 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
+++ b/
Emit the SELs and MOVs with the same execution controls as the
original MOVs, and the CMP with the same execution controls as the IF.
Also explicitly check that the execution controls of any pair of MOVs
being folded into a SEL are compatible (which is almost always going
to be the case), since oth
Instead of relying on the default one. This shouldn't lead to any
functional changes because DEP_RESOLVE_MOV overrides the execution
controls of the instruction anyway.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/mes
The execution size was being left equal to the default of 8/16, which
AFAICT would have overwritten components other than the one we wanted
to initialize and could potentially have corrupted other registers.
---
src/mesa/drivers/dri/i965/brw_fs_combine_constants.cpp | 2 +-
1 file changed, 1 inser
lower_integer_multiplication() was ignoring the execution controls of
the original MUL instruction. Fix it by using the new fs_builder
constructor.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/
The register coalesce pass wasn't rewriting the destination and
sources of instructions that accessed the second half of a coalesced
register previously copied with a 16-wide MOV instruction. E.g.:
| ADD (16) vgrf0:f, vgrf0:f, 1.0:f
| MOV (16) vgrf1:f, vgrf0:f
| MOV (8) vgrf2:f, vgrf0+1:f { sech
register_coalesce() was considering the exec_size of the MOV
instruction alone to decide whether the register at offset+1 of the
source VGRF was being copied to inst->dst.reg_offset+1 of the
destination VGRF, which is only a valid assumption if the move has a
32-bit execution type. Use regs_read()
For some reason the loop that rewrites all occurrences of the
coalesced register was iterating over all possible offsets until it
would find one that compares equal to the offset of a source or
destination of any instruction in the program. Since the mapping
between old and new offsets is already
From: Marek Olšák
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 66 ++
1 file changed, 66 insertions(+)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 4c6e48a..6f00727 100644
--- a/src/mesa/state_tracker
From: Marek Olšák
It only checks fragment textures and ignores other shaders, which makes it
incomplete, and texture are already finalized in update_single_texture.
There are no piglit regressions.
---
src/mesa/state_tracker/st_atom.c | 1 -
src/mesa/state_tracker/st_atom.h |
From: Marek Olšák
---
src/gallium/auxiliary/util/u_debug.c | 8
src/gallium/auxiliary/util/u_debug.h | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_debug.c
b/src/gallium/auxiliary/util/u_debug.c
index cf6eca7..b4503de 100644
---
From: Marek Olšák
This will be used by the new ddebug pipe. I'm including it now to avoid
conflicts with other patches.
---
src/gallium/drivers/r600/evergreen_compute.c | 2 +-
src/gallium/drivers/radeon/r600_pipe_common.h | 5 ++---
src/gallium/drivers/radeon/radeon_elf_util.c | 13 +---
From: Marek Olšák
---
src/gallium/drivers/r600/r600_llvm.c| 1 -
src/gallium/drivers/r600/r600_shader.c | 1 -
src/gallium/drivers/radeon/radeon_llvm.h| 19 ---
src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 14 --
4 f
From: Marek Olšák
There are 2 reasons for this:
- LLVM optimization passes can work with floor
- there are patterns to select v_fract from floor anyway
There is no change in the generated code.
---
src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 20
1 file changed, 16
From: Marek Olšák
---
src/gallium/drivers/r600/r600_blit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index 8e553a8..1c59230 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers/r600/r6
From: Marek Olšák
---
src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index a7fa7cc..319380f 100644
--- a/
From: Marek Olšák
duplicated now
---
src/gallium/drivers/r600/r600_llvm.c | 34 +--
src/gallium/drivers/radeon/radeon_llvm.h | 8 ---
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 68 +-
src/gallium/drivers/radeonsi/si_shader.c
From: Marek Olšák
The patch has a better explanation. Just a summary here:
- The CPU always uploads a whole descriptor array to previously-unused memory.
- CP DMA isn't used.
- No caches need to be flushed.
- All descriptors are always up-to-date in memory even after a hang, because
CP DMA does
From: Marek Olšák
st/nine uses GENERIC slots greater than 60.
---
src/gallium/drivers/radeonsi/si_shader.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 2239d96..4e4f766 1006
From: Marek Olšák
This is for shader-db and should reduce size of shader dumps.
---
src/gallium/drivers/r600/r600_llvm.c | 2 +-
src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 23 ---
src/gallium/drivers/radeon/
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
src/gallium/drivers/radeonsi/si_shader.c | 20 +++-
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/radeon/r6
From: Marek Olšák
Broken since:
46b2b3b - radeonsi: don't change pipe_resource in resource_copy_region
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91444
---
src/gallium/drivers/radeonsi/si_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/dri
From: Marek Olšák
---
src/gallium/drivers/r600/r600_llvm.c | 152 -
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 150
2 files changed, 150 insertions(+), 152 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gall
From: Marek Olšák
This will help remove some duplicated code from radeon.
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 6 +++---
src/gallium/auxiliary/gallivm/lp_bld_intr.c | 12
src/gallium/auxiliary/gallivm/lp_bld_intr.h | 3 ++-
src/gallium/auxiliary/gallivm/lp_bld_logi
From: Marek Olšák
This reverts commit 4db985a5fa9ea985616a726b1770727309502d81.
The grass no longer disappears, which was the reason the commit was reverted.
This might affect tessellation. We'll see.
Totals from affected shaders:
SGPRS: 151672 -> 150232 (-0.95 %)
VGPRS: 90620 -> 89776 (-0.93 %
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_blit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_blit.c
b/src/gallium/drivers/radeonsi/si_blit.c
index c3591a7..c892623 100644
--- a/src/gallium/drivers/radeonsi/si_blit.c
+++ b/src/gallium/drivers
From: Marek Olšák
---
src/gallium/drivers/radeonsi/Makefile.sources | 1 +
src/gallium/drivers/radeonsi/si_cp_dma.c | 265 ++
src/gallium/drivers/radeonsi/si_descriptors.c | 233 --
src/gallium/drivers/radeonsi/si_pipe.c| 1 +
src/gall
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
src/gallium/drivers/radeonsi/si_shader.c | 2 +-
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src
https://bugs.freedesktop.org/show_bug.cgi?id=13978
Tapani Pälli changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
---
src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
index cd89edd..a9bf0d8 100644
--- a/src/mesa/drivers
Link to v1:
http://lists.freedesktop.org/archives/mesa-dev/2015-July/089766.html
Changes after review (Curro)
- Drop the patch that asserted that the reg size should always be 1
- Expand this so that we do not unspill a register if we have just
unspilled it as well
- Use brw_mask_for_swi
In theory, GRF array access should have been moved to scratch by the time
we got here, so this should never happen. A full piglit run forcing
spilling of all registers seems to confirm this. The FS backend
does not seem to check for this either.
---
src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.
When we have code such as this:
mov vgrf1.0.x:F, vgrf2.:F
mov vgrf3.0.x:F, vgrf1.:F
...
mov vgrf3.0.x:F, vgrf1.:F
And vgrf1 is chosen for spilling, we can emit this:
mov vgrf1.0.x:F, vgrf2.:F
gen4_scratch_write hw_reg0:F, vgrf1.:D, 22D
mov vgrf3.0.x:F, vgrf1.:F
...
gen4_s
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4.cpp| 2 +-
src/mesa/drivers/dri/i965/intel_debug.c | 3 ++-
src/mesa/drivers/dri/i965/intel_debug.h | 5 +++--
4 files changed, 7 insertions(+), 5 deletions(-)
diff --g
Previous patches made it so that we do not need to unspill the same vgrf
with every instruction as long as these instructions come right after
the register was spilled or unspilled. This means that actually spilling
the register is now cheaper in these scenarios, so adjust the spilling
cost calcula
Similar to reads inmmediately after spilling, there is no gain for register
allocation in unspilling the same vgrf in consecutive instructions, since
the gain only comes when there are gaps in the program that don't use the
vgrf. In these scenarios we can simply unspill once and reuse the result
fo
Change function to get all gl_constants for inspection, this is used
by follow-up patch.
v2: rebase, update function documentation
Signed-off-by: Tapani Pälli
---
src/glsl/linker.cpp | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/src/glsl/linker.cpp
Same check is made for glBindFragDataLocationIndexed but it was missing
when using layout qualifiers.
Fixes following Piglit test:
arb_blend_func_extended-output-location
Signed-off-by: Tapani Pälli
---
src/glsl/linker.cpp | 19 +++
1 file changed, 19 insertions(+)
diff
On Tue, 2015-07-28 at 13:10 +1000, Edward O'Callaghan wrote:
> Hi,
>
> Attached is a patch that should support the said extension. I am using
> the following piglit patch to test with:
>
> https://github.com/victoredwardocallaghan/piglit
> -work/commit/783d5aa28b2e5ea4f67e439fe9e74c0391f5d7d0
>
Hi Edward,
please use git send-email next time. Now I have to paste your patch here.
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 15bb57f..6d9d424 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -189,7 +189,7 @@ GL 4.5, GLSL 4.50:
GL_ARB_ES3_1_compatibility not st
https://bugs.freedesktop.org/show_bug.cgi?id=91474
--- Comment #1 from Axel Davy ---
Mesa egl does indeed support DRI_PRIME for the wayland backend,
however unless DRI_PRIME is set, it uses the same card that the server.
I guess either the user has set DRI_PRIME or the equivalent drirc option,
o
https://bugs.freedesktop.org/show_bug.cgi?id=91474
--- Comment #2 from Emil Velikov ---
Using the device extensions one will be able to enumerate and select the device
they want without the need of X or the DRI_PRIME variable.
Jonny Lamb posted a series that implements the "base" - device_enumer
On 21 July 2015 at 16:43, Boyan Ding wrote:
> Signed-off-by: Boyan Ding
> ---
> configure.ac|8 +-
> src/loader/Makefile.am |9 +
> src/loader/loader_dri3_helper.c | 1397
> +++
> src/loader/loader_dri3_helper.h | 226 +++
On 21 July 2015 at 16:44, Boyan Ding wrote:
> Signed-off-by: Boyan Ding
> ---
> configure.ac | 6 +
> src/egl/drivers/dri2/Makefile.am | 5 +
> src/egl/drivers/dri2/egl_dri2.c | 66 +++-
> src/egl/drivers/dri2/egl_dri2.h | 14 +-
> src/
Hello Boyan,
On 21 July 2015 at 16:43, Boyan Ding wrote:
> This is the second version of my effort to bring dri3 to EGL on X. This
> time I took Emil's advice and moved common logic of GLX and EGL into
> loader/loader_dri3_helper.[ch]. With this, the dri3 code in libEGL is
> only ~650 lines, with
https://bugs.freedesktop.org/show_bug.cgi?id=91130
--- Comment #2 from Serge Martin ---
Hello
this should be mitigated with the "clover: allow the creation of Piglit tests
for the missing CL 1.2 fonction" serie available on mesa-dev list.
However, even if the program will compile, those fonctio
Hello Jim,
On 28 July 2015 at 02:57, Bish, Jim wrote:
> From: Jim Bish
>
Would you mind splitting this into separate patches ? Adding a few
words in the commit log(s) would be highly preferable.
> ---
> Android.common.mk | 10 ++
> Android.mk
https://bugs.freedesktop.org/show_bug.cgi?id=91130
--- Comment #3 from Serge Martin ---
Sorry I mean "OpenCL 1.1 MESA 10.7.0-devel". 1.2 is only clain on my local tree
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=91468
--- Comment #3 from Emil Velikov ---
Please send the patch to mesa-dev (ideally using git send-email). It'll get
wider exposure there.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
On Jul 28, 2015 2:43 AM, "Francisco Jerez" wrote:
>
> register_coalesce() was considering the exec_size of the MOV
> instruction alone to decide whether the register at offset+1 of the
> source VGRF was being copied to inst->dst.reg_offset+1 of the
> destination VGRF, which is only a valid assumpt
https://bugs.freedesktop.org/show_bug.cgi?id=91468
--- Comment #4 from Serge Martin ---
Please note that autotools buils have the "svn" part in the libname.
I don't knows if it will be deprecated in 3.8 and remove later or if it will be
removed in 3.8.
--
You are receiving this mail because:
Yo
On 17/07/15 21:57, Emil Velikov wrote:
> Would anyone be interested is skimming over this trivial series ?
>
Thomas kindly looked over patches 1,2 and 5. Would anyone care to throw
a quick ack/nack for the rest ?
I'm inclined to push the series unless there are any objections in the
next few days
On 20 July 2015 at 17:12, Brian Paul wrote:
> On 07/17/2015 02:14 PM, Emil Velikov wrote:
>>
>> On 17 July 2015 at 20:22, Brian Paul wrote:
>>>
>>> Can you elaborate in the commit message why this is being done or why the
>>> HAVE_SYS_TYPES_H definition is not needed? That saves me time having t
On 07/28/2015 07:33 AM, Emil Velikov wrote:
On 20 July 2015 at 17:12, Brian Paul wrote:
On 07/17/2015 02:14 PM, Emil Velikov wrote:
On 17 July 2015 at 20:22, Brian Paul wrote:
Can you elaborate in the commit message why this is being done or why the
HAVE_SYS_TYPES_H definition is not neede
On 07/28/2015 04:05 AM, Marek Olšák wrote:
From: Marek Olšák
It only checks fragment textures and ignores other shaders, which makes it
incomplete, and texture are already finalized in update_single_texture.
There are no piglit regressions.
---
src/mesa/state_tracker/st_atom.c | 1 -
Hi Marek,
Yea I don't let git send emails via any mailer.. It would be better if I
could just do pull requests rather than mailing lists if at all
possible? I really seriously hate mailing lists.
In any case, attached is a revised patch with all the feedback included.
Kind Regards,
Edward.
--
Jason Ekstrand writes:
> On Jul 28, 2015 2:43 AM, "Francisco Jerez" wrote:
>>
>> register_coalesce() was considering the exec_size of the MOV
>> instruction alone to decide whether the register at offset+1 of the
>> source VGRF was being copied to inst->dst.reg_offset+1 of the
>> destination VGR
https://bugs.freedesktop.org/show_bug.cgi?id=91130
--- Comment #4 from Dennis Schridde ---
Just to make sure I understand. You say that:
1) Mesa should provide a shared library that actually implements all functions
advertised in the header (which will be fixed in Mesa 10.7/11.0)
2) applications
https://bugs.freedesktop.org/show_bug.cgi?id=91468
--- Comment #5 from Krzysztof A. Sobiecki ---
(In reply to Serge Martin from comment #4)
> Please note that autotools buils have the "svn" part in the libname.
> I don't knows if it will be deprecated in 3.8 and remove later or if it will
> be re
https://bugs.freedesktop.org/show_bug.cgi?id=91468
--- Comment #6 from Krzysztof A. Sobiecki ---
(In reply to Emil Velikov from comment #3)
> Please send the patch to mesa-dev (ideally using git send-email). It'll get
> wider exposure there.
I don't see how It would be appropriate to even try to
Iago Toral Quiroga writes:
> Link to v1:
> http://lists.freedesktop.org/archives/mesa-dev/2015-July/089766.html
>
> Changes after review (Curro)
> - Drop the patch that asserted that the reg size should always be 1
> - Expand this so that we do not unspill a register if we have just
> uns
https://bugs.freedesktop.org/show_bug.cgi?id=91468
--- Comment #7 from Emil Velikov ---
(In reply to Krzysztof A. Sobiecki from comment #6)
> (In reply to Emil Velikov from comment #3)
> > Please send the patch to mesa-dev (ideally using git send-email). It'll get
> > wider exposure there.
>
> I
This also helps making my egl/dri3 code easier, so
Acked-by: Boyan Ding
2015-07-11 1:49 GMT+08:00 Emil Velikov :
> Cc: Axel Davy
> Signed-off-by: Emil Velikov
> ---
> configure.ac| 2 +-
> src/egl/drivers/dri2/platform_wayland.c | 20 ++--
> 2 file
On Tue, Jul 28, 2015 at 12:05:42PM +0200, Marek Olšák wrote:
> From: Marek Olšák
>
> This reverts commit 4db985a5fa9ea985616a726b1770727309502d81.
>
> The grass no longer disappears, which was the reason the commit was reverted.
> This might affect tessellation. We'll see.
>
Hi Marek,
This pa
On Tue, Jul 28, 2015 at 12:05:40PM +0200, Marek Olšák wrote:
> From: Marek Olšák
>
Reviewed-by: Tom Stellard
> ---
> src/gallium/drivers/r600/r600_llvm.c | 152
> -
> .../drivers/radeon/radeon_setup_tgsi_llvm.c| 150
> 2 files cha
Marek Olšák wrote on 28.07.2015 12:05:
> From: Marek Olšák
>
> ---
> src/gallium/auxiliary/util/u_debug.c | 8
> src/gallium/auxiliary/util/u_debug.h | 6 +++---
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_debug.c
> b/src/gallium/au
On 07/28/2015 06:11 AM, Emil Velikov wrote:
> Hello Jim,
>
> On 28 July 2015 at 02:57, Bish, Jim wrote:
>> From: Jim Bish
>>
> Would you mind splitting this into separate patches ? Adding a few
> words in the commit log(s) would be highly preferable.
sure. thought this was small enough but ok
On Tue, Jul 28, 2015 at 3:37 AM, Tapani Pälli wrote:
> Same check is made for glBindFragDataLocationIndexed but it was missing
> when using layout qualifiers.
>
> Fixes following Piglit test:
> arb_blend_func_extended-output-location
>
> Signed-off-by: Tapani Pälli
> ---
> src/glsl/linke
On 28/07/15 17:54, Bish, Jim wrote:
>
>
> On 07/28/2015 06:11 AM, Emil Velikov wrote:
>> Hello Jim,
>>
>> On 28 July 2015 at 02:57, Bish, Jim wrote:
>>> From: Jim Bish
>>>
>> Would you mind splitting this into separate patches ? Adding a few
>> words in the commit log(s) would be highly prefera
Brian Paul wrote on 28.07.2015 18:40:
> On 07/28/2015 10:35 AM, Kai Wasserbäch wrote:
>> Marek Olšák wrote on 28.07.2015 12:05:
>>> From: Marek Olšák
>>>
>>> ---
>>> src/gallium/auxiliary/util/u_debug.c | 8
>>> src/gallium/auxiliary/util/u_debug.h | 6 +++---
>>> 2 files changed, 7 i
We were already doing this internally for iterating over a function
implementation, so just expose it directly.
Signed-off-by: Connor Abbott
---
src/glsl/nir/nir.c | 7 +++
src/glsl/nir/nir.h | 3 +++
2 files changed, 10 insertions(+)
diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
ind
V2: Do a "depth first search" to convert to LCSSA
I'm still a bit unsure if the way I'm inserting
the phi nodes is correct, but the flow of the pass
seems to be correct. Unfortunately it keeps getting
rerun time and time again. Most likely due to some optimizations
removing the phi-nodes or other
I was hoping this should fix the problem with the pass
getting rerun forever, but apparently not. We still need
a solution like this though, so sending it out for some
feedback of whether or not this is the way to do it.
Signed-off-by: Thomas Helland
---
src/glsl/nir/nir.h | 1 +
Reviewed-by: Marek Olšák
Marek
On Mon, Jul 27, 2015 at 3:49 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This is part of ARB_gpu_shader5, and this passes
> all the piglit tests currently available.
>
> v2: use macros from the fine derivs commit.
> add comments.
> Signed-off-by: Dave Airlie
Just thought I'd mention that this is a bit RFC.
I was just throwing it out there before dinner so you guys could
have a look at it if you feel like it. I was hoping to put the loop analysis
on here to, but I'll fix it up to use a DFS approach before sending
it out on the list. The way I've solved
Reviewed-by: Marek Olšák
Marek
On Mon, Jul 27, 2015 at 3:49 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This adds support for queries against the non-0 vertex streams.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/radeon/r600_query.c | 18 --
> src/gallium/d
On Mon, Jul 27, 2015 at 3:50 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This will be used here later.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/radeon/r600_streamout.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/ra
On Mon, Jul 27, 2015 at 3:50 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This adds to the common radeon streamout code, support
> for multiple streams.
>
> It updates radeonsi/r600 to set the enabled mask up.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/r600/r600_shader.c
If you add the check for LLVM 3.7, this is:
Reviewed-by: Marek Olšák
Marek
On Mon, Jul 27, 2015 at 3:50 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This enables GL4.1 for radeonsi, and updates the
> docs in the correct places.
>
> Signed-off-by: Dave Airlie
> ---
> docs/GL3.txt
From: Marek Olšák
---
src/mesa/state_tracker/st_atom_shader.c | 29 ++---
src/mesa/state_tracker/st_context.h | 1 -
2 files changed, 2 insertions(+), 28 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_shader.c
b/src/mesa/state_tracker/st_atom_shader.c
ind
On 07/28/2015 12:44 PM, Marek Olšák wrote:
From: Marek Olšák
---
src/mesa/state_tracker/st_atom_shader.c | 29 ++---
src/mesa/state_tracker/st_context.h | 1 -
2 files changed, 2 insertions(+), 28 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_shader.
---
docs/GL3.txt | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 15bb57f..2e2a7e3 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -92,11 +92,11 @@ GL 3.3, GLSL 3.30 --- all DONE: i965, nv50, nvc0, r600,
r
The meta CopyImageSubData path uses BlitFramebuffers to do the actual copy.
The only thing that can affect BlitFramebuffers other than the currently
bound framebuffers is the scissor so we need to save that off and reset it.
If we don't do this, applications that use a scissor together with
CopyIma
On Tue, Jul 28, 2015 at 12:06 PM, Jason Ekstrand wrote:
> The meta CopyImageSubData path uses BlitFramebuffers to do the actual copy.
> The only thing that can affect BlitFramebuffers other than the currently
> bound framebuffers is the scissor so we need to save that off and reset it.
> If we don
On Tue, Jul 28, 2015 at 6:35 PM, Kai Wasserbäch
wrote:
> Marek Olšák wrote on 28.07.2015 12:05:
>> From: Marek Olšák
>>
>> ---
>> src/gallium/auxiliary/util/u_debug.c | 8
>> src/gallium/auxiliary/util/u_debug.h | 6 +++---
>> 2 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff
Ping.
Marek
On Fri, Jul 24, 2015 at 7:16 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Fixes piglit:
> spec@glsl-1.30@execution@fs-texture-sampler2dshadow-10
> spec@glsl-1.30@execution@fs-texture-sampler2dshadow-11
>
> v2: use st_shader_stage_to_ptarget
> ---
> src/mesa/state_tracker/
I thought someone else R-b'd this.
LGTM. Reviewed-by: Brian Paul
On 07/28/2015 01:45 PM, Marek Olšák wrote:
Ping.
Marek
On Fri, Jul 24, 2015 at 7:16 PM, Marek Olšák wrote:
From: Marek Olšák
Fixes piglit:
spec@glsl-1.30@execution@fs-texture-sampler2dshadow-10
spec@glsl-1.30@ex
1 - 100 of 146 matches
Mail list logo