Hi Kenneth,
El 2014-07-09 17:19, Kenneth Graunke escribió:
On Tuesday, July 08, 2014 11:19:38 AM Iago Toral wrote:
Hi,
I have some code that first initializes a register and then
overwrites a
specific subregister. However, after the optimization passes in
brw_vec4.cpp the
Hello Giovanni,
On Thu, 3 Jul 2014 11:14:48 +0200
Giovanni Campagna scampa.giova...@gmail.com wrote:
2014-07-03 10:48 GMT+02:00 Boris BREZILLON
boris.brezil...@free-electrons.com:
Hello Giovanni,
I have recently been working on a DRM/KMS driver which does not support
OpenGL rendering
https://bugs.freedesktop.org/show_bug.cgi?id=81162
Priority: medium
Bug ID: 81162
Assignee: mesa-dev@lists.freedesktop.org
Summary: Multicore Rendering issue on Intel Ironlake Mobile
chipsets
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=81174
Priority: medium
Bug ID: 81174
Assignee: mesa-dev@lists.freedesktop.org
Summary: Gallium: GL_LINE_LOOP broken with more than 512 points
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=81174
Ilia Mirkin imir...@alum.mit.edu changed:
What|Removed |Added
Attachment #102536|text/plain |image/png
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #1 from Florian Link florianl...@gmail.com ---
Created attachment 102537
-- https://bugs.freedesktop.org/attachment.cgi?id=102537action=edit
A Qt example that demonstrates the problem
--
You are receiving this mail because:
You
On Mon, Jul 07, 2014 at 12:27:29PM +0100, Neil Roberts wrote:
Pohjolainen, Topi topi.pohjolai...@intel.com writes:
All the other state flags considered in _mesa_meta_begin() are
explicitly set as disabled. And having noticed that you
unconditionally disable dithering also in
https://bugs.freedesktop.org/show_bug.cgi?id=80183
--- Comment #2 from Florian Link florianl...@gmail.com ---
I found out that the problem is the line:
gl_ClipVertex = gl_ModelViewMatrix * gl_Vertex;
in the fragment shader. If I remove that line, it works as expected.
Since the rendering is ok
https://bugs.freedesktop.org/show_bug.cgi?id=80183
--- Comment #3 from Brian Paul bri...@vmware.com ---
(In reply to comment #2)
I found out that the problem is the line:
gl_ClipVertex = gl_ModelViewMatrix * gl_Vertex;
in the fragment shader. If I remove that line, it works as expected.
No, that's the same experiment I would have run. I was hoping the original
authors could chime in, but it sounds like you have more insight via AoA
work.
I'll resubmit with your change, thanks!
-C
On Wed, Jul 9, 2014 at 5:36 PM, Timothy Arceri t_arc...@yahoo.com.au
wrote:
On Wed,
On Tue, Jul 08, 2014 at 03:37:02AM +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
Needed by ARB_draw_indirect.
I think we should come up with a rule for how long we should support
older versions of LLVM. Do you have any thoughts about this? I was
thinking we could have each
On Tue, Jul 08, 2014 at 01:37:02AM +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This is a follow-up to the commit which adds texture fetches with offsets.
Will this still work with LLVM 3.4.2 ?
-Tom
---
src/gallium/drivers/radeonsi/si_shader.c | 29
On Tue, Jul 08, 2014 at 01:37:03AM +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
Reviewed-by: Tom Stellard thomas.stell...@amd.com
---
src/gallium/drivers/radeonsi/si_blit.c| 2 +-
src/gallium/drivers/radeonsi/si_descriptors.c | 12 +-
https://bugs.freedesktop.org/show_bug.cgi?id=80183
--- Comment #4 from Florian Link florianl...@gmail.com ---
Sorry, that was a typo, of course it is in the vertex shader.
--
You are receiving this mail because:
You are the assignee for the bug.
___
On Mon, Jul 07, 2014 at 05:50:05PM +0200, Bruno Jiménez wrote:
Now, before moving everything to host memory, we try to create a
new resource to use as a pool. I we succeed we just use this resource
and delete the previous one. If we fail we fallback to using the
shadow.
This should make
Before, we were checking the level against view-u.tex.last_level but
level is not valid for buffers. Plus, the aliasing of the view-u.tex
view-u.buf members (a union) caused the level checking arithmetic to
be totally wrong. The net effect is we always returned early for
PIPE_BUFFER size
---
src/gallium/docs/source/tgsi.rst |2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 8cbb3d8..c267b2c 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -968,6 +968,8 @@ XXX
On Thu, Jul 10, 2014 at 11:43 AM, Brian Paul bri...@vmware.com wrote:
---
src/gallium/docs/source/tgsi.rst |2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/docs/source/tgsi.rst
b/src/gallium/docs/source/tgsi.rst
index 8cbb3d8..c267b2c 100644
---
On Thu, Jul 10, 2014 at 11:46 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Jul 10, 2014 at 11:43 AM, Brian Paul bri...@vmware.com wrote:
---
src/gallium/docs/source/tgsi.rst |2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/docs/source/tgsi.rst
Vectors are falling in to the ir_dereference_array() path.
Without this change, the following glsl aborts the debug driver,
or gets the wrong answer in release:
mat2x2 a = mat2( vec2( 1.0, vertex.x ), vec2( 0.0, 1.0 ) );
Also submitting piglit tests, will reference in bug.
v2: Rebase on Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=81174
Benjamin Bellec b.bel...@gmail.com changed:
What|Removed |Added
CC||b.bel...@gmail.com
Am 10.07.2014 17:43, schrieb Brian Paul:
Before, we were checking the level against view-u.tex.last_level but
level is not valid for buffers. Plus, the aliasing of the view-u.tex
view-u.buf members (a union) caused the level checking arithmetic to
be totally wrong. The net effect is we
On 07/10/2014 09:50 AM, Ilia Mirkin wrote:
On Thu, Jul 10, 2014 at 11:46 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Jul 10, 2014 at 11:43 AM, Brian Paul bri...@vmware.com wrote:
---
src/gallium/docs/source/tgsi.rst |2 ++
1 file changed, 2 insertions(+)
diff --git
On Thu, Jul 10, 2014 at 1:13 PM, Brian Paul bri...@vmware.com wrote:
On 07/10/2014 09:50 AM, Ilia Mirkin wrote:
On Thu, Jul 10, 2014 at 11:46 AM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Thu, Jul 10, 2014 at 11:43 AM, Brian Paul bri...@vmware.com wrote:
---
Yes, that sounds good. We should always support the latest stable
version of LLVM, but I don't think it's worth supporting anything
older than that.
It's also important to have the latest LLVM because it's sometimes the
only way to get the new features which are mentioned in the release
notes of
---
src/glsl/ir_hierarchical_visitor.cpp | 158 +--
src/glsl/ir_hierarchical_visitor.h | 29 +--
src/glsl/ir_validate.cpp | 12 +--
3 files changed, 126 insertions(+), 73 deletions(-)
diff --git a/src/glsl/ir_hierarchical_visitor.cpp
If we saw a tree that looked like
vec3
/ \
vec3 float
/ \
vec3 float
/ \
vec3 float
We would see that all of the expression types were vec3, and then
rebalance to
vec3
/\
vec3 vec3 -- should be
Should potentially allow a few more cases, while avoiding doing CSE on
texture operations on Gen = 6 with the MRF.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80211
---
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #2 from Benjamin Bellec b.bel...@gmail.com ---
Is that a regression ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=78716
--- Comment #9 from oscar garcia rtf...@gmail.com ---
Hi, seems now on unreal wiki there is a page with most content
demos compiled using some form of 4.3 preview so should have bugs fixed
querying tess info etc.. So now you can try to fix it,
---
src/gallium/drivers/r600/compute_memory_pool.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 1d0ec85..6d47b1a 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++
---
src/gallium/drivers/r600/compute_memory_pool.c | 54
src/gallium/drivers/r600/compute_memory_pool.h | 58 --
2 files changed, 83 insertions(+), 29 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
From: Thomas Helland thomashellan...@gmail.com
Let's cut the needless A B here.
Gives some effect on a clean shader-db with
some extra shaders from TF2 and portal.
helped: shaders/tf2/2042.shader_test fs16:23 - 21
(-8.70%)
helped: shaders/tf2/2042.shader_test fs8:
On Thu, Jul 10, 2014 at 2:24 PM, thomashellan...@gmail.com wrote:
From: Thomas Helland thomashellan...@gmail.com
Let's cut the needless A B here.
Gives some effect on a clean shader-db with
some extra shaders from TF2 and portal.
Nice. Thanks DX translators. :(
I'll run this on our
I have just tested it and it works with LLVM 3.4.2.
Marek
On Thu, Jul 10, 2014 at 5:11 PM, Tom Stellard t...@stellard.net wrote:
On Tue, Jul 08, 2014 at 01:37:02AM +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This is a follow-up to the commit which adds texture fetches
On Thu, Jul 10, 2014 at 2:24 PM, thomashellan...@gmail.com wrote:
From: Thomas Helland thomashellan...@gmail.com
Let's cut the needless A B here.
Gives some effect on a clean shader-db with
some extra shaders from TF2 and portal.
helped: shaders/tf2/2042.shader_test fs16:
From: Marek Olšák marek.ol...@amd.com
This happens when glGetMultisamplefv (or any other non-draw function) is
called, which doesn't invoke the VBO module to update _DrawArrays and
the pointer is invalid at that point.
However st/mesa still dereferences it to setup vertex buffers == crash.
---
On 07/10/2014 03:24 PM, thomashellan...@gmail.com wrote:
From: Thomas Helland thomashellan...@gmail.com
Let's cut the needless A B here.
Gives some effect on a clean shader-db with
some extra shaders from TF2 and portal.
helped: shaders/tf2/2042.shader_test fs16:23 - 21
On 07/10/2014 05:11 PM, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This happens when glGetMultisamplefv (or any other non-draw function) is
called, which doesn't invoke the VBO module to update _DrawArrays and
the pointer is invalid at that point.
However st/mesa still
On Thu, Jul 10, 2014 at 4:12 PM, Brian Paul bri...@vmware.com wrote:
BTW, looking at these algebraic simplifications in general, where do we
check for operands with side-effects? For example, in the 1^x == 1
optimization, suppose x is a function call which modifies a global. Removing
x would
On Thu, Jul 10, 2014 at 4:12 PM, Brian Paul bri...@vmware.com wrote:
BTW, looking at these algebraic simplifications in general, where do we
check for operands with side-effects? For example, in the 1^x == 1
optimization, suppose x is a function call which modifies a global. Removing
x would
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #3 from Marek Olšák mar...@gmail.com ---
No. If you use the immediate-mode style rendering (glBegin/End), the vertices
are written into a buffer. When the buffer is full, all vertices are drawn and
a new buffer is allocated for the
https://bugs.freedesktop.org/show_bug.cgi?id=81139
--- Comment #4 from Boyan Ding stu_...@126.com ---
(In reply to comment #1)
My guess it that it is a libxcb bug.
Debian packages have the fix (which is
http://cgit.freedesktop.org/xcb/libxcb/commit/
https://bugs.freedesktop.org/show_bug.cgi?id=81139
--- Comment #5 from Boyan Ding stu_...@126.com ---
I think it's not about xcb bug.
I turned on DebugPresent output and that's what I get when running glxgears:
q 1 0x2bf5a30 351258: 0046 - 0042 (crtc (nil))
e 1 ust 5854416007 msc
https://bugs.freedesktop.org/show_bug.cgi?id=81139
--- Comment #6 from Axel Davy veb...@hotmail.fr ---
I tested the program and confirmed I have the same problem with mesa git.
However on this branch https://github.com/axeldavy/mesa/tree/submit4,
I don't get the bug. This is quite strange.
https://bugs.freedesktop.org/show_bug.cgi?id=81139
--- Comment #7 from Axel Davy veb...@hotmail.fr ---
Hum... strangely after testing again, it doesn't work too now with this branch.
Perhaps the bug is from Xserver side.
--
You are receiving this mail because:
You are the assignee for the bug.
gen8_fs_generator uses these to decide whether to set the execution size
to 8 or 16, so we incorrectly made both of these MOVs the full width in
SIMD16 shaders. (It happened to work out on Gen4-7.)
Setting them should also help inform optimization passes what's really
going on, which could help
Both inst-force_uncompressed and inst-force_sechalf mean that the
generated instruction should be uncompressed and have an execution size
of 8. We don't require the visitor to set both flags - setting
inst-force_sechalf by itself is supposed to be enough.
On Gen4-7, guess_execution_size()
https://bugs.freedesktop.org/show_bug.cgi?id=81139
--- Comment #8 from Boyan Ding stu_...@126.com ---
(In reply to comment #7)
Perhaps the bug is from Xserver side.
I guess it may be the case. But where is the problem in xserver -- xwayland or
glamor or else? If it is not in xwayland, I guess
https://bugs.freedesktop.org/show_bug.cgi?id=81139
--- Comment #9 from Axel Davy veb...@hotmail.fr ---
For Xwayland, Present uses the Present fallback implementation.
If never present_fake_queue_vblank is called with a msc too low (already
passed), then perhaps it's going to wait forever. My
11. juli 2014 01:02 skrev Jordan Justen jljus...@gmail.com følgende:
On Thu, Jul 10, 2014 at 2:24 PM, thomashellan...@gmail.com wrote:
From: Thomas Helland thomashellan...@gmail.com
Let's cut the needless A B here.
Gives some effect on a clean shader-db with
some extra shaders from
51 matches
Mail list logo
