Looks good to me:
Reviewed-by: Alejandro Piñeiro
Note: I think that patches 3-4 should be reviewed by a more seasoned
developer (specially patch 3).
On 01/07/16 07:07, Francisco Jerez wrote:
> There were two places in the driver doing a pipe control VF cache
> flush, one of them was missing thi
On Wed, Jun 29, 2016 at 05:37:33PM -0700, Jason Ekstrand wrote:
> We put all of the code for fake IMS together. This requires moving a bit
> of the program key setup code further down so that it gets the right values
> out of the final surface.
> ---
> src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
Looks good to me:
Reviewed-by: Alejandro Piñeiro
On 01/07/16 07:07, Francisco Jerez wrote:
> Shouldn't cause any functional changes at this point, but we have
> forgotten to apply this workaround several times in the past, make
> sure it doesn't happen again.
> ---
> src/mesa/drivers/dri/i965/b
On Wed, Jun 29, 2016 at 05:37:32PM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_blorp.c | 1 -
> src/mesa/drivers/dri/i965/brw_blorp.h | 9 -
> 2 files changed, 10 deletions(-)
I found only one piece of blorp even considering the layout, and that reads
it from the mi
On Wed, Jun 29, 2016 at 05:37:30PM -0700, Jason Ekstrand wrote:
> AUX USAGE
Commit message looks a little incomplete. Otherwise patches 10-12 are
Reviewed-by: Topi Pohjolainen
> ---
> src/mesa/drivers/dri/i965/brw_blorp.h| 2 ++
> src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 16
On 30/06/16 15:28, Brian Paul wrote:
> On 06/29/2016 09:50 AM, Alejandro Piñeiro wrote:
>> silent, flush, incomplete_tex and incomplete_fbo flags were not
>> documented (see src/mesa/main.debug.c for more info).
>>
>> FP is not checked anymore.
>>
>> v2 (Brian Paul):
>> * MESA_DEBUG accepts a com
On 30/06/16 23:16, Francisco Jerez wrote:
> Alejandro Piñeiro writes:
>
>> Fixes:
>> GL44-CTS.texture_barrier_ARB.same-texel-rw-multipass
>>
>> On Haswell, Broadwell and Skylake (note that in order to execute that
>> test, it is needed to override GL and GLSL versions).
>>
>> On gen6 this test was
Hi,
Is OSMesaCreateContextAttribs supposed to be an extension function
that should not be linked against and queried for using
OSMesaGetProcAddress or is that a public api function?
If I look into the source I could think its public since it's
listed in the public header and marked as GLAPI.
But
On Thu, Jun 30, 2016 at 06:57:39AM -0700, Jason Ekstrand wrote:
>On Jun 29, 2016 11:07 PM, "Pohjolainen, Topi"
><[1]topi.pohjolai...@intel.com> wrote:
>>
>> On Wed, Jun 29, 2016 at 05:37:28PM -0700, Jason Ekstrand wrote:
>> > ---
>> > src/mesa/drivers/dri/i965/brw_blorp_bli
Review carefully, it sucks to have to keep track of the number of
command packet dwords emitted in the batch epilogue manually. The
MI_REPORT_PERF_COUNT_BATCH_DWORDS calculation was obviously wrong.
---
src/mesa/drivers/dri/i965/brw_performance_monitor.c | 10 +-
src/mesa/drivers/dri/i965
Shouldn't cause any functional changes at this point, but we have
forgotten to apply this workaround several times in the past, make
sure it doesn't happen again.
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 9 -
src/mesa/drivers/dri/i965/brw_pipe_control.c | 21 +++-
There were two places in the driver doing a pipe control VF cache
flush, one of them was missing this workaround, move it down into
brw_emit_pipe_control_flush to make sure we don't miss it again.
---
src/mesa/drivers/dri/i965/brw_pipe_control.c | 19 ++-
1 file changed, 10 inserti
This hardware race condition has caused problems several times already
(see "i965: Fix cache pollution race during L3 partitioning set-up.",
"i965: Fix brw_render_cache_set_check_flush's PIPE_CONTROLs." and
"i965: intel_texture_barrier reimplemented"). The problem is that
whenever we attempt to bo
I keep saying I'm going to review this "tomorrow" but I really mean it this
time! I would have today but I spent the whole day arguing the finer
points of surface layout, HiZ, fast clears, and color compression with
Chad. It was a fun day! :-)
--Jason
On Jun 23, 2016 12:17 PM, "Topi Pohjolainen"
Jason Ekstrand writes:
> On Jun 30, 2016 9:25 PM, "Francisco Jerez" wrote:
>>
>> Jason Ekstrand writes:
>>
>> > Fwiw, I very much like the way I did this in the Vulkan driver where it
>> > splits it into two pipe controls automatically based on the input bits.
>> > (Look at genX_cmd_buffer.c cm
On Jun 30, 2016 9:25 PM, "Francisco Jerez" wrote:
>
> Jason Ekstrand writes:
>
> > Fwiw, I very much like the way I did this in the Vulkan driver where it
> > splits it into two pipe controls automatically based on the input bits.
> > (Look at genX_cmd_buffer.c cmd_buffer_apply_pipe_flushes.) I
Jason Ekstrand writes:
> Fwiw, I very much like the way I did this in the Vulkan driver where it
> splits it into two pipe controls automatically based on the input bits.
> (Look at genX_cmd_buffer.c cmd_buffer_apply_pipe_flushes.) I very much
> doubt that this is the only place we have this pro
On Thu, Jun 30, 2016 at 6:54 PM, Samuel Pitoiset
wrote:
>
>
> On 07/01/2016 12:44 AM, Ilia Mirkin wrote:
>>
>> If moveSources doesn't move modifiers, we have a serious problem.
>> However it looks like it does:
>>
>> void
>> Instruction::setSrc(int s, const ValueRef& ref)
>> {
>>setSrc(s, ref.
On Thu, 2016-06-30 at 00:59 +0300, Grazvydas Ignotas wrote:
> On Wed, Jun 29, 2016 at 3:11 PM, Timothy Arceri
> wrote:
> > On Wed, 2016-06-29 at 03:47 +0300, Grazvydas Ignotas wrote:
> > > On Tue, Jun 28, 2016 at 10:53 AM, Timothy Arceri
> > > wrote:
> > > > On Mon, 2016-06-27 at 00:46 +1000, Tim
On Thu, Jun 30, 2016 at 6:26 PM, Samuel Pitoiset
wrote:
> This instruction is new since SM50 (Maxwell) and allows to perform
> an add with three sources. Unfortunately, it only supports integers.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir.h
---
src/mesa/main/shader_query.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index b5e1a44..a2a93b1 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -84,7 +84,8 @@ _mesa_B
Basically we just have to scale up the coordinates and then add the
relevant sample offset. The code to handle this was already largely
present from Christoph's earlier attempts to pipe images through back in
the dark ages, this just hooks it all up.
Signed-off-by: Ilia Mirkin
---
v1 -> v2:
- f
https://bugs.freedesktop.org/show_bug.cgi?id=95346
--- Comment #13 from Luchesar V. ILIEV ---
Sorry for the spam, but I just realised that earlier game versions can be
tested. Going back as far as 1.0.0, the situation is the same: textures work
in-game, but are broken in the start new game screen
On 07/01/2016 02:52 AM, Vedran Miletić wrote:
Had something similar in the works, Bas did as well, but this approach
is cleaner.
With these changes, in si_pipe.c and r600_pipe.c, you should not return
max_const_buffer_size anymore, since it can exceed int limits, but
instead something like
MAX2
On 07/01/2016 01:29 AM, Marek Olšák wrote:
From: Marek Olšák
also fix max_global_size to take a maximum of {vram_size, gart_size}
---
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/radeon/r600_pipe_common.c | 9 +++--
src/gallium/drivers/radeonsi/si_pipe.c
On Thu, Jun 30, 2016 at 11:42 AM, Kenneth Graunke
wrote:
> On Saturday, June 25, 2016 8:37:47 AM PDT Rob Clark wrote:
> > From: Rob Clark
> >
> > Some games are sloppy.. perhaps because it is defined behavior for DX or
> > perhaps because nv blob driver defaults things to zero.
> >
> > So add dr
https://bugs.freedesktop.org/show_bug.cgi?id=95346
--- Comment #12 from Luchesar V. ILIEV ---
Slight correction: the textures load correctly in-game; however the planets are
still broken as before (i.e. showing only the night texture) in the "New game"
screen, where the player selects who they wa
Am 01.07.2016 um 02:16 schrieb Brian Paul:
> We can't blit with resource_copy_region() if there are window clip rects.
> ---
> src/gallium/auxiliary/util/u_surface.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/auxiliary/util/u_surface.c
> b/src/gallium/auxiliary/util/u_s
We can't blit with resource_copy_region() if there are window clip rects.
---
src/gallium/auxiliary/util/u_surface.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/auxiliary/util/u_surface.c
b/src/gallium/auxiliary/util/u_surface.c
index e0234f8..a9ed006 100644
--- a/src/gallium/
On Fri, 2016-07-01 at 01:26 +0200, Roland Scheidegger wrote:
> Am 01.07.2016 um 00:59 schrieb Matt Turner:
> > According to the referenced bug report, gcc-4.5 and newer do not
> > inline
> > memcmp(). I see no difference in performance of ipers with llvmpipe
> > on a
> > Sandybridge (which does not
Ian Romanick writes:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 50 ++--
> src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 52
> +++---
> 2 files changed, 81 insertions(+), 21 deletions
Ian Romanick writes:
> On 06/30/2016 03:33 PM, Francisco Jerez wrote:
>> Matt Turner writes:
>>
>>> On Wed, Jun 29, 2016 at 2:04 PM, Ian Romanick wrote:
From: Ian Romanick
This uses one less instruction.
>>>
>>> Add FBH to the list of stupid instructions.
>>>
Signed-off-by
On 06/30/2016 03:33 PM, Francisco Jerez wrote:
> Matt Turner writes:
>
>> On Wed, Jun 29, 2016 at 2:04 PM, Ian Romanick wrote:
>>> From: Ian Romanick
>>>
>>> This uses one less instruction.
>>
>> Add FBH to the list of stupid instructions.
>>
>>> Signed-off-by: Ian Romanick
>>> ---
>>> src/me
From: Marek Olšák
This will be needed after some LLVM changes that haven't landed yet.
v2: - use LLVMIsConstant to fix an LLVM assertion failure.
LLVMSetMetadata doesn't work with constants.
- don't set float metadata as string
---
src/gallium/drivers/radeon/radeon_llvm.h |
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 ++
src/gallium/drivers/radeon/radeon_winsys.h| 1 +
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 2 ++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 1 +
4 files changed, 6 insertions(+)
diff --git
From: Marek Olšák
---
src/gallium/drivers/r600/evergreen_compute.c | 3 -
src/gallium/drivers/radeon/Makefile.sources | 2 -
src/gallium/drivers/radeon/radeon_llvm_util.c | 124 --
src/gallium/drivers/radeon/radeon_llvm_util.h | 39
src/gallium/drivers/ra
From: Marek Olšák
also fix max_global_size to take a maximum of {vram_size, gart_size}
---
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/radeon/r600_pipe_common.c | 9 +++--
src/gallium/drivers/radeonsi/si_pipe.c| 2 +-
3 files changed, 5 insertions(+), 8
From: Marek Olšák
It's always zero.
---
src/gallium/drivers/radeonsi/si_shader.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index e2aae85..f2cdd6e 100644
--- a/src/gallium/drivers/rade
From: Marek Olšák
use v_interp_mov for those
---
src/gallium/drivers/radeonsi/si_shader.c| 13 -
src/gallium/drivers/radeonsi/si_shader.h| 2 +-
src/gallium/drivers/radeonsi/si_state_shaders.c | 1 +
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/sr
From: Marek Olšák
Handle the bc_optimize SGPR bit if both CENTER and CENTROID are enabled.
This should increase the PS launch rate for big primitives with MSAA.
Based on discussion with SPI guys.
---
src/gallium/drivers/radeonsi/si_shader.c| 118 +++-
src/gallium/driv
From: Marek Olšák
This reduces the number of v_mov's in the prolog.
---
src/gallium/drivers/radeonsi/si_shader.c| 85 +++--
src/gallium/drivers/radeonsi/si_shader.h| 3 +-
src/gallium/drivers/radeonsi/si_state_shaders.c | 21 +++---
3 files changed, 64 insert
From: Marek Olšák
This should increase the PS launch rate for shaders using at least 2 pairs
of perspective (i,j) and same for linear.
---
src/gallium/drivers/radeonsi/si_shader.c| 74 -
src/gallium/drivers/radeonsi/si_shader.h| 4 +-
src/gallium/drivers/
From: Marek Olšák
It's not true.
---
src/gallium/drivers/radeonsi/si_shader.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index a408dee..77d1a8b 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
Hi,
These mainly reduce the number of (i,j) that the hardware has to
compute for each pixel shader, which should increase the PS launch
rate in those cases.
There are also some codegen improvements for interpolation and a few
interp-unrelated but shader-related changes.
Please review.
Marek
___
Am 01.07.2016 um 00:59 schrieb Matt Turner:
> According to the referenced bug report, gcc-4.5 and newer do not inline
> memcmp(). I see no difference in performance of ipers with llvmpipe on a
> Sandybridge (which does not have "Enhanced REP MOVSB/STOSB") by removing
> this flag.
>
> I attempted t
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_debug.c | 4
src/gallium/drivers/radeonsi/si_pipe.c | 20 +++-
src/gallium/drivers/radeonsi/si_pipe.h | 1 +
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_debug.c
b/sr
From: Marek Olšák
---
src/gallium/drivers/ddebug/dd_context.c | 4 +++-
src/gallium/drivers/ddebug/dd_draw.c| 4
src/gallium/drivers/ddebug/dd_pipe.h| 1 +
src/gallium/drivers/ddebug/dd_util.h| 23 +++
4 files changed, 31 insertions(+), 1 deletion(-)
diff
From: Marek Olšák
Getting LLVM IRs of hanging shaders have never been easier.
---
src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
src/gallium/drivers/radeonsi/si_pipe.c | 3 +++
src/gallium/drivers/radeonsi/si_pipe.h
Hi,
This series adds apitrace call tracking into ddebug and radeonsi and
other improvements.
It will improve our debugging and profiling possibilities. Just set
GALLIUM_DDEBUG="apitrace [draw call number]" and you will get
a complete ddebug log with TGSI, LLVM IR (new!), and asm. Both radeonsi
an
From: Marek Olšák
---
src/gallium/drivers/ddebug/dd_draw.c | 53 +++-
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/ddebug/dd_draw.c
b/src/gallium/drivers/ddebug/dd_draw.c
index 22337e0..f0f6fb6 100644
--- a/src/gallium/drivers
From: Marek Olšák
---
src/gallium/drivers/ddebug/dd_draw.c | 8
src/gallium/drivers/ddebug/dd_pipe.h | 4 +++-
src/gallium/drivers/ddebug/dd_screen.c | 20 ++--
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/ddebug/dd_draw.c
b/
From: Marek Olšák
and remove some obsolete comments
---
src/gallium/drivers/ddebug/dd_context.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/ddebug/dd_context.c
b/src/gallium/drivers/ddebug/dd_context.c
index f618f0c..5fe423b 100644
---
On 06/30/2016 03:59 PM, Matt Turner wrote:
> According to the referenced bug report, gcc-4.5 and newer do not inline
> memcmp(). I see no difference in performance of ipers with llvmpipe on a
> Sandybridge (which does not have "Enhanced REP MOVSB/STOSB") by removing
> this flag.
>
> I attempted to
On Thursday, June 16, 2016 12:07:36 PM PDT Ian Romanick wrote:
> From: Ian Romanick
>
> v2: Also update varying_matches::compute_packing_class(). Suggested by
> Timothy Arceri.
>
> Signed-off-by: Ian Romanick
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96358
> Cc: "12.0"
> Cc: Gr
On Thursday, June 16, 2016 12:06:56 PM PDT Ian Romanick wrote:
> From: Ian Romanick
>
> Outputs from the vertex shader need to be able to match
> per-vertex-arrayed inputs of later stages. Acomplish this by stripping
> one level of arrayness from the names and types of outputs going to a
> per-v
Not sure why I forgot to add them to CXXFLAGS in commit f55c408067 or
commit 875458b778. Cuts about 1k of .text.
text data bss dec hex filename
5806354 28781629384 6123554 5d7022 i965_dri.so before
5805497 28774429384 6122625 5d6c81 i965_dri.so after
---
On 06/30/2016 03:37 PM, Francisco Jerez wrote:
> Ian Romanick writes:
>
>> From: Ian Romanick
>>
>> Previously SHADER_OPCODE_MULH could only exist on Gen7+, so the
>> assertion assumed the Gen7+ accumulator rules. A future patch will
>> allow this instruction on at least Gen6, so update the ass
According to the referenced bug report, gcc-4.5 and newer do not inline
memcmp(). I see no difference in performance of ipers with llvmpipe on a
Sandybridge (which does not have "Enhanced REP MOVSB/STOSB") by removing
this flag.
I attempted to confirm the problem with gcc-4.4, but it fails to comp
On 06/30/2016 03:33 PM, Francisco Jerez wrote:
> Matt Turner writes:
>
>> On Wed, Jun 29, 2016 at 2:04 PM, Ian Romanick wrote:
>>> From: Ian Romanick
>>>
>>> This uses one less instruction.
>>
>> Add FBH to the list of stupid instructions.
>>
>>> Signed-off-by: Ian Romanick
>>> ---
>>> src/me
On 06/30/2016 03:20 PM, Matt Turner wrote:
> On Wed, Jun 29, 2016 at 2:04 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Signed-off-by: Ian Romanick
>> ---
>> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 50 ++--
>> src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 52
>
On Thu, Jun 30, 2016 at 3:33 PM, Francisco Jerez wrote:
> Matt Turner writes:
>
>> On Wed, Jun 29, 2016 at 2:04 PM, Ian Romanick wrote:
>>> From: Ian Romanick
>>>
>>> This uses one less instruction.
>>
>> Add FBH to the list of stupid instructions.
>>
>>> Signed-off-by: Ian Romanick
>>> ---
>>
On 07/01/2016 12:44 AM, Ilia Mirkin wrote:
If moveSources doesn't move modifiers, we have a serious problem.
However it looks like it does:
void
Instruction::setSrc(int s, const ValueRef& ref)
{
setSrc(s, ref.get());
srcs[s].mod = ref.mod;
}
which is what moveSources calls.
I was not
On Thu, Jun 30, 2016 at 6:47 PM, Samuel Pitoiset
wrote:
>
>
> On 07/01/2016 12:40 AM, Ilia Mirkin wrote:
>>
>> Doesn't ADD3 only work for integers? I don't see anything here
>> preventing float adds from being merged here...
>
>
> isOpSupported() should do the job because I check if dtype is float
On 07/01/2016 12:40 AM, Ilia Mirkin wrote:
Doesn't ADD3 only work for integers? I don't see anything here
preventing float adds from being merged here...
isOpSupported() should do the job because I check if dtype is float.
On Thu, Jun 30, 2016 at 6:26 PM, Samuel Pitoiset
wrote:
Signed-of
If moveSources doesn't move modifiers, we have a serious problem.
However it looks like it does:
void
Instruction::setSrc(int s, const ValueRef& ref)
{
setSrc(s, ref.get());
srcs[s].mod = ref.mod;
}
which is what moveSources calls.
On Thu, Jun 30, 2016 at 6:26 PM, Samuel Pitoiset
wrote:
Doesn't ADD3 only work for integers? I don't see anything here
preventing float adds from being merged here...
On Thu, Jun 30, 2016 at 6:26 PM, Samuel Pitoiset
wrote:
> Signed-off-by: Samuel Pitoiset
> ---
> .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 55
> ++
> 1
Ian Romanick writes:
> From: Ian Romanick
>
> Previously SHADER_OPCODE_MULH could only exist on Gen7+, so the
> assertion assumed the Gen7+ accumulator rules. A future patch will
> allow this instruction on at least Gen6, so update the assertion.
>
> Signed-off-by: Ian Romanick
> ---
> src/me
Matt Turner writes:
> On Wed, Jun 29, 2016 at 2:04 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> This uses one less instruction.
>
> Add FBH to the list of stupid instructions.
>
>> Signed-off-by: Ian Romanick
>> ---
>> src/mesa/drivers/dri/i965/brw_fs.h | 4
>> src/
And ADD3(d, a, 0x0, c) to ADD(d, a, c) as well.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/dri
This is similar to what we already do for MAD/FMA.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/d
And ADD3(d, a, b, c) to ADD(d, b, a + c) as well.
This doesn't change the world but it can reduce the number of
instructions in some situations:
total instructions in shared programs :97191 -> 97175 (-0.02%)
total gprs used in shared programs:29196 -> 29196 (0.00%)
total local used in shared
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index f136c58..1cf1fa3 10064
Signed-off-by: Samuel Pitoiset
---
.../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 55 ++
1 file changed, 55 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 3213188..928
This instruction is new since SM50 (Maxwell) and allows to perform
an add with three sources. Unfortunately, it only supports integers.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h| 1 +
src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 928923c..f136c58
Signed-off-by: Samuel Pitoiset
---
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 34 ++
1 file changed, 34 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index 2c5e8f6.
On Thu, Jun 30, 2016 at 12:00 PM, Matt Turner wrote:
> On Thu, Jun 30, 2016 at 11:37 AM, Matt Turner wrote:
>> Patches 1-5 are
>>
>> Reviewed-by: Matt Turner
>
> As are 6-14.
18-22 as well.
There's weirdness about LZD of signed sources. I sent a comment.
___
On Thu, Jun 30, 2016 at 3:20 PM, Gurchetan Singh
wrote:
> There are a few places in the code where clearing and reading are done on
> incorrect buffers for GLES contexts. See comments for details. This
> fixes 75 GLES3 dEQP tests on the surfaceless platform with no regressions.
>
> v2: Corrected
On Wed, Jun 29, 2016 at 2:04 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 50 ++--
> src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 52
> +++---
> 2 files changed,
There are a few places in the code where clearing and reading are done on
incorrect buffers for GLES contexts. See comments for details. This
fixes 75 GLES3 dEQP tests on the surfaceless platform with no regressions.
v2: Corrected unclear comment
v3: Make the change in context.c instead of get.c
On Wed, Jun 29, 2016 at 2:04 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> This uses one less instruction.
Add FBH to the list of stupid instructions.
> Signed-off-by: Ian Romanick
> ---
> src/mesa/drivers/dri/i965/brw_fs.h | 4
> src/mesa/drivers/dri/i965/brw_fs_genera
Build mesa 1718 completed
Commit eb79b2b331 by Brian Paul on 5/11/2016 3:20 PM:
st/wgl: make own_mutex() non-static\n\nReviewed-by: Jose Fonseca
Configure your notification preferences
___
mesa-dev mailing
Alejandro Piñeiro writes:
> Fixes:
> GL44-CTS.texture_barrier_ARB.same-texel-rw-multipass
>
> On Haswell, Broadwell and Skylake (note that in order to execute that
> test, it is needed to override GL and GLSL versions).
>
> On gen6 this test was already working without this change. It keeps
> wor
On Thursday, June 30, 2016 10:13:47 AM PDT Ian Romanick wrote:
> I think I might want to use gperf for something in Mesa, but I'm not
> 100% sure yet. Before I proceed, is it even acceptable to add that as a
> build dependency?
Why not make it an optional dependency?
signature.asc
Description:
On Thursday, June 30, 2016 5:03:24 PM PDT Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> split-to-files.py | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/split-to-files.py b/split-to-files.py
> index 7e14d89..0e1d729 100755
> --- a/split-to-files.py
> +++ b/split-to-files.py
> @@
Build mesa 1716 failed
Commit c8ea85 by Brian Paul on 6/28/2016 11:15 PM:
svga: use SVGA3D_vgpu10_BufferCopy() for buffer copies\n\nSo that we do copies host-side rather than in the guest with map/memcpy.\n\nTested with piglit arb_copy_buffer-subdata-sync t
Ok, thanks for the pointers. Will take a look tomorrow (is 21:00 here).
Btw, what do you prefer? To fix it first on the texture barrier with a
patch like this, and then import Vulkan's? or forget about fixing with
the current status and go directly to import Vulkan's approach?
BR
On 30/06/16 16:
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va/config.c | 61 +++---
src/gallium/state_trackers/va/context.c| 57
src/gallium/state_trackers/va/surface.c| 12 --
src/gallium/state_trackers/va/va_private.h | 5 +++
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va/config.c | 11 +++
src/gallium/state_trackers/va/context.c| 3 ++-
src/gallium/state_trackers/va/va_private.h | 1 +
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/va/config.
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/omx/vid_enc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/state_trackers/omx/vid_enc.c
b/src/gallium/state_trackers/omx/vid_enc.c
index d70439a..bbc7941 100644
--- a/src/gallium/state_trackers/omx/vid_enc.
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va/image.c | 48 +--
1 file changed, 40 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_trackers/va/image.c
b/src/gallium/state_trackers/va/image.c
index 3c8cc9c..1f68169 100644
--- a/src/gal
Signed-off-by: Boyuan Zhang
---
src/gallium/include/pipe/p_video_state.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/include/pipe/p_video_state.h
b/src/gallium/include/pipe/p_video_state.h
index 9cd489b..040d2f1 100644
--- a/src/gallium/include/pipe/p_video_state.h
+++ b/src/
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va/image.c | 55 ---
1 file changed, 51 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/va/image.c
b/src/gallium/state_trackers/va/image.c
index 1b956e3..c82b554 100644
--- a/src/gal
https://bugs.freedesktop.org/show_bug.cgi?id=95346
--- Comment #11 from Luchesar V. ILIEV ---
This seems to have been fixed with the latest Mesa from git. Either this, or
the 1.2 upgrade to Stellaris itself did the trick.
The only problem left now is the ugly cursor that uses a non-premultiplied
On Thu, Jun 30, 2016 at 11:37 AM, Matt Turner wrote:
> Patches 1-5 are
>
> Reviewed-by: Matt Turner
As are 6-14.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 30/06/16 18:13, Ian Romanick wrote:
I think I might want to use gperf for something in Mesa, but I'm not
100% sure yet. Before I proceed, is it even acceptable to add that as a
build dependency?
I presume C code generated by gperf is freely usable and it's not
subject to GPL, right? (I c
Signed-off-by: Boyuan Zhang
---
src/gallium/drivers/radeon/radeon_vce_52.c | 33 ++
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_vce_52.c
b/src/gallium/drivers/radeon/radeon_vce_52.c
index 7d33313..7986eb8 100644
--
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va/buffer.c | 6 +
src/gallium/state_trackers/va/picture.c| 170 -
src/gallium/state_trackers/va/va_private.h | 3 +
3 files changed, 177 insertions(+), 2 deletions(-)
diff --git a/src/gallium/stat
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va/picture.c | 36 +
1 file changed, 36 insertions(+)
diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c
index 26205b1..2d22e8b 100644
--- a/src/gallium/state_t
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va/image.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/gallium/state_trackers/va/image.c
b/src/gallium/state_trackers/va/image.c
index c82b554..3c8cc9c 100644
--- a/src/gallium/state_trackers/va/image.c
1 - 100 of 138 matches
Mail list logo