https://bugs.freedesktop.org/show_bug.cgi?id=105740
Bug ID: 105740
Summary: glsl_types.cpp(524): error: a dynamically-initialized
local static variable is not allowed inside of a
statement expression
Product: Mesa
Tested on Haswell. Patch works well for me, thanks!
Tested-by: Vadym Shovkoplias
On Fri, Mar 23, 2018 at 8:35 PM, Jason Ekstrand
wrote:
> Otherwise we may end up trying to coalesce in a case such as
>
> ssa_1 = fadd r1, r2
> r3.x = fneg(r2);
> r3 = vec4(ssa_1, ssa_1.y, ...)
>
> and that would
Fixes: ec478cf9c31c3775a21cd7b5b4b5cdd9263bde9e
st/mesa,tgsi: use enum tgsi_opcode
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105737
Signed-off-by: Gert Wollny
---
src/mesa/state_tracker/tests/st_tests_common.cpp | 6 +++---
src/mesa/state_tracker/tests/st_tests_common.h |
https://bugs.freedesktop.org/show_bug.cgi?id=105737
--- Comment #1 from Gert Wollny ---
Patch proposed:
https://patchwork.freedesktop.org/series/40651/
--
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=105738
--- Comment #3 from Samuel Pitoiset ---
I can reproduce a similar issue on my side, we are going to have a look,
Thanks!
--
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=105738
Samuel Pitoiset changed:
What|Removed |Added
CC||mar...@gmail.com
--
You are receivin
When mesa is compiled in debug mode then this adds the possibility
to print out some statistics about the translated shaders to a file.
The functionality is enabled by setting the environment variable
GLSL_TO_TGSI_PRINT_STATS
to the file name where the statistics should be collected. The file
Dear all,
this is the merged version of two series [1] (TGSI: split, merge
and interleave arrays) and [2] (mesa/st/glsl_to_tgsi: Properly
resolve life times for simple if/else + use constructs) I sent
earlier. Considering that both parts target the same optimization
step and fix a bug if both
in constructs like below, currently the live range estimation extends the live
range
of t unecessarily to the whole loop because it was not detected that t is
unconditional written and later read only in the "if (a)" scope.
while (foo) {
...
if (a) {
...
if (b)
t
Signed-off-by: Gert Wollny
---
.../state_tracker/st_glsl_to_tgsi_temprename.cpp | 61 +++---
.../state_tracker/st_glsl_to_tgsi_temprename.h | 2 +-
2 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
b/src/
In preparation of the array live range tracking the evaluation of the read
mask is moved out the register live range tracking to the enclosing call
of the reneralized read access tracking.
Signed-off-by: Gert Wollny
---
src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp | 15 ---
On one hand "live range" is the term used in the literature, and on the
other hand a distinction is needed from the array live ranges.
Signed-off-by: Gert Wollny
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 16 ++---
.../state_tracker/st_glsl_to_tgsi_temprename.cpp | 78 +++
Signed-off-by: Gert Wollny
---
src/mesa/Makefile.sources | 2 +
src/mesa/meson.build | 2 +
.../state_tracker/st_glsl_to_tgsi_array_merge.cpp | 283 +
.../state_tracker/st_glsl_to_tgsi_array_merge.h| 116 +
This patch ties in the array split, merge, and interleave code.
shader-db changes in the TGSI code are:
original code | array-merge | change in %
mean max | meanmax | mean -max
---
arrays 0.05
todo explain
Signed-off-by: Gert Wollny
---
.../state_tracker/st_glsl_to_tgsi_array_merge.cpp | 69 ++
.../state_tracker/st_glsl_to_tgsi_array_merge.h| 46 +++
2 files changed, 115 insertions(+)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_array_merge
Signed-off-by: Gert Wollny
---
.../state_tracker/st_glsl_to_tgsi_array_merge.cpp | 389 -
.../state_tracker/st_glsl_to_tgsi_array_merge.h| 26 +-
2 files changed, 413 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.cpp
b/sr
Signed-off-by: Gert Wollny
---
src/mesa/state_tracker/tests/Makefile.am | 20 +-
src/mesa/state_tracker/tests/st_tests_common.h | 7 +-
.../tests/test_glsl_to_tgsi_array_merge.cpp| 296 +
3 files changed, 317 insertions(+), 6 deletions(-)
create mode
v2: fix a crash when there is no subpass
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 7 +--
src/amd/vulkan/radv_pass.c | 12 ++--
src/amd/vulkan/radv_private.h| 1 +
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/r
Signed-off-by: Gert Wollny
---
.../state_tracker/st_glsl_to_tgsi_temprename.cpp | 102 +
1 file changed, 102 insertions(+)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
index b6e87e9a02..00c7155e1
Array who's elements are only accessed directly are replaced by the
according number of temporary registers. By doing so the otherwise
reserved register range becomes subject to further optimizations like
copy propagation and register merging.
Thanks to the resulting reduced register pressure this
Signed-off-by: Gert Wollny
---
.../state_tracker/st_glsl_to_tgsi_temprename.cpp | 61 +-
1 file changed, 49 insertions(+), 12 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
index 00c71
This fixes the bug for me, thanks,
Tested-by: Gert Wollny
Am Montag, den 26.03.2018, 10:31 +1100 schrieb Timothy Arceri:
> Just checking for 2 jumps is not enough to be sure we can do a
> complex loop unroll. We need to make sure we also have also found
> 2 loop terminators.
>
> Without this we
https://bugs.freedesktop.org/show_bug.cgi?id=105442
--- Comment #2 from i...@yahoo.com ---
Can you do a bisect between Mesa-17.2 and Mesa-17.3, using the same LLVM-5.0.1
?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
Negative deltas are used to fake a range in a large buffer.
See 900a5c91eeb3
"i965: Use negative relocation deltas to minimise vertex uploads"
Gen8+ use 48-bit address relocations so need to extend the sign
to 64-bit return value. Without it we have higher bits zeroed
and missing the negavive valu
Hello, Stuart.
Could You, please, test this patch?
On Mon, Mar 26, 2018 at 3:16 PM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:
> Negative deltas are used to fake a range in a large buffer.
> See 900a5c91eeb3
> "i965: Use negative relocation deltas to minimise vertex uploads"
>
> Gen8+
Quoting Sergii Romantsov (2018-03-26 13:16:24)
> Negative deltas are used to fake a range in a large buffer.
> See 900a5c91eeb3
> "i965: Use negative relocation deltas to minimise vertex uploads"
>
> Gen8+ use 48-bit address relocations so need to extend the sign
Note that 48-bit relocations were
Hey,
On 03/23/2018 06:21 PM, Emil Velikov wrote:
On 23 March 2018 at 16:20, Tomasz Figa wrote:
On Sat, Mar 24, 2018 at 12:55 AM, Emil Velikov wrote:
On 23 March 2018 at 13:15, Tomasz Figa wrote:
Perhaps we could try to use drmOpenWithType() [2]. We could have one
property that would be p
On Mon, Mar 26, 2018 at 9:45 PM, Robert Foss wrote:
> Hey,
>
> On 03/23/2018 06:21 PM, Emil Velikov wrote:
>>
>> On 23 March 2018 at 16:20, Tomasz Figa wrote:
>>>
>>> On Sat, Mar 24, 2018 at 12:55 AM, Emil Velikov
>>> wrote:
On 23 March 2018 at 13:15, Tomasz Figa wrote:
>
>>>
Hello, Chris. Thank you for reviewing patch.
Do you mean changing just only emit_reloc() parameter type or all the
preceding callers too?
Also, please, explain what you mean about patch cee9f3890351?
That issue is present even on mesa 13-0.0 and also solved with similar
type-conversion fix.
Rega
On 26 March 2018 at 14:08, Tomasz Figa wrote:
> On Mon, Mar 26, 2018 at 9:45 PM, Robert Foss
> wrote:
>> Hey,
>>
>> On 03/23/2018 06:21 PM, Emil Velikov wrote:
>>>
>>> On 23 March 2018 at 16:20, Tomasz Figa wrote:
On Sat, Mar 24, 2018 at 12:55 AM, Emil Velikov
wrote:
>
>
Quoting Sergii Romantsov (2018-03-26 14:11:26)
> Hello, Chris. Thank you for reviewing patch.
> Do you mean changing just only emit_reloc() parameter type or all the
> preceding
> callers too?
If you insist, but you don't have to. int32_t on the parameter is enough
to document and correct the typ
Ext_color_buffer_half_float is using type GL_HALF_FLOAT
and data_type GL_FLOAT. This fix Android CTS test android.view.cts.PixelCopyTest
v2: remove commtens of Ext_color_buffer_half_float. As Ext_color_buffer__float
can use type GL_HALF_FLOAT
Reviewed-by: Palli, Tapani
Signed-off-by: Lin Johnso
On 26 March 2018 at 13:31, Chris Wilson wrote:
> Quoting Sergii Romantsov (2018-03-26 13:16:24)
>> Negative deltas are used to fake a range in a large buffer.
>> See 900a5c91eeb3
>> "i965: Use negative relocation deltas to minimise vertex uploads"
>>
>> Gen8+ use 48-bit address relocations so need
Ext_color_buffer_half_float is using type GL_HALF_FLOAT
and data_type GL_FLOAT. This fix Android CTS test
android.view.cts.PixelCopyTest
v2: remove commtens of Ext_color_buffer_half_float.
As Ext_color_buffer__float can use type GL_HALF_FLOAT
Reviewed-by: Palli, Tapani
Signed-off-by: Lin Johnso
I assume this was implemented in a previous version of that commit, but
was removed in the version that actually landed.
Fixes: 8430af5ebe1ee8119e14 "Add support for swrast to the DRM EGL platform"
Cc: Giovanni Campagna
Cc: Emil Velikov
Signed-off-by: Eric Engestrom
---
src/gbm/gbm-symbols-che
https://bugs.freedesktop.org/show_bug.cgi?id=105740
Roland Scheidegger changed:
What|Removed |Added
Severity|normal |critical
Priority|medium
Hello, Emil. Thanks for involving.
> Fixes: cee9f3890351 ("i965: Allow 48-bit addressing on Gen8+.")
Actually that patch doesn't fix exactly cee9f3890351. Also I wrote earlier
(probably, my e-mails may go into spam :)):
"That issue is present even on mesa 13-0.0 and also solved with similar
type-c
Reviewed-by: Brian Paul
Sorry for the breakage.
-Brian
On 03/26/2018 02:17 AM, Gert Wollny wrote:
Fixes: ec478cf9c31c3775a21cd7b5b4b5cdd9263bde9e
st/mesa,tgsi: use enum tgsi_opcode
Bugzilla:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fi
Ping.
This is the only pending patch to review from this series. Although it is
independent enough and I could submit to master the rest of the series, I would
prefer to push all the series, and move to shape a second batch without pending
patches around.
Thanks in advance.
On 08/03/18 09:1
Am Montag, den 26.03.2018, 08:46 -0600 schrieb Brian Paul:
> Reviewed-by: Brian Paul
I forgot to mention: I can't push, could you take care of this?
Thanks,
Gert
>
> Sorry for the breakage.
>
> -Brian
>
> On 03/26/2018 02:17 AM, Gert Wollny wrote:
> > Fixes: ec478cf9c31c3775a21cd7b5b4b5cd
https://bugs.freedesktop.org/show_bug.cgi?id=105737
Brian Paul changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Wed, 2018-03-07 at 00:16 -0800, Jordan Justen wrote:
> Ken suggested that we might be underallocating scratch space on HD
> 400. Allocating scratch space as though there was actually 8 EUs
> seems to help with a GPU hang seen on synmark CSDof.
>
FYI, in order to pick this commit for next 17.3
Reviewed-by: Karol Herbst
On Sun, Mar 25, 2018 at 8:02 PM, Pierre Moreau wrote:
> Signed-off-by: Pierre Moreau
> ---
> src/gallium/state_trackers/clover/api/program.cpp | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/api/program.cpp
> b/src/ga
On Wed, Mar 21, 2018 at 10:09 AM, Eric Engestrom
wrote:
> Cc: Maxin B. John
> Cc: Khem Raj
> Suggested-by: Jon Turney
> Signed-off-by: Eric Engestrom
> ---
> configure.ac| 1 +
> meson.build | 2 +-
> src/util/u_endian.h | 2 +-
> 3 files changed, 3 insertions(+), 2 deletions(
2018-03-22 16:23 GMT+08:00 Tomasz Figa :
> Hi Chih-Wei,
>
> On Thu, Feb 22, 2018 at 2:53 PM, Chih-Wei Huang wrote:
>> 2018-02-21 3:03 GMT+08:00 Rob Herring :
>>>
>>> Perhaps worth revisiting. Given we've failed to progress at all since
>>> then may change opinions some. We already have to handle m
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/include/state_tracker/graw.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/include/state_tracker/graw.h
b/src/gallium/include/state_tracker/graw.h
index 217fa31ba1..78ddf0a87f 100644
--- a/src/gallium/include/stat
Quoting Alyssa Rosenzweig (2018-03-26 08:56:53)
> Signed-off-by: Alyssa Rosenzweig
> ---
> src/gallium/include/state_tracker/graw.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/include/state_tracker/graw.h
> b/src/gallium/include/state_tracker/graw.h
> in
On 03/25/2018 04:31 PM, Timothy Arceri wrote:
> Just checking for 2 jumps is not enough to be sure we can do a
> complex loop unroll. We need to make sure we also have also found
> 2 loop terminators.
>
> Without this we were attempting to unroll a loop where the second
> jump was nesed inside mul
From: Emil Velikov
Update the macro to have the explic return. Using the current GCC
specific macro breaks other compilers such as the Intel one or MSVC.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105740
Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
Cc: Rob Clark
Cc: Timothy Arcer
On March 26, 2018 07:53:44 Alejandro Piñeiro wrote:
Ping.
This is the only pending patch to review from this series. Although it is
independent enough and I could submit to master the rest of the series, I
would prefer to push all the series, and move to shape a second batch
without pending
Otherwise meson won't read the VERSION file and won't set a version.
That means that pkg-config files will have version unset as well.
Signed-off-by: Dylan Baker
fixes: 3e9533d9b88d75d99632fa40e38cfed842d10842
("meson: Add script to use VERSION file for getting version")
---
Makefile.am |
FixeS: 272bef0601a1bdb5292771aefc8d62fcbdf4c47f
("intel: Split gen_device_info out into libintel_dev")
Signed-off-by: Dylan Baker
---
src/intel/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/Makefile.am b/src/intel/Makefile.am
index bfb7f5b9f08..2f96a68d992 10064
https://bugs.freedesktop.org/show_bug.cgi?id=105371
mirh changed:
What|Removed |Added
CC||m...@protonmail.ch
--
You are receiving this ma
On Mon, Mar 26, 2018 at 9:45 AM, Emil Velikov wrote:
> From: Emil Velikov
>
> Update the macro to have the explic return. Using the current GCC
> specific macro breaks other compilers such as the Intel one or MSVC.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105740
> Fixes: f407edf
Optional binding of variables can be processed before linking shader
objects for creating shader program. It is activated by adding lines
with a keyword "BindAttribLoc" followed by name and index as,
"BindAttribLoc name_str1 "
For example,
[require]
..
BindAttrbLoc vertex 1
BindAttrbLoc coor
https://bugs.freedesktop.org/show_bug.cgi?id=104665
mirh changed:
What|Removed |Added
CC||m...@protonmail.ch
--
You are receiving this ma
As much as I'm not a fan of C++ templates, I don't see how this
preprocessor macro reinvention of that mechanism is an improvement.
On 03/26/2018 09:45 AM, Emil Velikov wrote:
> From: Emil Velikov
>
> Update the macro to have the explic return. Using the current GCC
> specific macro breaks other
On 03/26/2018 01:33 PM, Ian Romanick wrote:
> As much as I'm not a fan of C++ templates, I don't see how this
> preprocessor macro reinvention of that mechanism is an improvement.
At least if we're going to do this, can we put the whole body of the
function in the macro, as is done elsewhere?
> O
I split all the stuff that might interfere into this nice set of patches?
They've gone through intel-ci fine.
Anyone? if not I suppose I can review Elie's stuff and he can review mine :-)
Dave.
On 12 March 2018 at 15:14, Dave Airlie wrote:
> I've been fixing up Elie's work and although the pro
correct me if I'm wrong, but I don't see how you could do the ## stuff
to construct the built-in type name with templates. So I think the
options are tons of copy/pasta code (ie. what we had before) or
macros.
I agree that could just construct the whole method with the macro.. I
like that better
Am 26.03.2018 um 23:01 schrieb Rob Clark:
> correct me if I'm wrong, but I don't see how you could do the ## stuff
> to construct the built-in type name with templates. So I think the
> options are tons of copy/pasta code (ie. what we had before) or
> macros.
>
> I agree that could just construct
On 03/26/2018 02:01 PM, Rob Clark wrote:
> correct me if I'm wrong, but I don't see how you could do the ## stuff
> to construct the built-in type name with templates. So I think the
> options are tons of copy/pasta code (ie. what we had before) or
> macros.
That is true... I don't know why my ey
On Mon, Mar 26, 2018 at 6:07 PM, Roland Scheidegger wrote:
> Am 26.03.2018 um 23:01 schrieb Rob Clark:
>> correct me if I'm wrong, but I don't see how you could do the ## stuff
>> to construct the built-in type name with templates. So I think the
>> options are tons of copy/pasta code (ie. what w
Thanks all for the input.
I don't have an in-depth knowledge of the hardware either, though as
far as we can see the hardware does expect that we pass min_index in
the command stream. max_index is used to calculate the sizes in other
command stream fields (which is not the same as pipe_draw_info.c
On Mon, Mar 26, 2018 at 6:38 PM, Rob Clark wrote:
> On Mon, Mar 26, 2018 at 6:07 PM, Roland Scheidegger
> wrote:
>> Am 26.03.2018 um 23:01 schrieb Rob Clark:
>>> correct me if I'm wrong, but I don't see how you could do the ## stuff
>>> to construct the built-in type name with templates. So I t
The VECN() macro was taking advantage of a GCC specific feature that is
not available on lesser compilers, mostly for the purposes of avoiding a
macro that encoded a return statement.
But as suggested by Ian, we could just have the macro produce the entire
method body and avoid the need for this.
Acked-by: Timothy Arceri
On 27/03/18 09:49, Rob Clark wrote:
The VECN() macro was taking advantage of a GCC specific feature that is
not available on lesser compilers, mostly for the purposes of avoiding a
macro that encoded a return statement.
But as suggested by Ian, we could just have the m
in glapi_dispatch.c, as we have for many other GLES functions.
Fixes a cross-compile issue (missing prototype) when GLES support
is disabled.
---
src/mapi/glapi/glapi_dispatch.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mapi/glapi/glapi_dispatch.c b/src/mapi/glapi/glapi_dispatch.c
Am 27.03.2018 um 00:44 schrieb Rob Clark:
> On Mon, Mar 26, 2018 at 6:38 PM, Rob Clark wrote:
>> On Mon, Mar 26, 2018 at 6:07 PM, Roland Scheidegger
>> wrote:
>>> Am 26.03.2018 um 23:01 schrieb Rob Clark:
correct me if I'm wrong, but I don't see how you could do the ## stuff
to constru
Looks nicer in any case.
Reviewed-by: Roland Scheidegger
Am 27.03.2018 um 00:49 schrieb Rob Clark:
> The VECN() macro was taking advantage of a GCC specific feature that is
> not available on lesser compilers, mostly for the purposes of avoiding a
> macro that encoded a return statement.
>
> Bu
https://bugs.freedesktop.org/show_bug.cgi?id=105755
Bug ID: 105755
Summary: Mesa freezes when the GLSL shader contains a `for`
loop with an uninitialized `i` index/counter variable
Product: Mesa
Version: unspecified
Hardwar
On Mon, Mar 26, 2018 at 6:39 PM, Erico Nunes wrote:
> Thanks all for the input.
>
> I don't have an in-depth knowledge of the hardware either, though as
> far as we can see the hardware does expect that we pass min_index in
> the command stream. max_index is used to calculate the sizes in other
>
https://bugs.freedesktop.org/show_bug.cgi?id=105755
--- Comment #1 from Swyter ---
Created attachment 138365
--> https://bugs.freedesktop.org/attachment.cgi?id=138365&action=edit
default.vert
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=105755
--- Comment #2 from Swyter ---
Created attachment 138366
--> https://bugs.freedesktop.org/attachment.cgi?id=138366&action=edit
default-fixed.frag
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assigne
Build mesa 7298 failed
Commit 7d2079908d by Marek Olšák on 3/21/2018 8:10 PM:
winsys/amdgpu: always allow GTT placements on APUs\n\nReviewed-by: Christian König
Configure your notification preferences
___
https://bugs.freedesktop.org/show_bug.cgi?id=105755
--- Comment #3 from Swyter ---
Created attachment 138367
--> https://bugs.freedesktop.org/attachment.cgi?id=138367&action=edit
glxinfo.txt
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for t
https://bugs.freedesktop.org/show_bug.cgi?id=105755
--- Comment #4 from Ilia Mirkin ---
The shader compiler provides warnings:
$ bin/glslparsertest foo.frag pass 1.30
Successfully compiled fragment shader foo.frag: 0:54(14): warning: `i' used
uninitialized
0:58(39): warning: `i' used uninitializ
Reviewed-by: Sinclair Yeh
On Mon, Mar 26, 2018 at 04:56:22PM -0600, Brian Paul wrote:
> in glapi_dispatch.c, as we have for many other GLES functions.
> Fixes a cross-compile issue (missing prototype) when GLES support
> is disabled.
> ---
> src/mapi/glapi/glapi_dispatch.c | 2 ++
> 1 file chang
On Sun, Mar 25, 2018 at 6:32 PM, Timothy Arceri
wrote:
> When an if nesting inside anouther if is optimised away we can
> end up with a loop terminator and following block that looks like
> this:
>
> if ssa_596 {
> block block_5:
> /* preds: block_4 */
>
Buffers are always page aligned on 965+ hardware; I believe this extra
parameter is a vestige from the Gen2-3 era.
All callers pass 0, and in fact we assert that the alignment is 0 unless
BO_ALLOC_BUSY is set (for some reason). We can just drop the parameter
and set the value to 0 explicitly.
---
bo->align is always 0; there's no need to waste 8 bytes storing it.
Thanks to C99 initializers zeroing fields, we can completely drop the
only read of the field altogether.
---
src/mesa/drivers/dri/i965/brw_bufmgr.c| 2 --
src/mesa/drivers/dri/i965/brw_bufmgr.h| 7 ---
src/mesa
brw_bo_alloc no longer uses this parameter, so there's no point.
---
src/mesa/drivers/dri/i965/brw_blorp.c | 2 +-
src/mesa/drivers/dri/i965/brw_bufmgr.c| 2 +-
src/mesa/drivers/dri/i965/brw_bufmgr.h| 2 +-
src/mesa/drivers/dri/i965/brw_performance_query.c | 5 +
intel_miptree_create_for_bo does not actually allocate a BO, so
specifying allocation flags accomplishes nothing and is confusing.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
From: Marek Olšák
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105738
---
src/amd/common/ac_surface.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 12dfc0cb1f2..81882576baf 100644
--- a/src/amd/common/ac_surf
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_pipe.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index fa9ee43389a..1cc08c5feed 100644
--- a/src/gallium/drivers/radeonsi/si_pi
From: Marek Olšák
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105738
---
src/amd/common/ac_surface.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 12dfc0cb1f2..81882576baf 100644
--- a/src/amd/common/ac_surf
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_texture.c | 29 +
1 file changed, 9 insertions(+), 20 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index 1614df63c98..eb6706c9dcd 100644
--- a/sr
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_pipe.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index fa9ee43389a..1cc08c5feed 100644
--- a/src/gallium/drivers/radeonsi/si_pi
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 8ae742c93f6..00ebbb9b0f2 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/
It looks like there are a couple places in brw_fs_nir.cpp
(emit_system_values_block and fs_visitor::nir_emit_vs_intrinsic) that
handle nir_intrinsic_load_base_instance but not
nir_intrinsic_load_first_vertex. Should those cases be added?
I have pushed a branch to my fd.o repo called gl_VertexID-f
https://bugs.freedesktop.org/show_bug.cgi?id=105755
Swyter changed:
What|Removed |Added
CC||swyterzone+mes...@gmail.com
--- Comment #5 fro
https://bugs.freedesktop.org/show_bug.cgi?id=105755
--- Comment #6 from Ian Romanick ---
Swyter: Can you run your program in gdb, interrupt it during the hang, and
provide a backtrace?
Reading Ilia's response, it seems that the trivial glslsparsertest based test
case doesn't reproduce the hang.
https://bugs.freedesktop.org/show_bug.cgi?id=105755
--- Comment #7 from Ilia Mirkin ---
(In reply to Ian Romanick from comment #6)
> Swyter: Can you run your program in gdb, interrupt it during the hang, and
> provide a backtrace?
>
> Reading Ilia's response, it seems that the trivial glslsparse
Rb
On March 26, 2018 16:52:40 Kenneth Graunke wrote:
intel_miptree_create_for_bo does not actually allocate a BO, so
specifying allocation flags accomplishes nothing and is confusing.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
di
From: Ian Romanick
Future changes will add generated files used only from
src/compiler/glsl. These can't be built from Makefile.nir.am, and we
can't move all the rules from Makefile.nir.am to Makefile.spirv.am (and
it would be silly anyway).
v2: Do it for meson too.
Signed-off-by: Ian Romanick
Most of these patches have been on the list at least once. Major
changes are:
- Patches 1, 6, and 7 had a bunch of changes due to rebasing.
- Patches 2 had some minor changes due to rebasing.
- Patches 3 and 8 are new.
Only patches 4 and 5 should be unchanged. The whole series passes the
Inte
From: Ian Romanick
src/mesa/drivers/dri/i965/brw_draw_upload.c: In function ‘double_types’:
src/mesa/drivers/dri/i965/brw_draw_upload.c:225:34: warning: unused parameter
‘brw’ [-Wunused-parameter]
double_types(struct brw_context *brw,
^~~
Signed-off-by: Ian Ro
From: Ian Romanick
Previously bitset.h would include u_math.h to get bitscan.h. u_math.h
lives in src/gallium/auxiliary/util while both bitset.h and bitscan.h
live in src/util. Having the one file directly include another file
that lives in the same directory makes much more sense.
As a side-e
From: Ian Romanick
Previously size=0, element_size=0 would have been allowed. That
combination can only lead to despair.
Signed-off-by: Ian Romanick
---
src/util/u_vector.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/util/u_vector.c b/src/util/u_vector.c
index
From: Ian Romanick
The new name make the zero-input behavior more obvious. The next
patch adds a new function with different zero-input behavior.
Signed-off-by: Ian Romanick
Suggested-by: Matt Turner
---
src/amd/common/ac_gpu_info.c | 4 ++--
src/amd/common/ac_su
1 - 100 of 120 matches
Mail list logo
