It should be unsigned, not enum pipe_flush_flags.
Fixed a build error:
src/gallium/state_trackers/egl/android/native_android.cpp:426:29: error:
invalid conversion from 'int' to 'pipe_flush_flags' [-fpermissive]
Signed-off-by: Chia-I Wu
---
src/gallium/include/pipe/p_context.h |2 +-
1
- Original Message -
> Currently, there's no way to get the high bits of a 32x32
> signed/unsigned integer multiplication with tgsi.
> However, all of d3d10, OpenGL, and OpenCL support that, so we need it as
> well.
> There's essentially two ways how it could be done:
> - a 2-destination
On Wed, May 1, 2013 at 1:23 PM, Marek Olšák wrote:
> This is a funny subject. Originally, we only used SURFACE_SYNC on
> Evergreen, which is what the hw guys recommend using, but then Jerome
> came and rewrote it with no reasonable argument to back it up (what he
> was trying to fix by his cache-f
> > k, I'll just push that last patch then. If someone won't like it or we'll
> > decide to do it in some other way we can always redo it later. For now
> > this will be enough to fix the umad handling.
> >
>
> I don't like this, sorry for being slow :-)
>
> Mainly because I don't think any hw ha
https://bugs.freedesktop.org/show_bug.cgi?id=64172
--- Comment #2 from Zack Rusin ---
Actually I was wrong, gallium lies about the naming of the buffer_size
variable, it's actually available_space. Patch sent for a review.
--
You are receiving this mail because:
You are the assignee for the bug
gallium lies. buffer_size is not actually buffer_size but available
size, which is 'buffer_size - buffer_offset' so by adding buffer
offset we'd incorrectly compute overflow.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_pt_so_emit.c |3 +--
1 file changed, 1 insertion(+), 2
Am 03.05.2013 03:07, schrieb Dave Airlie:
>> Sorry to hear the hw doesn't support it, but this is supported by d3d10
>> so it's quite likely some hw indeed supports it. There's always some
>> things some hw can't do natively.
>
> Well I was hoping before adding new things for sw driver to gallium
https://bugs.freedesktop.org/show_bug.cgi?id=64172
Zack Rusin changed:
What|Removed |Added
Keywords|regression |
--- Comment #1 from Zack Rusin ---
Unfort
https://bugs.freedesktop.org/show_bug.cgi?id=64172
Priority: medium
Bug ID: 64172
Keywords: regression
CC: za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: piglit ext_transform_feedback-change-size offset-grow
https://bugs.freedesktop.org/show_bug.cgi?id=64170
Priority: medium
Bug ID: 64170
Keywords: regression
CC: srol...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe] piglit fbo-cubemap regression
Se
> Sorry to hear the hw doesn't support it, but this is supported by d3d10
> so it's quite likely some hw indeed supports it. There's always some
> things some hw can't do natively.
Well I was hoping before adding new things for sw driver to gallium we
should confirm if it
makes sense for hw.
> I'
Am 03.05.2013 00:29, schrieb Dave Airlie:
> On Fri, May 3, 2013 at 6:04 AM, Zack Rusin wrote:
>>> Well in contrast to the IF/UIF they'd be really redundant unless I'm
>>> missing something so just for supporting negation on inputs or not this
>>> looks like not really worth it (and as said there a
On 05/02/2013 01:58 PM, Eric Anholt wrote:
Improves glb2.7 performance at a misaligned size by 2.3% +/- 0.7% (n=11).
The workaround was to avoid bad primitive/surface sizes, but that's worked
around as of a14dc4f92cdad6177d83f051a088a66e31a973bc. (One might note
that pre-gen7 we don't know that
Currently, there's no way to get the high bits of a 32x32
signed/unsigned integer multiplication with tgsi.
However, all of d3d10, OpenGL, and OpenCL support that, so we need it as
well.
There's essentially two ways how it could be done:
- a 2-destination instruction returning both high and low bit
From: Roland Scheidegger
A lot of them were missing. Others were moved from the Compute ISA
to a new Integer ISA section as that seemed more appropriate.
---
src/gallium/docs/source/tgsi.rst | 362 ++
1 file changed, 289 insertions(+), 73 deletions(-)
diff -
On Fri, May 3, 2013 at 6:04 AM, Zack Rusin wrote:
>> Well in contrast to the IF/UIF they'd be really redundant unless I'm
>> missing something so just for supporting negation on inputs or not this
>> looks like not really worth it (and as said there are also other signed
>> instructions where supp
From: Tom Stellard
This leads to crashes when multiple threads try to compile compute
shaders in the same time.
Fixes a crash in bfgminer when using more than one thread.
---
src/gallium/drivers/radeon/radeon_llvm_util.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/s
---
src/mesa/vbo/vbo_save.h |8
src/mesa/vbo/vbo_save_api.c | 25 -
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index c1108ca..aa075bb 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mes
---
src/mesa/main/api_arrayelt.c | 100 +++---
1 files changed, 65 insertions(+), 35 deletions(-)
diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index c34f9f7..bd55f8e 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_
As we do for the other commands which can appear between glBegin/End.
---
src/mesa/vbo/vbo_noop.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/mesa/vbo/vbo_noop.c b/src/mesa/vbo/vbo_noop.c
index 8ba4959..f869845 100644
--- a/src/mesa/vbo/vbo_noop.c
+++ b/src
---
src/mesa/main/dd.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index c5531a4..adace3b 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -696,13 +696,13 @@ struct dd_function_table {
#define FLUSH_UPDATE_CURREN
---
src/mesa/main/dd.h |3 ++-
src/mesa/vbo/vbo_save_api.c |8
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index bc93026..c5531a4 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -703,8 +703,9 @@ struct
---
src/mesa/vbo/vbo_save_api.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index 9ce3c6e..aa57ee7 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -928,8 +928,10 @@ _sav
A surprising number of apps and benchmarks have poor code like this:
glBegin(GL_LINE_STRIP);
glVertex(v1);
glVertex(v2);
glEnd();
// Possibly some no-op state changes here
glBegin(GL_LINE_STRIP);
glVertex(v3);
glVertex(v4);
glEnd();
// repeat many, many times.
The above sequence can be converted
To be used by following commit.
---
src/mesa/vbo/vbo.h | 10 +
src/mesa/vbo/vbo_exec.c | 94 +++
2 files changed, 104 insertions(+), 0 deletions(-)
diff --git a/src/mesa/vbo/vbo.h b/src/mesa/vbo/vbo.h
index 9f800d8..08c67d6 100644
--- a/src
On Tue, Apr 30, 2013 at 9:15 AM, Eric Anholt wrote:
> This will free instruction scheduling to make better choices. No
> statistically significant performance difference on GLB2.7 (n=93).
> ---
Series is:
Reviewed-by: Matt Turner
___
mesa-dev mailing
Texture operations have very long (hundreds of cycles) latencies. If a
texture operation is ready to be scheduled, prefer it over other types
of instructions.
Typically this will mean the other instructions execute to completion
during the time it takes the texturing operation to return results, s
On 05/02/2013 06:34 PM, Lauri Kasanen wrote:
On Thu, 02 May 2013 00:45:13 +0400
Vadim Girlin wrote:
On 05/01/2013 11:36 PM, Lauri Kasanen wrote:
Now that it built, I could test your optimizations in my own apps.
These are on current master 8eef6ad, on a RV710 (HD 4350 pci-e).
In one of my pr
In ureg src registers could have an indirect register that was
either a temp or an addr register, while dst registers allowed
only addr. That made moving between them a little difficult so
make them behave the same way and allow temp's and addr registers
as indirect files for both (tgsi supports it
Just a reminder to all students and mentors planning to work on an
X.Org GSoC project this year, the deadline for applications is
tomorrow (May 3rd, 19:00 UTC). If you are a student planning to
apply, please submit your application by the deadline. If you are
planning to mentor a project and have
Improves glb2.7 performance at a misaligned size by 2.3% +/- 0.7% (n=11).
The workaround was to avoid bad primitive/surface sizes, but that's worked
around as of a14dc4f92cdad6177d83f051a088a66e31a973bc. (One might note
that pre-gen7 we don't know that the right half of an 8x4 at the right
edge is
The Haswell Bspec says "A SIMD16 instruction is not allowed." (but
16-wide BFI1 works for me so far). Since GLSL's bitfieldInsert()
function takes int parameters BFI1 produces the same results in all
channels, so there's never any reason to emit a 16-wide BFI1.
---
src/mesa/drivers/dri/i965/brw_fs
v2: Only lower bitfieldInsert to BFM+BFI (and don't lower
bitfieldExtract at all) since three-source instructions are now
usable in the vertex shader.
v3: Lower bitfield_insert in the same pass with everything else, since
it doesn't produce any instructions to be lowered (the other two
Don't bother scalarizing ir_binop_bfm, since its results are
identical for all channels.
v2: Subtract result of FBH from 31 (unless an error) to convert
MSB counts to LSB counts.
v3: Use op0->clone() in ir_triop_bfi to prevent (var_ref
channel_expressions) from appearing multiple times in
Also update asserts to allow BFE and BFI2, which take (unsigned)
doubleword arguments.
v2: Allow BRW_REGISTER_TYPE_UD for src1 and src2 as well.
Assert that src2.type (instead of src0.type) matches dest.type since
it's the primary argument and src0 and src1 might correctly have
differe
v2: Order bits from LSB end (31 - count) for ir_unop_find_msb.
v3: Add ir_triop_bitfield_extract as an exception to the op[0]->type ==
op[1]->type assertion in ir_constant_expression.cpp.
Reviewed-by: Chris Forbes [v2]
---
src/glsl/ir_constant_expression.cpp | 126 +++
On 04/30/2013 09:15 AM, Eric Anholt wrote:
This will free instruction scheduling to make better choices. No
statistically significant performance difference on GLB2.7 (n=93).
---
src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp |4
1 file changed, 4 insertions(+)
diff --git a/src
On Thu, May 2, 2013 at 11:52 AM, Lauri Kasanen wrote:
> On Thu, 2 May 2013 07:58:30 -0700
> Matt Turner wrote:
>
>> > -TEST_LIBS = -lXvMCW -lXvMC -lXv -lX11
>> > +TEST_LIBS = $(XVMC_LIBS) -lXvMCW -lXvMC -lXv -lX11
>>
>> Doesn't XVMC_LIBS include all of those other libraries? I think
>> they're no
On 05/02/2013 01:08 PM, Paul Berry wrote:
On 2 May 2013 12:54, Chris Wilson mailto:ch...@chris-wilson.co.uk>> wrote:
On Thu, May 02, 2013 at 09:07:08AM -0700, Eric Anholt wrote:
> Chris Wilson mailto:ch...@chris-wilson.co.uk>> writes:
>
> > On Thu, May 02, 2013 at 07:26:06AM -
- Original Message -
> Hi list,
>
> This patch series attemps to clean up u_prim.h, with an exception that a new
> function to get the tessellated (as opposed to decomposed) primitive count is
> added by the last patch. I need that function for ilo to update
> PIPE_QUERY_PRIMITIVES_GENERA
On 2 May 2013 12:54, Chris Wilson wrote:
> On Thu, May 02, 2013 at 09:07:08AM -0700, Eric Anholt wrote:
> > Chris Wilson writes:
> >
> > > On Thu, May 02, 2013 at 07:26:06AM -0700, Paul Berry wrote:
> > >>Can you provide a documentation reference for why the value we're
> > >>currently p
> Well in contrast to the IF/UIF they'd be really redundant unless I'm
> missing something so just for supporting negation on inputs or not this
> looks like not really worth it (and as said there are also other signed
> instructions where supporting negation doesn't really make sense). OTOH
> you'
On Thu, May 02, 2013 at 09:07:08AM -0700, Eric Anholt wrote:
> Chris Wilson writes:
>
> > On Thu, May 02, 2013 at 07:26:06AM -0700, Paul Berry wrote:
> >>Can you provide a documentation reference for why the value we're
> >>currently programming (0xf001) is unsafe, and why 0x7fff0001
On Thu, 2 May 2013 07:58:30 -0700
Matt Turner wrote:
> > -TEST_LIBS = -lXvMCW -lXvMC -lXv -lX11
> > +TEST_LIBS = $(XVMC_LIBS) -lXvMCW -lXvMC -lXv -lX11
>
> Doesn't XVMC_LIBS include all of those other libraries? I think
> they're now redundant and should be removed.
It doesn't here:
XVMC_LIBS =
On Thu, May 2, 2013 at 11:28 AM, gregory hainaut
wrote:
> On Fri, 12 Apr 2013 13:52:46 -0700
> Eric Anholt wrote:
>> gregory hainaut writes:
>> > On Fri, 12 Apr 2013 12:38:19 -0700
>> > Eric Anholt wrote:
>> >
>> >> Please, patches for Mesa have to actually be addressed to Mesa.
>> >
>> > What
On Fri, 12 Apr 2013 13:52:46 -0700
Eric Anholt wrote:
> gregory hainaut writes:
>
> > On Fri, 12 Apr 2013 12:38:19 -0700
> > Eric Anholt wrote:
> >
> >> Please, patches for Mesa have to actually be addressed to Mesa.
> >
> > What do you mean? The github tree (was requested by Jordan)? Or
> > b
Marek Olšák writes:
> MaxUniformComponents contains only the limit for the default uniform buffer,
> but the linker also adds all uniforms blocks to the uniform usage stats,
> causing bogus linker failures.
So now you can have MaxCombinedUniformComponents in the default uniform
block? It seems
Marek Olšák writes:
> diff --git a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
> b/src/mesa/drivers/dri/intel/intel_buffer_objects.c
> index 996518b..f941c56 100644
> --- a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
> +++ b/src/mesa/drivers/dri/intel/intel_buffer_objects.c
> @@ -39,6
On 05/02/2013 02:13 AM, Chris Wilson wrote:
On Wed, May 01, 2013 at 04:28:08PM -0700, Eric Anholt wrote:
The GPU apparently goes looking for constants even though there are no
shader stages enabled, and gets stuck because we haven't told it there are
no constants to collect. If any other user o
There is a single limit in OpenGL - GL_MAX_VERTEX_ATTRIBS, and there
is one-to-one mapping between vertex array bindings and vertex shader
inputs. Anyway, the core Mesa limit is 16 at the moment and I don't
plan to change it (the vbo module has to analyze all available vertex
attribs no matter how
Marek Olšák writes:
> Shaders are unified on most hardware (= same limits in all stages).
> No idea what the assertion was good for.
> ---
> src/mesa/main/config.h |6 ++
> src/mesa/main/context.c|6 ++
> src/mesa/state_tracker/st_extensions.c |
On Tue, Apr 30, 2013 at 03:59:43PM +0200, Vincent Lejeune wrote:
> This is a port of "r600g:mask unused source components for SAMPLE"
> patch from Vadim Girlin.
Reviewed-by: Tom Stellard
Can you wrap those long line before you commit.
> ---
> src/gallium/drivers/r600/r600_llvm.c | 25 ++
On 05/01/2013 08:41 PM, Jordan Justen wrote:
On Tue, Apr 30, 2013 at 10:01 AM, Jordan Justen wrote:
On Tue, Apr 30, 2013 at 9:57 AM, Ian Romanick wrote:
On 04/27/2013 04:32 PM, Jordan Justen wrote:
This GLSL extension requires that AMD_vertex_shader_layer be
enabled by the driver.
Most (a
Am 02.05.2013 18:16, schrieb Zack Rusin:
> - Original Message -
>>> I don't oppose either. Integer signedness has always been too loose for us
>>> to be pedantic about it here.
>>>
>>
>> Ok. We should update tgsi docs to reflect that, however.
>> Note that we already moved some opcodes (ok
On 05/02/2013 07:55 PM, Marek Olšák wrote:
AFAIK, there are 16 fetch shader resources. These are the resource
slots for r600:
Ah, you are right (though it's higher on EG as Alex wrote). Anyway, I'm
not against your patch, I just wanted to understand where this limit
comes from. I think this ca
- Original Message -
> > I don't oppose either. Integer signedness has always been too loose for us
> > to be pedantic about it here.
> >
>
> Ok. We should update tgsi docs to reflect that, however.
> Note that we already moved some opcodes (ok only one, uadd) to the
> signed section in
On Thu, May 2, 2013 at 11:55 AM, Marek Olšák wrote:
> AFAIK, there are 16 fetch shader resources. These are the resource
> slots for r600:
>
> [offset .. +count]
> PS: 0 .. +160
> VS: 160 .. +160
> FS: 320 .. +16
> GS: 336 .. +160
It's bigger on evergreen:
PS: 0.. +176
VS: 176.. +160
GS: 336..
Chris Wilson writes:
> On Thu, May 02, 2013 at 07:26:06AM -0700, Paul Berry wrote:
>>Can you provide a documentation reference for why the value we're
>>currently programming (0xf001) is unsafe, and why 0x7fff0001 is
>>correct?� I don't see anything in the bspec.
>
> The largest G
On Thu, May 02, 2013 at 05:18:51PM +0200, Armin K. wrote:
> On 05/02/2013 04:56 PM, Tom Stellard wrote:
> >From: Tom Stellard
> >
> >---
> > src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 9 -
> > src/gallium/drivers/radeon/radeon_llvm_emit.cpp | 2 +-
> > 2 files changed, 9 insertions
AFAIK, there are 16 fetch shader resources. These are the resource
slots for r600:
[offset .. +count]
PS: 0 .. +160
VS: 160 .. +160
FS: 320 .. +16
GS: 336 .. +160
Marek
On Thu, May 2, 2013 at 5:04 PM, Vadim Girlin wrote:
> On 05/02/2013 11:06 AM, Michel Dänzer wrote:
>>
>> On Don, 2013-05-02
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_core.cpp | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/sb_core.cpp
b/src/gallium/drivers/r600/sb/sb_core.cpp
index 9f81ed4..b919fa4 100644
--- a/src/gallium/drivers/r600/sb/sb_core.cpp
+++ b/src/ga
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_ra_init.cpp | 25 +++--
src/gallium/drivers/r600/sb/sb_sched.cpp | 4
2 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/sb_ra_init.cpp
b/src/gallium/drivers/r600/
post_scheduler clears interference set for reallocatable values when
the value becomes live first time, and then updates it to take into
account modified order of operations, but this was not handled properly
if the value appears first time as a source in copy operation.
Fixes issues with webgl de
Some inputs may be preloaded into predefined GPRs,
so we can't reallocate arrays with such inputs.
Fixes issues with webgl demo: http://oos.moxiecode.com/js_webgl/snake/
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_ra_coalesce.cpp | 14 +-
src/gallium/drivers/r600/
On Thu, May 02, 2013 at 07:26:06AM -0700, Paul Berry wrote:
>Can you provide a documentation reference for why the value we're
>currently programming (0xf001) is unsafe, and why 0x7fff0001 is
>correct?� I don't see anything in the bspec.
The largest GTT size for gen6 is 2GiB (it ca
https://bugs.freedesktop.org/show_bug.cgi?id=64153
Rafael Castillo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=64153
--- Comment #2 from Rafael Castillo ---
fixed thank you very much
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
htt
On 05/02/2013 04:56 PM, Tom Stellard wrote:
From: Tom Stellard
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 9 -
src/gallium/drivers/radeon/radeon_llvm_emit.cpp | 2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.
On 05/02/2013 11:06 AM, Michel Dänzer wrote:
On Don, 2013-05-02 at 05:45 +0200, Marek Olšák wrote:
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
b/src/gallium/drivers/radeon
From: Tom Stellard
The LLVM C API is considered stable and should never change, so it
is much more desirable to use than the LLVM C++ API, which is constantly in
flux.
v2:
- Split target initialization and lookup into separate functions
---
src/gallium/drivers/radeon/Makefile.am |
From: Tom Stellard
This does not solve all of the problems with using LLVM in a
multithreaded enivronment, but it should help in some cases.
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 15 +++
src/gallium/drivers/radeon/radeon_llvm_emit.cpp | 14 --
2 files chan
From: Tom Stellard
This library is very small, so there is not much to gain from building
it as a shared library. Also, when linking statically with LLVM, a
shared libradeonllvm exports LLVM symbols and creates problems when
used with other shared objects that also link statically to LLVM.
---
On Wed, May 1, 2013 at 12:17 PM, Lauri Kasanen wrote:
> Without this, the X lib path was not properly passed for tests/:
> /usr/bin/ld: cannot find -lXvMCW
> /usr/bin/ld: cannot find -lXvMC
> /usr/bin/ld: cannot find -lXv
> /usr/bin/ld: cannot find -lX11
> collect2: ld returned 1 exit status
>
> S
https://bugs.freedesktop.org/show_bug.cgi?id=64153
--- Comment #1 from Tom Stellard ---
Created attachment 78784
--> https://bugs.freedesktop.org/attachment.cgi?id=78784&action=edit
Build fix
This patch should fix it.
--
You are receiving this mail because:
You are the assignee for the bug.
From: Tom Stellard
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 9 -
src/gallium/drivers/radeon/radeon_llvm_emit.cpp | 2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.
On Thu, May 2, 2013 at 12:08 AM, Topi Pohjolainen
wrote:
> Provides definitions for dma buffer import extension.
>
> Signed-off-by: Topi Pohjolainen
> ---
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.f
Am 02.05.2013 13:22, schrieb Jose Fonseca:
>
>
> - Original Message -
>> - Original Message -
>>> Am 02.05.2013 03:13, schrieb Zack Rusin:
It's valid. Some shaders do the negation on unsigned and then
use the results in opcodes taking signed integers.
Signed-of
On Thu, 02 May 2013 00:45:13 +0400
Vadim Girlin wrote:
> On 05/01/2013 11:36 PM, Lauri Kasanen wrote:
> > Now that it built, I could test your optimizations in my own apps.
> > These are on current master 8eef6ad, on a RV710 (HD 4350 pci-e).
> >
> > In one of my private apps, using R600_DEBUG=sb
https://bugs.freedesktop.org/show_bug.cgi?id=64153
Rafael Castillo changed:
What|Removed |Added
Priority|medium |highest
Assignee|i...@freede
From: Christian König
Kills tilling on UVD buffers, but we currently don't really need that.
Signed-off-by: Christian König
---
src/gallium/drivers/r600/r600_uvd.c |6 +++---
src/gallium/drivers/radeon/radeon_uvd.c |4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --g
Sorry, it's a typo. I'll fix that.
Marek
On Thu, May 2, 2013 at 4:23 PM, Brian Paul wrote:
> On 05/01/2013 09:43 PM, Marek Olšák wrote:
>>
>> ---
>> src/gallium/docs/source/screen.rst |2 ++
>> src/gallium/drivers/llvmpipe/lp_screen.c |2 ++
>> src/gallium/drivers/nv30/
On 2 May 2013 02:13, Chris Wilson wrote:
> On Wed, May 01, 2013 at 04:28:08PM -0700, Eric Anholt wrote:
> > The GPU apparently goes looking for constants even though there are no
> > shader stages enabled, and gets stuck because we haven't told it there
> are
> > no constants to collect. If any
On 05/01/2013 09:42 PM, Marek Olšák wrote:
Shaders are unified on most hardware (= same limits in all stages).
No idea what the assertion was good for.
---
src/mesa/main/config.h |6 ++
src/mesa/main/context.c|6 ++
src/mesa/state_tracker/st_ext
On 05/01/2013 09:43 PM, Marek Olšák wrote:
---
src/gallium/docs/source/screen.rst |2 ++
src/gallium/drivers/llvmpipe/lp_screen.c |2 ++
src/gallium/drivers/nv30/nv30_screen.c |1 +
src/gallium/drivers/nv50/nv50_screen.c |2 ++
src/gallium/drivers/n
From: Christian König
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_video_buffer.c | 16
src/gallium/auxiliary/vl/vl_video_buffer.h | 10 +-
src/gallium/drivers/r600/r600_uvd.c |6 +++---
src/gallium/drivers/radeonsi/radeonsi_uvd.c |
From: Christian König
Still not perfect, but a step in the right direction.
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/radeon_uvd.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/
From: Christian König
We still need the option for handling 3D textures as well.
Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=64143
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c |6 +++---
src/gallium/auxiliary/vl/vl_video_buffer.c | 23 ++
https://bugs.freedesktop.org/show_bug.cgi?id=63404
Emilio Pozuelo Monfort changed:
What|Removed |Added
CC||poch...@gmail.com
--
You are r
On Mit, 2013-05-01 at 19:26 +0300, Lauri Kasanen wrote:
> Without this patch, radeon_uvd failed to find the libdrm includes:
>
> In file included from radeon_uvd.c:48:
> ../../winsys/radeon/drm/radeon_winsys.h:44:35: error:
> libdrm/radeon_surface.h: No such file or directory
>
> Signed-off-by:
glsl-max-varyings uses 33 vertex shader outputs, but you need to be
lucky to see any difference. In my case, there was a weird assertion
failure during command buffer generation for a vertex shader (valgrind
didn't help). I found the cause by moving the input and output arrays
to the end of r600_sh
Alright. I'm deleting the patch.
Marek
On Thu, May 2, 2013 at 9:06 AM, Michel Dänzer wrote:
> On Don, 2013-05-02 at 05:45 +0200, Marek Olšák wrote:
>> ---
>> src/gallium/drivers/radeonsi/radeonsi_pipe.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/d
- Original Message -
> instead of crashing just fill zeros at the input slots that don't
> match, that's the mandated behavior and it avoids debug asserts.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/auxiliary/draw/draw_gs.c | 93
> --
> 1 file
- Original Message -
> - Original Message -
> > Am 02.05.2013 03:13, schrieb Zack Rusin:
> > > It's valid. Some shaders do the negation on unsigned and then
> > > use the results in opcodes taking signed integers.
> > >
> > > Signed-off-by: Zack Rusin
> > > ---
> > > src/galliu
---
src/gallium/drivers/radeon/radeon_llvm_emit.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.cpp
b/src/gallium/drivers/radeon/radeon_llvm_emit.cpp
index 55dad9b..e0ea31d 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_em
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index 717afa7..a531d98 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
On Wed, May 01, 2013 at 04:28:08PM -0700, Eric Anholt wrote:
> The GPU apparently goes looking for constants even though there are no
> shader stages enabled, and gets stuck because we haven't told it there are
> no constants to collect. If any other user of the 3D pipeline had run
> (even the Ren
Am 01.05.2013 21:17, schrieb Lauri Kasanen:
Without this, the X lib path was not properly passed for tests/:
/usr/bin/ld: cannot find -lXvMCW
/usr/bin/ld: cannot find -lXvMC
/usr/bin/ld: cannot find -lXv
/usr/bin/ld: cannot find -lX11
collect2: ld returned 1 exit status
Signed-off-by: Lauri Kasa
Am 02.05.2013 09:06, schrieb Michel Dänzer:
On Don, 2013-05-02 at 05:45 +0200, Marek Olšák wrote:
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
b/src/gallium/drivers/radeons
The function returns the number of reduced/tessellated primitives for the
given vertex count.
Signed-off-by: Chia-I Wu
---
src/gallium/auxiliary/util/u_prim.h | 20
1 file changed, 20 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_prim.h
b/src/gallium/auxiliary/
Switch to '>=' for comparisons, and it becomes obvious that the comparison for
PIPE_PRIM_QUAD_STRIP was wrong.
Add minimum vertex count check for PIPE_PRIM_LINE_LOOP. Return 1 for
PIPE_PRIM_POLYGON with 3 vertices.
Signed-off-by: Chia-I Wu
---
src/gallium/auxiliary/util/u_prim.h | 22 +++
1 - 100 of 119 matches
Mail list logo
