While disassembling the predicate always print flag subregister number
to keep grammar same across the generation for assembler tool.
v2: Club consecutive format calls (Matt Turner)
Signed-off-by: Sagar Ghuge
---
src/intel/compiler/brw_disasm.c | 13 ++---
1 file changed, 6 insertions(+
When RepCtrl is set, the swizzle field is ignored by the hardware. In
order to ensure a 1-to-1 correspondence between the human-readable
disassembly and the binary instruction encoding always set the swizzle
to (all zeros) when it is unused due to RepCtrl
Signed-off-by: Sagar Ghuge
Reviewed-
https://bugs.freedesktop.org/show_bug.cgi?id=108933
--- Comment #12 from Gustaw Smolarczyk ---
(In reply to iive from comment #10)
> You solved the mystery!
>
> It makes sense since this is the last called function in the disassembly.
>
> I can confirm that the issue does go away after changing
https://bugs.freedesktop.org/show_bug.cgi?id=108933
--- Comment #11 from i...@yahoo.com ---
(In reply to iive from comment #10)
> I can confirm that the issue does go away after changing the string
> "__dynamic_cast" to "__dynamicZcast" in Core.so .
That doesn't work. It is enough for the game t
https://bugs.freedesktop.org/show_bug.cgi?id=108933
--- Comment #10 from i...@yahoo.com ---
(In reply to Gustaw Smolarczyk from comment #9)
> The Core.so binary seems to export the __dynamic_cast symbol. It suggests
> that it has been statically linked with some old libstdc++ library that is
> inc
On Sat, Dec 8, 2018 at 7:03 PM Rhys Perry wrote:
>
> A small number of questions/concerns:
>
> - sampleLocationCoordinateRange[1] should probably be set to 0.9375,
> because of how the sample locations are encoded
> - gl_SamplePosition doesn't seem like it would return the new sample
> locatio
On Thu, Nov 22, 2018 at 1:05 PM Matt Turner wrote:
>
> On Wed, Nov 21, 2018 at 10:48 AM Matt Turner wrote:
> >
> > Thanks Arfrever and Dylan.
> >
> > Acked-by: Matt Turner
>
> Hmm, actually this doesn't seem to work for me. With it applied I get:
>
> src/mesa/drivers/dri/meson.build:59:8: ERROR:
https://bugs.freedesktop.org/show_bug.cgi?id=100960
--- Comment #19 from Fabian Maurer ---
Hey there, sorry for the late answer.
The mod has fixed the issue in its latest version, so for me this issue isn't
relevant anymore. Do we still want a change in this, or do we consider this a
"NOTOURBUG"
https://bugs.freedesktop.org/show_bug.cgi?id=108933
--- Comment #9 from Gustaw Smolarczyk ---
(In reply to iive from comment #8)
> I've already tried placing "#include " before "iostream", but it has
> no effect. I retested it to be sure.
That won't do anything. The locale stuff is handled by li
https://bugs.freedesktop.org/show_bug.cgi?id=108933
--- Comment #8 from i...@yahoo.com ---
(In reply to Gustaw Smolarczyk from comment #7)
> Static initialization order is undefined between translation units (i.e.
> source files) but it is defined within one translation unit - it is the
> global v
Rb
On December 8, 2018 12:28:56 Rob Clark wrote:
Signed-off-by: Rob Clark
---
src/compiler/nir/nir_linking_helpers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_linking_helpers.c
b/src/compiler/nir/nir_linking_helpers.c
index a05890ada43..1ab9c095
Previously, if we had a .z or .w component that could be compacted
to .y, we'd could overlook that opportunity.
Signed-off-by: Rob Clark
---
src/compiler/nir/nir_linking_helpers.c | 30 --
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/src/compiler/nir/nir
Signed-off-by: Rob Clark
---
src/compiler/nir/nir_linking_helpers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_linking_helpers.c
b/src/compiler/nir/nir_linking_helpers.c
index a05890ada43..1ab9c095657 100644
--- a/src/compiler/nir/nir_linking_helpers
Not entirely sure when this changed, but it seem like
LinkedTransformFeedback is (usually?) populated, even if
NumVaryings is zero. So make the check about whether it
is safe to nir_compact_varyings() a bit more complete.
Signed-off-by: Rob Clark
---
src/mesa/state_tracker/st_glsl_to_nir.cpp |
On Sat, Dec 8, 2018 at 12:10 PM Karol Herbst wrote:
>
> opnd() might delete the passed in instruction, but it's used through
> i->srcExists() later in visit
>
> v2: use continue instead return
Can you verify that this change has no effect on compilation results
(at least the high-level stats) for
A small number of questions/concerns:
- sampleLocationCoordinateRange[1] should probably be set to 0.9375,
because of how the sample locations are encoded
- gl_SamplePosition doesn't seem like it would return the new sample
locations
- R_028BD4_PA_SC_CENTROID_PRIORITY_{0,1} isn't updated. I'm
Reviewed-by: Ilia Mirkin
On Sat, Dec 8, 2018 at 12:10 PM Karol Herbst wrote:
>
> multiple threads can write to those at the same time
>
> Signed-off-by: Karol Herbst
> ---
> src/gallium/drivers/nouveau/nouveau_screen.h | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --gi
opnd() might delete the passed in instruction, but it's used through
i->srcExists() later in visit
v2: use continue instead return
Signed-off-by: Karol Herbst
---
.../nouveau/codegen/nv50_ir_peephole.cpp | 71 +++
1 file changed, 43 insertions(+), 28 deletions(-)
diff --gi
multiple threads can write to those at the same time
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/nouveau_screen.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.h
b/src/gallium/drivers/nouveau/nouveau_screen.
https://bugs.freedesktop.org/show_bug.cgi?id=108933
--- Comment #7 from Gustaw Smolarczyk ---
Static initialization order is undefined between translation units (i.e. source
files) but it is defined within one translation unit - it is the global
variable definition order. Since #include defines
https://bugs.freedesktop.org/show_bug.cgi?id=108933
--- Comment #6 from i...@yahoo.com ---
Created attachment 142752
--> https://bugs.freedesktop.org/attachment.cgi?id=142752&action=edit
Workaround for mesa crashing on UT99 because of static global constructor from
C++ iostream
Just few observa
Instead of a custom ARB_gl_spirv xfb gather info pass.
In fact, this is not only about reusing code, but the current custom
code was not handling properly how many varyings are enumerated from
some complex types. So this change is also about fixing some corner
cases.
---
src/compiler/glsl/gl_nir_
On OpenGL, a array of a simple type adds just one varying. So
gl_transform_feedback_varying_info struct defined at mtypes.h includes
the parameters Type (base_type) and Size (number of elements).
This commit checks this when the recursive add_var_xfb_outputs call
handles arrays, to ensure that jus
In order to allow nir_gather_xfb_info to be used on OpenGL,
specifically ARB_gl_spirv.
So, from OpenGL 4.6 spec, section 11.1.2.1, "Output Variables":
"outputs specifying both an *XfbBuffer* and an *Offset* are
captured, while outputs not specifying both of these are not
captured. V
In order to be used for OpenGL (right now for ARB_gl_spirv).
This commit adds two new structures:
* nir_xfb_varying_info: that identifies each individual varying. For
each one, we need to know the type, buffer and xfb_offset
* nir_xfb_buffer_info: as now for each buffer, in addition to t
Current code assumes that if the type is an struct it would behave as
a block. That is not always the case (like xfb_offset/xfb_buffer
assignment on arrays of structs vs arrays of blocks), so we need to
differentiate.
---
src/compiler/spirv/vtn_variables.c | 17 +
1 file changed, 1
From GLSL 4.60 spec, Section 4.4.2. Output Layout Qualifiers,
subsection Transform Feedback Layout Qualifiers:
"When a block is declared as an array, all members of block
array-element 0 are captured, as previously described, by the
declared or inherited xfb_buffer. Generally, an array
In the same way that just a struct is not a interface block, and array
of structs is not an array of interface blocks.
At least at the NIR level.
---
src/compiler/spirv/vtn_variables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/spirv/vtn_variables.c
b/src/co
GLSLang computes the xfb_offset for struct members. In fact, for basic
structs, the xfb nir gathering pass expect those to be filled, as one
struct variable is lowered to several nir variables, and those need to
have the xfb offset already set. See [1].
But, as one existing comments at spirv to ni
Hi Jason,
as we were talking about arrays of blocks, xfb and other etc, I
decided to clean up the code I have so far, and send a new RFC, so you
know more or less what I have been doing.
With this series most of the xfb tests I have wrotten pass so far
(that includes arrays of structs, arrays of
Where component_offset here is the offset when accessing components of
a packed variable. Or in other words, location_frac on
nir.h. Different places of mesa use different names for it.
Technically nir_xfb_info consumer can get the same from the
component_mask, it seems somewhat forced to make it
Now Vulkan radv driver, and ARB_gl_spirv implementation supports
transform feedback. Having said so, those decorations are handled
elsewhere.
Reviewed-by: Jason Ekstrand
---
src/compiler/spirv/spirv_to_nir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/spirv/s
This commit removes several of the checks when assigning the
array_element as the interface_type. Reading the comment, and what
commit bb04b84114d2780307f9cbd04447216c3f2d1c0c added on top, this is
done conservatively, for only the builtin cases that makes sense at
that moment. But even if those we
Equivalent to previous patch (so comments applies), but implemented on
a different place. We would need to chose in which one.
---
src/compiler/nir/nir_gather_xfb_info.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/src/compiler/nir/nir_gather_xfb_info.c
b/src/compi
The offset compute was working fine for the case of attrib_slots=1,
and updating the offset for the following varying.
But in the case of attrib_slots=2 (so dvec3/4), we are basically
splitting the comp_slots needed in two outputs. In that case we can't
add to the offset the full size of the type.
https://bugs.freedesktop.org/show_bug.cgi?id=108977
--- Comment #1 from Matthieu Bouron ---
Comment on attachment 142750
--> https://bugs.freedesktop.org/attachment.cgi?id=142750
EGL pbuffer test
>#include
>#include
>#include
>#include
>#include
>
>#include
>
>#define WIDTH 4
>#define HE
https://bugs.freedesktop.org/show_bug.cgi?id=108977
Bug ID: 108977
Summary: Reading back an EGL Pbuffer using the OpenGL API
returns garbled output
Product: Mesa
Version: 18.2
Hardware: Other
OS: All
37 matches
Mail list logo
