On Fri, Aug 09, 2013 at 02:59:07PM +0200, Niels Ole Salscheider wrote:
> ---
This series is:
Reviewed-by: Tom Stellard
Your implementation of SITargetLowering::isFMAFasterThanFMulAndFAdd()
is correct for SI, not sure about Sea Islands, but we can always fix it
later. Feel free to commit these
https://bugs.freedesktop.org/show_bug.cgi?id=67969
Priority: medium
Bug ID: 67969
Keywords: regression
CC: za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] piglit gl-1.0-edgeflag-quads regression
https://bugs.freedesktop.org/show_bug.cgi?id=67968
Priority: medium
Bug ID: 67968
Keywords: regression
CC: za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] piglit polygon-mode regression
Sev
https://bugs.freedesktop.org/show_bug.cgi?id=67967
Priority: medium
Bug ID: 67967
Keywords: regression
CC: za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] piglit clipflat regression
Severit
Currently single sample scaled blits with GL_LINEAR filter falls
back to meta path. Patch removes this limitation in BLORP engine
and implements single sample scaled blit with bilinear filter.
No piglit, gles3 regressions are obeserved with this patch. Piglit
test case patches to verify this implem
https://bugs.freedesktop.org/show_bug.cgi?id=67966
Priority: medium
Bug ID: 67966
Keywords: regression
CC: za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] piglit glean pointSprite regression
https://bugs.freedesktop.org/show_bug.cgi?id=67965
Priority: medium
Bug ID: 67965
Keywords: regression
CC: za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe] piglit point-line-no-cull regression
https://bugs.freedesktop.org/show_bug.cgi?id=67963
Priority: medium
Bug ID: 67963
Keywords: regression
CC: za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe] piglit glean pointAtten regression
Hi Chris
Just a quick note for any Gentoo users - I've added these alternative
sources into the FireBurn overlay
You just need to set the nine use flag and you'll get Chris's versions
Cheers
Mike
On 16 July 2013 19:43, Christoph Bumiller wrote:
> So, about two months ago I had the insane ide
There's no need to use a clip flag for NEGW on these gens, so
no reason we can't just enable 8 planes.
V2: - Bump (and document!) MAX_VERTS in the clip code.
- Fix clip flag masks in the clip unit state and in the shader
prolog
- Move this to the end of the series for less breakage.
---
src/mesa/drivers/dri/i965/brw_clip.c | 3 +-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 40 +-
src/mesa/drivers/dri/i965/brw_vs.c | 14 ++---
src/mesa/drivers/dri/i965/brw_vs.h | 9 --
4 files changed, 11 insertions(+),
This does the same thing as we do for triangle clipping -- select the
appropriate source (either dot(hpos,fixed plane) or a clipdistance
slot).
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_clip_line.c | 66 ++-
1 file changed, 47 insertions(+), 19 del
Nothing in the clipper uses gl_ClipVertex any more, so we don't care
where it is.
V2: Don't bother fishing out the clipvertex offset either.
Signed-off-by: Chris Forbes
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i965/brw_clip_tri.c | 15 ---
1 file changed, 4 insertions(+), 1
V2: Adjust explanation of load_clip_distance()
Signed-off-by: Chris Forbes
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i965/brw_clip_tri.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip_tri.c
b/src/mesa/drivers/dri/i965/b
Soon the dp4 is only going to be used for fixed clip planes.
V2: Remove old inaccurate comment about the behavior of this function;
add a better explanation above.
Signed-off-by: Chris Forbes
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i965/brw_clip_tri.c | 39 ++--
Signed-off-by: Chris Forbes
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i965/brw_clip.h | 3 +++
src/mesa/drivers/dri/i965/brw_clip_tri.c | 9 +
2 files changed, 12 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_clip.h
b/src/mesa/drivers/dri/i965/brw_clip.h
index 2b0
V2: - Use the new VS_OPCODE_UNPACK_FLAGS_SIMD4X2 to correctly split the
flags for the two vertices being processed together.
- Don't apply bogus masking of clip flags. The set of plane enables
aren't included in the shader key, and we wouldn't want the
recompiles anyway.
Sign
Splits the bottom 8 bits of f0.0 for further wrangling
in a SIMD4x2 program. The 4 bits corresponding to the channels in each
program flow are copied to the LSBs of dst.x visible to each flow.
This is useful for working with clipping flags in the VS.
Signed-off-by: Chris Forbes
---
src/mesa/dri
Previously we had disabled interpolation of the clip distances as a
special case, since they were unused.
Signed-off-by: Chris Forbes
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i965/brw_clip_util.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/mesa/dri
We need to produce clip flags for the vertex header on Gen4/5, so
clip plane lowering has to be done before we try to emit the flags/psiz
attribute.
Signed-off-by: Chris Forbes
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i965/brw_vec4.h | 2 +-
src/mesa/drivers/dri/i965/brw_vec4
V2: We don't particularly care where they fall in the VUE map, as long
as they are allocated somewhere, and occupy two contiguous slots. Don't
fiddle with the SF layout at all -- there's no need.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_vs.c | 5 +
1 file changed, 5 inse
This series adds support for GLSL-1.30 clip distances on Gen4/5, and
extends max clip planes to match the 1.30 requirement on Cantiga and later.
Passes 2000/2004 glsl-1.30 piglits on Ironlake. The missing 4 tests here are
bugs in handling unusual `switch` control flow, and affect all gens.
Passes
From: Ian Romanick
This is required by the spec, and it's a bit tricky because the default
precision is scoped. As a result, I'm slightly abusing the symbol
table.
Fixes piglit no-default-float-precision.frag tests and the piglit
default-precision-nested-scope-0[1234].frag tests that are curren
From: Ian Romanick
We never noticed this before because we previously didn't enfoce GLSL ES
fragement shader requirements that precision be defined. There may also
have been some interaction here with the addition of
GL_ARB_shading_language_420pack, but it doesn't appear to me that it
added any
From: Ian Romanick
This is used by the next patch.
Signed-off-by: Ian Romanick
Cc: "9.2"
---
src/glsl/ast_to_hir.cpp | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 9d69e49..091e0e6 100644
--- a/src/glsl/ast_
From: Ian Romanick
Once the compiler proplerly checks for default precision qualifiers,
these shaders will cease to compile.
Signed-off-by: Ian Romanick
Cc: "9.2"
---
src/glsl/builtins/profiles/100es.frag| 2 ++
src/glsl/builtins/profiles/300es.frag| 1
From: Ian Romanick
Signed-off-by: Ian Romanick
Cc: "9.2"
---
src/mesa/drivers/common/meta.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 69b06ed..609ef80 100644
--- a/src/mesa/drivers/common/meta.c
From: Ian Romanick
Previously we would emit a warning for empty declarations like
float;
We would also emit the same warning for things like
highp float;
However, this second case is most likely the application trying to set the
default precision. We should instead generate an error.
Fixes
From: Ian Romanick
Send it straight to the Department of Redundancy Department.
Signed-off-by: Ian Romanick
---
src/glsl/ast_to_hir.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 9d2..9d69e49 100644
--- a/src/
From: Ian Romanick
GLSL ES does not allow unsized arrays, and GLSL ES 1.00 does not allow
array initializers. However, GLSL ES 3.00 allows array initializers,
and the initializer can explicitly size the array. The specification
even includes some examples of this:
float x[] = float[2] (1.0
From: Ian Romanick
Fixes piglit array-function-return-unsized.vert.
Signed-off-by: Ian Romanick
Cc: "9.2"
---
src/glsl/ast_to_hir.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 325cb06..49804b7 100644
--- a/src/gls
This series fixes a bunch of little things that we were doing
incorrectly in the compiler front end. These were mostly related to the
handling of unsized arrays and precision qualifiers.
With these changes, all of the tests in the piglit groups glslparsertest
(+1), glsl-es-1.00 (+4, counting new
From: Ian Romanick
Fixes piglit glx-query-drawable-GLXBadDrawable.
Signed-off-by: Ian Romanick
Cc: "9.2"
---
src/glx/glx_pbuffer.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index f11305a..183fbaa 100644
--
The surface allocator understands the scanout flag just fine.
This seems to improve performance for Ubuntu Unity on top of st/xorg
and it fixes the cursor.
---
src/gallium/drivers/radeonsi/r600_texture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeo
Any pixmap can potentially end up as a scanout buffer, right?
This fixes a whole-screen corruption with radeonsi, which needs a different
texture layout for scanout textures.
---
src/gallium/state_trackers/xorg/xorg_exa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gal
Am 09.08.2013 21:31, schrieb Roland Scheidegger:
> Am 09.08.2013 21:00, schrieb Christoph Bumiller:
>> On 09.08.2013 20:42, Roland Scheidegger wrote:
>>> This is a proposal for new comparison instructions, as the old ones
>>> don't really fit modern (graphic or opencl I guess for that matter)
>>> l
Le vendredi 9 août 2013 18:50:20 Michel Dänzer a écrit :
> From: Michel Dänzer
>
> Exporting position 2/3 (clip distances) but not position 1 (point size)
> causes geometry corruption for some reason.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66974
>
> Cc: mesa-sta...@lists.fre
On Thu, Aug 8, 2013 at 5:02 PM, Tom Stellard wrote:
> On Thu, Aug 08, 2013 at 01:51:39PM +0200, Marek Olšák wrote:
>> Interleaving might not be a good idea, but they could be in the same
>> array, like this:
>>
>> 0..15: textures
>> 16..31: FMASK textures
>>
>> I'll test LLVM master, but we should
On 08/09/2013 05:59 AM, Niels Ole Salscheider wrote:
+bool SITargetLowering::isFMAFasterThanFMulAndFAdd(EVT VT) const {
+ VT = VT.getScalarType();
+
+ if (!VT.isSimple())
+return false;
+
+ switch (VT.getSimpleVT().SimpleTy) {
+ case MVT::f32:
+return false; /* There is V_MAD_F32 for
On Fri, Aug 9, 2013 at 8:28 PM, Ian Romanick wrote:
> On 08/09/2013 04:22 AM, Martin Andersson wrote:
>>
>> I think I have found an issue in the piglit test.
>>
>> Marek, could you take a look at the attached patch and see if it looks
>> correct. If so I will send it to the piglit list.
>
>
> Wow.
On Fri, Aug 9, 2013 at 6:00 PM, Michel Dänzer wrote:
> On Fre, 2013-08-09 at 08:30 -0700, Tom Stellard wrote:
>> On Fri, Aug 09, 2013 at 07:35:02AM -0700, Tom Stellard wrote:
>> > On Fri, Aug 09, 2013 at 07:54:11AM +0200, Michel Dänzer wrote:
>> > > On Don, 2013-08-08 at 11:32 -0700, Tom Stellard
Tested by examining generated TGSI shaders from piglit/glsl-routing.
Cc: mesa-sta...@lists.freedesktop.org
---
src/glsl/ir_optimization.h | 2 +-
src/glsl/linker.cpp| 6 +++---
src/glsl/opt_dead_builtin_varyings.cpp | 27 +++
3 files chang
Most importantly, this hides all LLVM symbols. They shouldn't clash
with a different LLVM version used by apps (at least in theory).
$ nm -g --defined-only radeonsi_dri.so
01148f30 D __driDriverExtensions
We could do something similar for the other targets.
v2: add the EXTRA_ prefix so as not to
On 08/09/2013 01:59 PM, Brian Paul wrote:
>
> That's probably not it, given the above. Can you try setting a
> breakpoint on pstip_destroy() and see if that's getting called before
> the segfault? If so, things are getting freed in the wrong order.
>
No, it is not called before the segfault.
Am 09.08.2013 21:00, schrieb Christoph Bumiller:
> On 09.08.2013 20:42, Roland Scheidegger wrote:
>> This is a proposal for new comparison instructions, as the old ones
>> don't really fit modern (graphic or opencl I guess for that matter)
>> languages well.
>> If you've got objections, think the n
Tying this to PIPE_SHADER_CAP_INTEGERS sounds good to me.
And yeah, st_glsl_to_tgsi.cpp will need some work one of these days...
-Brian
On 08/09/2013 01:17 PM, Roland Scheidegger wrote:
I was thinking it should just be part of the native_integer support
(glsl 1.30 basically) so it must be supp
I was thinking it should just be part of the native_integer support
(glsl 1.30 basically) so it must be supported if you support that, and
it is always preferred in that case.
Though I won't implement it for other drivers (just llvmpipe/softpipe),
and just hope everybody will implement it so glsl c
- Original Message -
> This is a proposal for new comparison instructions, as the old ones
> don't really fit modern (graphic or opencl I guess for that matter)
> languages well.
> If you've got objections, think the naming is crazy or whatnot I'm open
> for suggestions :-). I would think t
Looks good to me.
Will you be a adding a new PIPE_SHADER_CAP_ flag so the driver can tell
the state tracker which kind of comparison instructions it wants?
-Brian
On 08/09/2013 12:42 PM, Roland Scheidegger wrote:
This is a proposal for new comparison instructions, as the old ones
don't reall
On 09.08.2013 20:42, Roland Scheidegger wrote:
> This is a proposal for new comparison instructions, as the old ones
> don't really fit modern (graphic or opencl I guess for that matter)
> languages well.
> If you've got objections, think the naming is crazy or whatnot I'm open
> for suggestions :-
Most importantly, this hides all LLVM symbols. They shouldn't clash
with a different LLVM version used by apps (at least in theory).
$ nm -g --defined-only radeonsi_dri.so
01148f30 D __driDriverExtensions
We could do something similar for the other targets.
---
src/gallium/targets/dri-freedreno/
This is a proposal for new comparison instructions, as the old ones
don't really fit modern (graphic or opencl I guess for that matter)
languages well.
If you've got objections, think the naming is crazy or whatnot I'm open
for suggestions :-). I would think this is not just a much better fit
for d
From: Roland Scheidegger
The old float comparison opcodes always return floats 0.0 and 1.0 (clarified
in docs these were really floats, was always the case) for legacy graphics.
But everybody else (opengl,opencl,d3d10) just has to work around their
return results (converting the returned float ba
https://bugs.freedesktop.org/show_bug.cgi?id=41700
Bug 41700 depends on bug 50754, which changed state.
Bug 50754 Summary: Building 32 bit mesa on 64 bit OS fails since change for
automake
https://bugs.freedesktop.org/show_bug.cgi?id=50754
What|Removed |Added
https://bugs.freedesktop.org/show_bug.cgi?id=45466
Bug 45466 depends on bug 50754, which changed state.
Bug 50754 Summary: Building 32 bit mesa on 64 bit OS fails since change for
automake
https://bugs.freedesktop.org/show_bug.cgi?id=50754
What|Removed |Added
https://bugs.freedesktop.org/show_bug.cgi?id=50754
Alexandre Demers changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
On 08/09/2013 04:22 AM, Martin Andersson wrote:
I think I have found an issue in the piglit test.
Marek, could you take a look at the attached patch and see if it looks
correct. If so I will send it to the piglit list.
Wow. That test is confusing. It would be a lot more obvious (and less
er
On 08/09/2013 12:33 AM, Eric Anholt wrote:
Mark Mueller writes:
On Thu, Aug 8, 2013 at 2:19 PM, Eric Anholt wrote:
Mark Mueller writes:
Signed-off-by: Mark Mueller
---
src/mesa/drivers/dri/i965/brw_draw.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --gi
On Fri, Aug 9, 2013 at 3:48 PM, Christian König wrote:
> Am 09.08.2013 15:29, schrieb Marek Olšák:
>>
>> On Fri, Aug 9, 2013 at 10:34 AM, Christian König
>> wrote:
>>>
>>> Am 08.08.2013 21:38, schrieb Alex Deucher:
>>>
On Thu, Aug 8, 2013 at 1:34 PM, Marek Olšák wrote:
>
> On Thu, A
On 08/09/2013 11:53 AM, Kevin H. Hobbs wrote:
On 08/09/2013 09:16 AM, Brian Paul wrote:
On 08/07/2013 12:17 PM, Kevin H. Hobbs wrote:
#0 pstip_bind_sampler_states (pipe=, num=0, sampler=0x0)
at draw/draw_pipe_pstipple.c:713
Hmm, I'd expect memcpy() of length zero to be fine even if src/dst
On 08/09/2013 09:16 AM, Brian Paul wrote:
> On 08/07/2013 12:17 PM, Kevin H. Hobbs wrote:
>>
>> #0 pstip_bind_sampler_states (pipe=, num=0, sampler=0x0)
>> at draw/draw_pipe_pstipple.c:713
>>
> Hmm, I'd expect memcpy() of length zero to be fine even if src/dst were
> null.
>
memcpy is fine, t
Hi
I seem to have a missing symbol wayland_drm_buffer_get in libgbm.so.1
I'm pretty sure its related
Regards
Mike
On 18 Jul 2013 13:15, "Ander Conselvan de Oliveira" <
ander.conselvan.de.olive...@intel.com> wrote:
> Since Wayland 1.2, struct wl_buffer and a few functions are deprecated.
>
> Re
In commit 8fc41df (glsl: Modify ir_set_program_inouts to handle
geometry shaders), when attempting to pattern match the "foo" part of
expressions such as:
foo[i][j]
foo[i]
I incorrectly called as_dereference_variable() on the subexpression
foo[i] instead of foo. As a result, the pattern ne
According to section 15.2.3 (Shader Outputs) of the GL 4.4 spec (and
similar text in older GL specs), failing to write to gl_FragData[n]
results in undefined data being sent to color buffer attachment n:
"Writing to gl_FragColor specifies the fragment color (color
number zero) that will be
From: Michel Dänzer
Exporting position 2/3 (clip distances) but not position 1 (point size)
causes geometry corruption for some reason.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66974
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeo
From: Michel Dänzer
E.g. the Source engine seems to always write to gl_ClipVertex, but normally
doesn't enable any GL_CLIP_DISTANCEn states. This change removes some
irrelevant parts from the generated vertex shader code in such cases.
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeo
On Fre, 2013-08-09 at 08:30 -0700, Tom Stellard wrote:
> On Fri, Aug 09, 2013 at 07:35:02AM -0700, Tom Stellard wrote:
> > On Fri, Aug 09, 2013 at 07:54:11AM +0200, Michel Dänzer wrote:
> > > On Don, 2013-08-08 at 11:32 -0700, Tom Stellard wrote:
> > > > On Thu, Aug 08, 2013 at 05:36:09PM +0200, Mi
On Fri, Aug 09, 2013 at 07:35:02AM -0700, Tom Stellard wrote:
> On Fri, Aug 09, 2013 at 07:54:11AM +0200, Michel Dänzer wrote:
> > On Don, 2013-08-08 at 11:32 -0700, Tom Stellard wrote:
> > > On Thu, Aug 08, 2013 at 05:36:09PM +0200, Michel Dänzer wrote:
> > > > On Don, 2013-08-08 at 08:00 -0700, T
On Fri, Aug 09, 2013 at 07:54:11AM +0200, Michel Dänzer wrote:
> On Don, 2013-08-08 at 11:32 -0700, Tom Stellard wrote:
> > On Thu, Aug 08, 2013 at 05:36:09PM +0200, Michel Dänzer wrote:
> > > On Don, 2013-08-08 at 08:00 -0700, Tom Stellard wrote:
> > > > On Thu, Aug 08, 2013 at 02:20:54AM +0200, M
Am 09.08.2013 15:29, schrieb Marek Olšák:
On Fri, Aug 9, 2013 at 10:34 AM, Christian König
wrote:
Am 08.08.2013 21:38, schrieb Alex Deucher:
On Thu, Aug 8, 2013 at 1:34 PM, Marek Olšák wrote:
On Thu, Aug 8, 2013 at 6:57 PM, Christian König
wrote:
Am 08.08.2013 16:33, schrieb Marek Olšák:
If we enable glx-tls in Mesa by default, we should also do so in Glamor.
Marek
On Fri, Aug 9, 2013 at 9:26 AM, Vedran Rodic wrote:
> Hi,
>
> I've been burned with the issue of GLX TLS not being enabled by
> default in Mesa (Dota 2 seems to rely on it).
>
> What's the rationale of not enabling it
On Fri, Aug 9, 2013 at 10:34 AM, Christian König
wrote:
> Am 08.08.2013 21:38, schrieb Alex Deucher:
>
>> On Thu, Aug 8, 2013 at 1:34 PM, Marek Olšák wrote:
>>>
>>> On Thu, Aug 8, 2013 at 6:57 PM, Christian König
>>> wrote:
Am 08.08.2013 16:33, schrieb Marek Olšák:
>
> On Thu,
If I understand the code correctly, value[3] should be 1.
If it were 0, the bias would be 1, therefore adding 1 and clamping the
alpha (because of the RGBA8 colorbuffer) would always return 1 no
matter what the texture fetch returned.
Anyway, if the texture fetch returned 0x, the test wou
On 08/07/2013 12:17 PM, Kevin H. Hobbs wrote:
One of the VTK tests (vtkFiltersHybridPython-largeImageOffset) makes
OSMesa segfault.
This is the top of the gdb backtrace :
#0 pstip_bind_sampler_states (pipe=, num=0, sampler=0x0)
at draw/draw_pipe_pstipple.c:713
#1 0x7fffdf7580fc in cso_rel
---
lib/Target/R600/SIISelLowering.cpp | 18 ++
lib/Target/R600/SIISelLowering.h | 1 +
test/CodeGen/R600/fmuladd.ll | 31 +++
3 Dateien geändert, 50 Zeilen hinzugefügt(+)
create mode 100644 test/CodeGen/R600/fmuladd.ll
diff --git a/lib/Target
---
lib/Target/R600/SIInstructions.td | 8 ++--
test/CodeGen/R600/fma.ll | 31 +++
2 Dateien geändert, 37 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
create mode 100644 test/CodeGen/R600/fma.ll
diff --git a/lib/Target/R600/SIInstructions.td
b/lib/Target
I think I have found an issue in the piglit test.
Marek, could you take a look at the attached patch and see if it looks
correct. If so I will send it to the piglit list.
//Martin
On Tue, Aug 6, 2013 at 11:20 PM, Marek Olšák wrote:
> Sorry, I have no idea. You can try to remove support for RGBX
Signed-off-by: Niels Ole Salscheider
---
src/gallium/state_trackers/clover/api/event.cpp | 26 -
src/gallium/state_trackers/clover/core/event.cpp | 116 ---
src/gallium/state_trackers/clover/core/event.hpp | 18 +++-
3 Dateien geändert, 142 Zeilen hinzugefügt(+), 18 Zei
This patch adds support for:
PIPE_COMPUTE_CAP_MAX_INPUT_SIZE
PIPE_COMPUTE_CAP_MAX_LOCAL_SIZE
Return the values reported by the closed source driver for now.
Signed-off-by: Niels Ole Salscheider
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c | 15 ++-
1 Datei geändert, 14 Zeilen hi
The command is submitted once the event has been triggered, but it might not
have completed yet. Therefore, we have to add it to deps in order to wait on it.
Signed-off-by: Niels Ole Salscheider
---
src/gallium/state_trackers/clover/core/event.cpp | 2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+)
Signed-off-by: Niels Ole Salscheider
---
src/gallium/drivers/radeonsi/r600.h| 1 +
src/gallium/drivers/radeonsi/r600_hw_context.c | 31 ++
src/gallium/drivers/radeonsi/r600_query.c | 14 +++-
src/gallium/drivers/radeonsi/radeonsi_pipe.c | 2 +-
Signed-off-by: Niels Ole Salscheider
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c | 9 +
1 Datei geändert, 9 Zeilen hinzugefügt(+)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
index 3ba8232..7ae5598 100644
--- a/src/gallium
This makes sure that there are not too many concurrent fences.
Also, simplify status handling by keeping track of the current state.
Signed-off-by: Niels Ole Salscheider
---
src/gallium/state_trackers/clover/core/event.cpp | 29 +++-
src/gallium/state_trackers/clover/core/ev
>
> I've been burned with the issue of GLX TLS not being enabled by
> default in Mesa (Dota 2 seems to rely on it).
>
> What's the rationale of not enabling it by default?
>
not sure we have really any major reason for not doing so, it really
depends on what your distro does with its Xorg and glam
Am 08.08.2013 21:38, schrieb Alex Deucher:
On Thu, Aug 8, 2013 at 1:34 PM, Marek Olšák wrote:
On Thu, Aug 8, 2013 at 6:57 PM, Christian König wrote:
Am 08.08.2013 16:33, schrieb Marek Olšák:
On Thu, Aug 8, 2013 at 3:09 PM, Christian König
wrote:
Am 08.08.2013 14:38, schrieb Marek Olšák:
Mark Mueller writes:
> On Thu, Aug 8, 2013 at 2:19 PM, Eric Anholt wrote:
>
>> Mark Mueller writes:
>> > Signed-off-by: Mark Mueller
>> > ---
>> > src/mesa/drivers/dri/i965/brw_draw.c | 16 ++--
>> > 1 file changed, 6 insertions(+), 10 deletions(-)
>> >
>> > diff --git a/src/mesa/
Hi,
I've been burned with the issue of GLX TLS not being enabled by
default in Mesa (Dota 2 seems to rely on it).
What's the rationale of not enabling it by default?
Thanks,
Vedran Rodic
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://
Am 09.08.2013 03:15, schrieb Alex Deucher:
Cayman and trinity systems still seem to suffer from
stability problems with GPUVM. This also fixes compute
on these asics. It can still be enabled for testing
by setting env var RADEON_VA=true.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=6595
On Don, 2013-08-08 at 11:32 -0700, Tom Stellard wrote:
> On Thu, Aug 08, 2013 at 05:36:09PM +0200, Michel Dänzer wrote:
> > On Don, 2013-08-08 at 08:00 -0700, Tom Stellard wrote:
> > > On Thu, Aug 08, 2013 at 02:20:54AM +0200, Marek Olšák wrote:
> > > >
> > > > diff --git a/src/gallium/drivers/rad
89 matches
Mail list logo
