Seems reasonable:
Reviewed-by: Timothy Arceri
On 23/08/17 12:19, Kenneth Graunke wrote:
This may reduce some recompiles.
---
src/mesa/drivers/dri/i965/brw_wm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
b/src/mesa/drivers/dri/i
We don't actually write them to disk here. That will happen in the
following commit.
---
src/compiler/glsl/shader_cache.cpp | 20 +---
src/compiler/glsl/tests/cache_test.c| 12 ++--
src/gallium/drivers/radeonsi/si_state_shaders.c | 2 +-
src/mesa/s
---
src/util/disk_cache.c | 89 ++-
1 file changed, 88 insertions(+), 1 deletion(-)
diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index c1b7429b92..dd12a09841 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -105,20 +10
This will be used to store more information about the cache item
in it's header. This information is intended for 3rd party and
cache analysis use but can also be used for detecting the unlikely
scenario of cache collisions.
---
src/util/disk_cache.h | 20
1 file changed, 20 i
It really doesn't cost us much and will stop strange crashes should
the stars align.
---
src/util/disk_cache.c | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index 644a911e53..2df49cf626 100644
--- a/sr
Steam is already analysing cache items, unfortunatly we did not
introduce a versioning mechanism for identifying structural changes
to cache entries earlier so the only way to do so is to rename the
cache directory.
Since we are renaming it we take the opportunity to give the directory
a more mean
On 23/08/17 12:19, Kenneth Graunke wrote:
All shader stages do the exact same thing, so we don't need the switch
statement, or the redundant FS case. I believe these used to be
different before Tim eliminated the (e.g.) brw_vertex_program
subclasses.
Seems about right, I must have forgotten to
This is causing piglit regressions for me. For example:
./bin/shader_runner
tests/spec/arb_bindless_texture/execution/images/multiple-resident-images-reading.shader_test
-auto -fb
Unexpected GL error: GL_OUT_OF_MEMORY 0x505
(Error at
/home/tarceri/git/Mesa_arrays_of_arrays_piglit/tests/shade
https://bugs.freedesktop.org/show_bug.cgi?id=102017
--- Comment #13 from MWATTT ---
I definitively can't reproduce this bug, even with Ubuntu 17.04 stock mesa. It
might be specific to some high end cards. Which game settings do you use?
--
You are receiving this mail because:
You are the assign
All shader stages do the exact same thing, so we don't need the switch
statement, or the redundant FS case. I believe these used to be
different before Tim eliminated the (e.g.) brw_vertex_program
subclasses.
---
src/mesa/drivers/dri/i965/brw_program.c | 33 +
1 fi
This may reduce some recompiles.
---
src/mesa/drivers/dri/i965/brw_wm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
b/src/mesa/drivers/dri/i965/brw_wm.c
index c9c45045902..e1555d60c56 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++
Previously, the state upload code listened to a broad set of dirty flags
that corresponded to all possible state dependencies for a shader stage.
This is somewhat overkill. For example, if a shader has no textures,
there is no need to listen to _NEW_TEXTURE. Although these extra
dependencies are
Am 23.08.2017 um 01:59 schrieb Marek Olšák:
> On Wed, Aug 23, 2017 at 12:30 AM, Roland Scheidegger
> wrote:
>> Am 22.08.2017 um 17:15 schrieb Marek Olšák:
>>> On Sun, Aug 20, 2017 at 12:32 AM, Roland Scheidegger
>>> wrote:
Am 19.08.2017 um 21:32 schrieb Marek Olšák:
> How about we remo
On Wed, Aug 23, 2017 at 12:30 AM, Roland Scheidegger wrote:
> Am 22.08.2017 um 17:15 schrieb Marek Olšák:
>> On Sun, Aug 20, 2017 at 12:32 AM, Roland Scheidegger
>> wrote:
>>> Am 19.08.2017 um 21:32 schrieb Marek Olšák:
How about we remove all opcodes that are unused? Like:
SAMPLE
On 23/08/17 09:42, Ilia Mirkin wrote:
On Tue, Aug 22, 2017 at 7:41 PM, Timothy Arceri wrote:
On 23/08/17 09:28, Ilia Mirkin wrote:
On Tue, Aug 22, 2017 at 7:25 PM, Timothy Arceri
wrote:
On 23/08/17 09:08, Ilia Mirkin wrote:
On Tue, Aug 22, 2017 at 6:55 PM, Timothy Arceri
wrote:
On Tue, Aug 22, 2017 at 7:41 PM, Timothy Arceri wrote:
>
>
> On 23/08/17 09:28, Ilia Mirkin wrote:
>>
>> On Tue, Aug 22, 2017 at 7:25 PM, Timothy Arceri
>> wrote:
>>>
>>>
>>>
>>> On 23/08/17 09:08, Ilia Mirkin wrote:
On Tue, Aug 22, 2017 at 6:55 PM, Timothy Arceri
wrote:
On 23/08/17 09:28, Ilia Mirkin wrote:
On Tue, Aug 22, 2017 at 7:25 PM, Timothy Arceri wrote:
On 23/08/17 09:08, Ilia Mirkin wrote:
On Tue, Aug 22, 2017 at 6:55 PM, Timothy Arceri
wrote:
On 23/08/17 00:56, Ilia Mirkin wrote:
On Tue, Aug 22, 2017 at 10:51 AM, Roland Scheidegger
wro
On Tue, Aug 22, 2017 at 7:25 PM, Timothy Arceri wrote:
>
>
> On 23/08/17 09:08, Ilia Mirkin wrote:
>>
>> On Tue, Aug 22, 2017 at 6:55 PM, Timothy Arceri
>> wrote:
>>>
>>>
>>>
>>> On 23/08/17 00:56, Ilia Mirkin wrote:
On Tue, Aug 22, 2017 at 10:51 AM, Roland Scheidegger
w
On 23/08/17 09:08, Ilia Mirkin wrote:
On Tue, Aug 22, 2017 at 6:55 PM, Timothy Arceri wrote:
On 23/08/17 00:56, Ilia Mirkin wrote:
On Tue, Aug 22, 2017 at 10:51 AM, Roland Scheidegger
wrote:
I am probably missing something here, but why do you need a new register
file? Since you couldn
On 22/08/17 03:19, Samuel Pitoiset wrote:
Looks like you no longer encode shader_info::stage (which is the first
field), is that expected?
Nice catch! I guess we probably don't use this field after compilation,
although we should still fix it so I've sent a 6.5 patch to reorder the
members.
This will allow us to easily skip them when writting the struct
to disk cache.
---
src/compiler/shader_info.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index a67084156d..38413940d6 100644
--- a/src/compiler/sha
gen6...brw? Drop some baklava layers.
---
src/mesa/drivers/dri/i965/brw_ff_gs.c | 5 -
src/mesa/drivers/dri/i965/brw_ff_gs.h | 1 -
src/mesa/drivers/dri/i965/brw_gs.c| 2 +-
3 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_ff_gs.c
b/src/mesa/dri
It doesn't seem like the old code could possibly work.
1. brw_gs_state_dirty made us bail unless one of these flags were set:
_NEW_TEXTURE, BRW_NEW_GEOMETRY_PROGRAM, BRW_NEW_TRANSFORM_FEEDBACK
2. If there was no geometry program, we called brw_upload_ff_gs_prog()3
3. That checked brw_ff_gs_stat
On Tue, Aug 22, 2017 at 6:55 PM, Timothy Arceri wrote:
>
>
> On 23/08/17 00:56, Ilia Mirkin wrote:
>>
>> On Tue, Aug 22, 2017 at 10:51 AM, Roland Scheidegger
>> wrote:
>>>
>>> I am probably missing something here, but why do you need a new register
>>> file? Since you couldn't use LOAD with TGSI_
On 23/08/17 00:56, Ilia Mirkin wrote:
On Tue, Aug 22, 2017 at 10:51 AM, Roland Scheidegger wrote:
I am probably missing something here, but why do you need a new register
file? Since you couldn't use LOAD with TGSI_FILE_CONSTANT before, can't
you just allow LOAD with TGSI_FILE_CONSTANT and ac
Yeah I've noticed this before.
Reviewed-by: Timothy Arceri
On 23/08/17 07:58, Kenneth Graunke wrote:
brw_ff_gs.c is about using the geometry shader to implement things
that the fixed function ought to do, but doesn't on old hardware.
Gen7+ does not need this. We should drop the misleading co
https://bugs.freedesktop.org/show_bug.cgi?id=102017
--- Comment #12 from Timothy Arceri ---
(In reply to Thomas Jollans from comment #9)
> I'm having the same issue, with Ubuntu 17.04 stock mesa and r600 (HD 6870)
>
> It looks to me like an issue with textures not being drawn; Everything is
> di
Am 22.08.2017 um 17:15 schrieb Marek Olšák:
> On Sun, Aug 20, 2017 at 12:32 AM, Roland Scheidegger
> wrote:
>> Am 19.08.2017 um 21:32 schrieb Marek Olšák:
>>> How about we remove all opcodes that are unused? Like:
>>>
>>> SAMPLE_POS
>>> SAMPLE_INFO
>>> SAMPLE
>>> SAMPLE_I
>>> SAMPLE_I_MS
>>> SAMP
brw_ff_gs.c is about using the geometry shader to implement things
that the fixed function ought to do, but doesn't on old hardware.
Gen7+ does not need this. We should drop the misleading comment
about Gen7 not using geometry shaders.
---
src/mesa/drivers/dri/i965/brw_ff_gs.c | 7 +++
1 fil
https://bugs.freedesktop.org/show_bug.cgi?id=102038
Brian Paul changed:
What|Removed |Added
Attachment #133654|0 |1
is obsolete|
State upload code should use prog_data rather than poking at shader_info
directly.
---
src/intel/compiler/brw_compiler.h| 1 +
src/intel/compiler/brw_fs.cpp| 2 ++
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 6 ++
3 files changed, 5 insertions(+), 4 d
Replace piles of my own boilerplate with 1-2 lines of code.
---
src/mesa/drivers/dri/i965/brw_context.c | 4
src/mesa/drivers/dri/i965/brw_context.h | 5 -
src/mesa/drivers/dri/i965/brw_state.h| 4
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 22
Render target surfaces always start at binding table index 0.
This is required for us to use headerless FB writes, which we
really want to do. So, we'll never change that.
Given that, it's not necessary to look up a wm_prog_data field
which we already know contains 0. We can drop the dependency
Also rename it to gen6_update_renderbuffer_surface, as this is the
function for Gen6+. Having functions named "brw_*" and "gen4_*"
is confusing...if we're using gens, let's stick with those.
---
src/mesa/drivers/dri/i965/brw_state.h| 5 -
src/mesa/drivers/dri/i965/brw_wm_surface_
We either want the framebuffer dimensions or 1x1x1. Passing fb and
falling back to 1x1x1 lets us shorten some calls.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 28 ++--
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm
We don't need yet another set of flags. The function already has access
to both brw and the unit, so it can check brw->draw_aux_buffer_disabled
itself in one line of code. The layered flag was only used to assert
that Gen4-5 doesn't do layered rendering, which isn't that useful.
---
src/mesa/dri
Less baklava layers.
---
src/mesa/drivers/dri/i965/brw_state.h| 5 ---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 53 +---
2 files changed, 20 insertions(+), 38 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_state.h
b/src/mesa/drivers/dri/i965/br
This involves a bunch of unnecessary copying, a batch flush, and
state re-emission.
---
src/mesa/drivers/dri/i965/brw_program_cache.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_program_cache.c
b/src/mesa/drivers/dri/i965/brw_program_cache.c
index 4dcfd523
Am 22.08.2017 um 19:10 schrieb Marek Olšák:
> Hi,
>
> I'd like to discuss 16-bit float and integer support in TGSI. I'm
> proposing this:
>
> struct tgsi_instruction
> {
> unsigned Type : 4; /* TGSI_TOKEN_TYPE_INSTRUCTION */
> unsigned NrTokens : 8; /* UINT */
> unsigned O
This shrinks the key from 64 bytes to 20 bytes.
---
src/intel/blorp/blorp_priv.h | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/src/intel/blorp/blorp_priv.h b/src/intel/blorp/blorp_priv.h
index 81bf8c66c66..f96a5e0e5ad 100644
---
Depending on which extension or GL spec you read the behavior of
glVertexAttrib(index=0) either sets the current value for generic
attribute 0, or it emits a vertex just like glVertex(). I believe
it should do either, depending on context (see below).
The piglit gl-2.0-vertex-const-attr test decl
https://bugs.freedesktop.org/show_bug.cgi?id=102017
--- Comment #11 from Thomas Jollans ---
Created attachment 133679
--> https://bugs.freedesktop.org/attachment.cgi?id=133679&action=edit
in-game data view has correct colours
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freedesktop.org/show_bug.cgi?id=102017
--- Comment #10 from Thomas Jollans ---
Created attachment 133678
--> https://bugs.freedesktop.org/attachment.cgi?id=133678&action=edit
in-game screenshot: blank surfaces
--
You are receiving this mail because:
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=102017
--- Comment #9 from Thomas Jollans ---
I'm having the same issue, with Ubuntu 17.04 stock mesa and r600 (HD 6870)
It looks to me like an issue with textures not being drawn; Everything is
displayed with nice reflective surfaces. In the in-game
https://bugs.freedesktop.org/show_bug.cgi?id=100613
--- Comment #43 from Ben Crocker ---
(In reply to Ben Crocker from comment #42)
> Created attachment 133677 [details] [review]
> lp_build_gather_elem_vec big-endian fix for 3x16 load
>
> In reply to Roland's Comment 32:
>
> Roland, thanks for
On 08/22/2017 02:40 AM, Michel Dänzer wrote:
On 22/08/17 06:31 PM, Timothy Arceri wrote:
On 22/08/17 18:02, Michel Dänzer wrote:
On 22/08/17 10:02 AM, Pierre-Loup A. Griffais wrote:
On 08/18/2017 04:02 AM, Nicolai Hähnle wrote:
On 15.08.2017 01:26, Timothy Arceri wrote:
This will be used t
https://bugs.freedesktop.org/show_bug.cgi?id=100613
Ben Crocker changed:
What|Removed |Added
Attachment #131577|0 |1
is obsolete|
On Tue, Aug 22, 2017 at 7:55 PM, Ilia Mirkin wrote:
> On Tue, Aug 22, 2017 at 1:32 PM, Marek Olšák wrote:
>> On Tue, Aug 22, 2017 at 7:28 PM, Ilia Mirkin wrote:
>>> How do you propose defining the semantics for e.g. loading a 16-bit
>>> value from a constbuf/ssbo? Would those get separate instru
On Tue, Aug 22, 2017 at 1:32 PM, Marek Olšák wrote:
> On Tue, Aug 22, 2017 at 7:28 PM, Ilia Mirkin wrote:
>> How do you propose defining the semantics for e.g. loading a 16-bit
>> value from a constbuf/ssbo? Would those get separate instructions?
>
> st/mesa should use UP2H, PK2H and similar opco
On Tue, Aug 22, 2017 at 7:28 PM, Ilia Mirkin wrote:
> How do you propose defining the semantics for e.g. loading a 16-bit
> value from a constbuf/ssbo? Would those get separate instructions?
st/mesa should use UP2H, PK2H and similar opcodes for I16 and U16, and
drivers can replace them with MOV i
How do you propose defining the semantics for e.g. loading a 16-bit
value from a constbuf/ssbo? Would those get separate instructions?
On Tue, Aug 22, 2017 at 1:10 PM, Marek Olšák wrote:
> Hi,
>
> I'd like to discuss 16-bit float and integer support in TGSI. I'm
> proposing this:
>
> struct tgsi
Emil Velikov writes:
> Hi Eric,
>
> On 10 August 2017 at 23:43, Eric Anholt wrote:
>
>> +aarch64)
>> +DEFINES="$DEFINES -DUSE_AARCH64_ASM"
> I cannot see any places where the define is used.
>
> Am I missing something or there isn't any? Do you have some WIP
> patches that make use o
Hi,
I'd like to discuss 16-bit float and integer support in TGSI. I'm
proposing this:
struct tgsi_instruction
{
unsigned Type : 4; /* TGSI_TOKEN_TYPE_INSTRUCTION */
unsigned NrTokens : 8; /* UINT */
unsigned Opcode : 8; /* TGSI_OPCODE_ */
unsigned Saturate : 1;
For the series:
Reviewed-by: Marek Olšák
Marek
On Tue, Aug 22, 2017 at 5:45 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Use the correct type to fix pointer arithmetic.
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> d
On 08/22/2017 10:35 AM, Nicolai Hähnle wrote:
On 22.08.2017 18:33, Brian Paul wrote:
On 08/22/2017 09:32 AM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
So we can easily re-arrange members of tgsi_opcode_info, and readers of
the code don't have to guess what all the 0s mean.
Mostly done with
On 22.08.2017 18:33, Brian Paul wrote:
On 08/22/2017 09:32 AM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
So we can easily re-arrange members of tgsi_opcode_info, and readers of
the code don't have to guess what all the 0s mean.
Mostly done with regex search&replace.
---
src/gallium/auxilia
Am 22.08.2017 um 16:56 schrieb Ilia Mirkin:
> On Tue, Aug 22, 2017 at 10:51 AM, Roland Scheidegger
> wrote:
>> I am probably missing something here, but why do you need a new register
>> file? Since you couldn't use LOAD with TGSI_FILE_CONSTANT before, can't
>> you just allow LOAD with TGSI_FILE_
On 08/22/2017 09:32 AM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
So we can easily re-arrange members of tgsi_opcode_info, and readers of
the code don't have to guess what all the 0s mean.
Mostly done with regex search&replace.
---
src/gallium/auxiliary/Makefile.sources | 1 +
sr
Pass the dri.sym version script to the linker. This ensures only
explicitly exported symbols are exported and shrinks the library by up
to 60KB.
HAVE_DLADDR also needs to be set so that __driDriverExtensions is defined.
We need to pass "--undefined-version" because the Android build system
sets -
For the series:
Reviewed-by: Marek Olšák
Marek
On Tue, Aug 22, 2017 at 5:32 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> They are only used for debug info.
>
> Together with making tgsi_opcode_info::opcode a bitfield, this reduces
> the size of tgsi_opcode_info on 64-bit systems from
On 08/22/2017 09:52 AM, Nicolai Hähnle wrote:
On 22.08.2017 17:42, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/auxiliary/tgsi/tgsi_scan.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c
b/src/gallium/auxiliary/tg
On 21 August 2017 at 20:33, Rob Herring wrote:
> Pass the dri.sym version script to the linker. This ensures only
> explicitly exported symbols are exported and shrinks the library by up
> to 60KB.
>
> We need to pass "--undefined-version" because the Android build system
> sets --no-undefined-ver
On Tue, Aug 22, 2017 at 5:09 PM, Nicolai Hähnle wrote:
> Are you sure we really want this? I could well imagine badly coded
> applications that don't explicitly specify the required Z depth, but will
> have artifacts with 16 bits because they need the precision.
It's something I noticed. I don't
before:
dst.xy = (uint64_t) src0.x
dst.zw = (uint64_t) src0.y
after:
dst.xy = (int64_t) src0.x
dst.zw = (int64_t) src0.y
Signed-off-by: Mun Gwan-gyeong
---
src/gallium/docs/source/tgsi.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/docs/source/tg
On 22.08.2017 17:42, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/auxiliary/tgsi/tgsi_scan.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index 2fd7d7c..db87ce3 100644
-
From: Nicolai Hähnle
---
src/amd/common/ac_debug.c | 84 +--
1 file changed, 66 insertions(+), 18 deletions(-)
diff --git a/src/amd/common/ac_debug.c b/src/amd/common/ac_debug.c
index 518893ff481..e92dfbd0e4a 100644
--- a/src/amd/common/ac_debug.c
+++
From: Nicolai Hähnle
Use the correct type to fix pointer arithmetic.
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 37c12dea
From: Nicolai Hähnle
Help catch garbage data written into IBs.
---
src/amd/common/ac_debug.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/amd/common/ac_debug.c b/src/amd/common/ac_debug.c
index e92dfbd0e4a..2af83a146c8 100644
--- a/src/amd/common/ac_debug.c
+++ b
From: Nicolai Hähnle
Guard against out-of-bounds accesses, and prepare for upcoming changes.
---
src/amd/common/ac_debug.c | 368 +++---
1 file changed, 215 insertions(+), 153 deletions(-)
diff --git a/src/amd/common/ac_debug.c b/src/amd/common/ac_debug.c
From: Nicolai Hähnle
Various index-related fields are only initialized when required, so
they should only be dumped in those cases.
---
src/gallium/auxiliary/util/u_dump_state.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_dump_sta
From: Nicolai Hähnle
---
src/gallium/drivers/radeonsi/si_state.h | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.h
b/src/gallium/drivers/radeonsi/si_state.h
index ca701658d0b..26c7b4ca9a3 100644
--- a/src/gallium/drivers/rade
Hi all,
The two main changes here are related to amd/common IB parsing:
1. Prefix IB dumps with the raw hex values in the IB. For when you distrust
your debugging tools...
I've gone back and forth on how to implement this. It's a pity that
the stdlib has no way of "overloading" FILE, an
From: Marek Olšák
---
src/gallium/auxiliary/tgsi/tgsi_scan.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index 2fd7d7c..db87ce3 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
From: Nicolai Hähnle
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.c | 2 +-
src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c | 2 +-
src/gallium/auxiliary/tgsi/tgsi_dump.c | 2 +-
src/gallium/auxiliary/tgsi/tgsi_sanity.c| 6 --
src/gallium/auxiliary/tgsi/tgsi_text.c
From: Nicolai Hähnle
---
src/gallium/auxiliary/tgsi/tgsi_info.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c
b/src/gallium/auxiliary/tgsi/tgsi_info.c
index 0a82dbb14ca..472c088c7de 100644
--- a/src/gallium/auxiliary/tgsi
From: Nicolai Hähnle
So we can easily re-arrange members of tgsi_opcode_info, and readers of
the code don't have to guess what all the 0s mean.
Mostly done with regex search&replace.
---
src/gallium/auxiliary/Makefile.sources | 1 +
src/gallium/auxiliary/tgsi/tgsi_info.c | 262
From: Nicolai Hähnle
It's not clear why they were ever 2 bits to begin with. Perhaps
the original intent was to use signed values, but that doesn't
seem to have ever been the case in master.
---
src/gallium/auxiliary/tgsi/tgsi_info.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
dif
From: Nicolai Hähnle
They are only used for debug info.
Together with making tgsi_opcode_info::opcode a bitfield, this reduces
the size of tgsi_opcode_info on 64-bit systems from 24 bytes to 4 bytes,
and makes the whole data structure a bit more linker friendly.
---
src/gallium/auxiliary/tgsi/t
Hi all,
The recent changes and required rebases reminded me that I had
this series lying around :)
Basically, I'd been annoyed by the format of the TGSI opcode info
table for a long time, because it really discourages extensibility.
This series cleans that up and then does some obvious micro-
opt
Signed-off-by: Mun Gwan-gyeong
---
src/gallium/docs/source/tgsi.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index b148c3c939..f9b1385e55 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/
On Sun, Aug 20, 2017 at 12:32 AM, Roland Scheidegger wrote:
> Am 19.08.2017 um 21:32 schrieb Marek Olšák:
>> How about we remove all opcodes that are unused? Like:
>>
>> SAMPLE_POS
>> SAMPLE_INFO
>> SAMPLE
>> SAMPLE_I
>> SAMPLE_I_MS
>> SAMPLE_B
>> SAMPLE_C
>> SAMPLE_C_LZ
>> SAMPLE_D
>> SAMPLE_L
>>
With Eric's comment addressed, for the series:
Reviewed-by: Nicolai Hähnle
On 22.08.2017 12:39, Emil Velikov wrote:
From: Emil Velikov
The scripts are invoked with the correct version of python and are
missing the execute bit.
Follow the rest of Mesa and drop the shebang line.
Signed-off-b
Are you sure we really want this? I could well imagine badly coded
applications that don't explicitly specify the required Z depth, but
will have artifacts with 16 bits because they need the precision.
Cheers,
Nicolai
On 22.08.2017 16:39, Marek Olšák wrote:
From: Marek Olšák
---
src/mesa/
On Tue, Aug 22, 2017 at 10:51 AM, Roland Scheidegger wrote:
> I am probably missing something here, but why do you need a new register
> file? Since you couldn't use LOAD with TGSI_FILE_CONSTANT before, can't
> you just allow LOAD with TGSI_FILE_CONSTANT and achieve the same thing?
> Or do you nee
I am probably missing something here, but why do you need a new register
file? Since you couldn't use LOAD with TGSI_FILE_CONSTANT before, can't
you just allow LOAD with TGSI_FILE_CONSTANT and achieve the same thing?
Or do you need to know how it's going to be accessed in advance?
Roland
Am 22.08
On Tue, Aug 22, 2017 at 2:07 AM, Andres Gomez wrote:
> On Thu, 2017-08-10 at 12:51 -0700, Jason Ekstrand wrote:
> > On August 10, 2017 12:45:43 PM Ilia Mirkin wrote:
> >
> > > On Wed, Aug 9, 2017 at 4:09 PM, Kenneth Graunke
> wrote:
> > > > Also, silence an obnoxious finishme that started occur
On Tue, Aug 22, 2017 at 5:23 AM, Andres Gomez wrote:
> Jason, 76e2f390f9863a35 didn't land in 17.1 so I understand this is not
> really needed there and we only need it for 17.2.
>
> WDYT?
>
This only applies to 17.2
> On Sat, 2017-08-19 at 11:07 -0700, Jason Ekstrand wrote:
> > In 76e2f390f98
From: Marek Olšák
---
src/mesa/state_tracker/st_format.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 348853a..7a00a3e 100644
--- a/src/mesa/state_tracker/st_format.c
+++ b/src/mesa/state_tracke
https://bugs.freedesktop.org/show_bug.cgi?id=102318
Alex Granni changed:
What|Removed |Added
Summary|Scons build - LLVM 5.0 not |Mesa3D Scons build - LLVM
Am 22.08.2017 um 15:17 schrieb Jose Fonseca:
> On 22/08/17 12:28, Marek Olšák wrote:
>> On Tue, Aug 22, 2017 at 1:10 PM, Jose Fonseca
>> wrote:
>>> On 20/08/17 01:49, Marek Olšák wrote:
From: Marek Olšák
use COS+SIN instead.
>>>
>>>
>>> I don't know if any existing gallium dri
Hi Eric,
On 10 August 2017 at 23:43, Eric Anholt wrote:
> +aarch64)
> +DEFINES="$DEFINES -DUSE_AARCH64_ASM"
I cannot see any places where the define is used.
Am I missing something or there isn't any? Do you have some WIP
patches that make use of it?
Thanks
Emil
___
On 22/08/17 12:28, Marek Olšák wrote:
On Tue, Aug 22, 2017 at 1:10 PM, Jose Fonseca wrote:
On 20/08/17 01:49, Marek Olšák wrote:
From: Marek Olšák
use COS+SIN instead.
I don't know if any existing gallium driver leverages that, but it's a basic
trigonometric principle that one can easily
On 22 August 2017 at 12:07, Eric Engestrom wrote:
> On Tuesday, 2017-08-22 11:39:35 +0100, Emil Velikov wrote:
>> From: Emil Velikov
>>
>> Follow the example used through mesa and use "..." + "__VA_ARGS__".
>> The former tends to be more common and portable.
>>
>> Signed-off-by: Emil Velikov
>>
Jason, 76e2f390f9863a35 didn't land in 17.1 so I understand this is not
really needed there and we only need it for 17.2.
WDYT?
On Sat, 2017-08-19 at 11:07 -0700, Jason Ekstrand wrote:
> In 76e2f390f9863a35, when Topi switched num_samples from 0 to 1 for
> single-sampled, he accidentally switche
On 22.08.2017 14:10, Nicolai Hähnle wrote:
On 22.08.2017 13:00, Marek Olšák wrote:
On Tue, Aug 22, 2017 at 9:37 AM, Nicolai Hähnle
wrote:
On 18.08.2017 19:06, Marek Olšák wrote:
Ping.
On Wed, Aug 16, 2017 at 12:57 AM, Marek Olšák wrote:
From: Marek Olšák
The workaround will do for now.
Before this change we were defaulting to STD140 which is slightly
less efficient at packing arrays.
---
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
src/mesa/state_tracker/st_context.c| 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.
Fixes: 4c2422067b5c ("glsl: pass UseSTD430AsDefaultPacking to where it will be
used")
---
src/mesa/program/ir_to_mesa.cpp| 10 ++
src/mesa/program/ir_to_mesa.h | 3 ++-
src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp
This will be use to distinguish between load types when using
the TGSI_OPCODE_LOAD opcode.
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 1 +
src/gallium/include/pipe/p_shader_tokens.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
b/src/gallium
---
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 +
src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
src/gallium/drivers/i915/i915_screen.c | 1 +
src/gallium/drivers/llvmpipe/lp_screen.c | 1 +
src/gallium/d
v2: always set can_speculate and allow_smem to true
---
src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c | 31 +++
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_m
1 - 100 of 147 matches
Mail list logo