11. juli 2014 01:02 skrev "Jordan Justen" følgende:
>
> On Thu, Jul 10, 2014 at 2:24 PM, wrote:
> > From: Thomas Helland
> >
> > 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.shade
https://bugs.freedesktop.org/show_bug.cgi?id=81139
--- Comment #9 from Axel Davy ---
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 guess is that for an
https://bugs.freedesktop.org/show_bug.cgi?id=81139
--- Comment #8 from Boyan Ding ---
(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 there is possibl
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() demo
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 a
https://bugs.freedesktop.org/show_bug.cgi?id=81139
--- Comment #7 from Axel Davy ---
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.
_
https://bugs.freedesktop.org/show_bug.cgi?id=81139
--- Comment #6 from Axel Davy ---
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.
Could test it and say
https://bugs.freedesktop.org/show_bug.cgi?id=81139
--- Comment #5 from Boyan Ding ---
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 351258
c 0x2b
https://bugs.freedesktop.org/show_bug.cgi?id=81139
--- Comment #4 from Boyan Ding ---
(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/
> ?id=3b72a2c9d1d656c74c691a45689e1d637f669e3a)
I tried
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #3 from Marek Olšák ---
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 following vertex da
On Thu, Jul 10, 2014 at 4:12 PM, Brian Paul 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 be invalid,
On Thu, Jul 10, 2014 at 4:12 PM, Brian Paul 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 be invalid,
On 07/10/2014 05:11 PM, Marek Olšák wrote:
From: Marek Olšák
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 verte
On 07/10/2014 03:24 PM, thomashellan...@gmail.com wrote:
From: Thomas Helland
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/
From: Marek Olšák
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.
---
src/mesa/main/array
On Thu, Jul 10, 2014 at 2:24 PM, wrote:
> From: Thomas Helland
>
> 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/2
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 wrote:
> On Tue, Jul 08, 2014 at 01:37:02AM +0200, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> This is a follow-up to the commit which adds texture fetches with offsets.
>
> Will this still
On Thu, Jul 10, 2014 at 2:24 PM, wrote:
> From: Thomas Helland
>
> 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 collection of shaders too. I'll reply with some st
From: Thomas Helland
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: 23 -> 21
(-8.70%)
hel
---
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
b/src/gallium/drivers/r
---
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
+++ b/src/
https://bugs.freedesktop.org/show_bug.cgi?id=78716
--- Comment #9 from oscar garcia ---
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, right?
El miércole
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #2 from Benjamin Bellec ---
Is that a regression ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http:/
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 a/src/mes
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 fl
---
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
b/src/glsl
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 M
On Thu, Jul 10, 2014 at 1:13 PM, Brian Paul wrote:
> On 07/10/2014 09:50 AM, Ilia Mirkin wrote:
>>
>> On Thu, Jul 10, 2014 at 11:46 AM, Ilia Mirkin
>> wrote:
>>>
>>> On Thu, Jul 10, 2014 at 11:43 AM, Brian Paul wrote:
---
src/gallium/docs/source/tgsi.rst |2 ++
1 file
On 07/10/2014 09:50 AM, Ilia Mirkin wrote:
On Thu, Jul 10, 2014 at 11:46 AM, Ilia Mirkin wrote:
On Thu, Jul 10, 2014 at 11:43 AM, Brian Paul 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/d
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
https://bugs.freedesktop.org/show_bug.cgi?id=81174
Benjamin Bellec changed:
What|Removed |Added
CC||b.bel...@gmail.com
--
You are receivi
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 ma
On Thu, Jul 10, 2014 at 11:46 AM, Ilia Mirkin wrote:
> On Thu, Jul 10, 2014 at 11:43 AM, Brian Paul 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
On Thu, Jul 10, 2014 at 11:43 AM, Brian Paul 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
> --- a/src/gallium/docs/source/tgsi.rs
---
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 does
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 queri
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 mak
https://bugs.freedesktop.org/show_bug.cgi?id=80183
--- Comment #4 from Florian Link ---
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.
___
mesa-dev mailing list
m
On Tue, Jul 08, 2014 at 01:37:03AM +0200, Marek Olšák wrote:
> From: Marek Olšák
Reviewed-by: Tom Stellard
>
> ---
> src/gallium/drivers/radeonsi/si_blit.c| 2 +-
> src/gallium/drivers/radeonsi/si_descriptors.c | 12 +-
> src/gallium/drivers/radeonsi/si_pipe.c| 6 ++-
On Tue, Jul 08, 2014 at 01:37:02AM +0200, Marek Olšák wrote:
> From: Marek Olšák
>
> 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 -
> 1
On Tue, Jul 08, 2014 at 03:37:02AM +0200, Marek Olšák wrote:
> From: Marek Olšák
>
> 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 Mesa release sup
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
wrote:
> On Wed, 2014-07-02 at 22:16 +1000, Tim
https://bugs.freedesktop.org/show_bug.cgi?id=80183
--- Comment #3 from Brian Paul ---
(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.
>
> Since the
https://bugs.freedesktop.org/show_bug.cgi?id=80183
--- Comment #2 from Florian Link ---
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 on ATI/NVidia and on
On Mon, Jul 07, 2014 at 12:27:29PM +0100, Neil Roberts wrote:
> "Pohjolainen, Topi" 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 cleartexsubimage_using_fbo()
>
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #1 from Florian Link ---
Created attachment 102537
--> https://bugs.freedesktop.org/attachment.cgi?id=102537&action=edit
A Qt example that demonstrates the problem
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freedesktop.org/show_bug.cgi?id=81174
Ilia Mirkin changed:
What|Removed |Added
Attachment #102536|text/plain |image/png
mime type|
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=81162
Priority: medium
Bug ID: 81162
Assignee: mesa-dev@lists.freedesktop.org
Summary: Multicore Rendering issue on Intel Ironlake Mobile
chipsets
Severity: normal
Classificati
Hello Giovanni,
On Thu, 3 Jul 2014 11:14:48 +0200
Giovanni Campagna wrote:
> 2014-07-03 10:48 GMT+02:00 Boris BREZILLON
> :
> > Hello Giovanni,
> >
> > I have recently been working on a DRM/KMS driver which does not support
> > OpenGL rendering (it only provides plane composition functionalitie
50 matches
Mail list logo
