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/radeonsi/radeonsi_pipe.c
> index c923c67..3
The set introduces new target for 'eglCreateImageKHR()' allowing one
to create EGL images out of externally allocated buffers. Especially
one can combine up to three separate buffers into one single logical
entity. Low level native buffers may not support planar formats and
hence EGL layer will ins
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/intel/intel_screen.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index ad1b351..1ba1279 100644
--- a/src/mesa/drivers/dri/in
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/intel/intel_fbo.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 6730d26..6aaf6b6 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/
No functional change in preparation for supporting multiple planes
per image each having its own region.
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/intel/intel_fbo.c | 6 +--
src/mesa/drivers/dri/intel/intel_regions.h | 7 ++-
src/mesa/drivers/dri/intel/intel_screen.c
v2:
- refactor both occurences, not just one
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/intel/intel_screen.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/in
Otherwise 'intel_set_texture_image_region()' won't have enough
details to work with.
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/intel/intel_screen.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_s
v2 (as advised by Eric):
- use ARRAY_SIZE
- re-use 'image_destroy' for cleaning up after failure
- check directly the region pointer instead of the buffer object
when determining if a region exists
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/intel/intel_screen.c | 103
v2:
- do not break ABI, but instead introduce new entry point for
dma buffers and bump up the dri-interface version to eight
Signed-off-by: Topi Pohjolainen
---
include/GL/internal/dri_interface.h| 36 +-
src/mesa/drivers/dri/intel/intel_regions.h | 7
Provides definitions for dma buffer import extension.
Signed-off-by: Topi Pohjolainen
---
include/EGL/eglext.h | 45 ++---
1 file changed, 42 insertions(+), 3 deletions(-)
diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
index b2b5a80..1d68178 100
As specified in:
http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
Checking for the valid fourcc values is left for drivers avoiding
dependency to drm header files here.
v2:
- enforce EGL_NO_CONTEXT
v3:
- declare the extension as EGL (not GLES)
v4:
-
v2:
- upon success close the given file descriptors
v3:
- use specific entry for dma buffers instead of the basic for
primes, and enable the extension based on the availability
of the hook
Signed-off-by: Topi Pohjolainen
---
src/egl/drivers/dri2/egl_dri2.c | 280
On Don, 2013-05-02 at 05:45 +0200, Marek Olšák wrote:
> and add assertions to prevent buffer overflow. This fixes corruption
> of the r600_shader struct.
Any pointers to tests exercising this? I noticed just yesterday that the
corresponding code in radeonsi seems a bit wonky...
--
Earthling Mi
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_GENERATED.
Fix for PIPE_PRIM_TRIANGLES_ADJACENCY and PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY.
Signed-off-by: Chia-I Wu
---
src/gallium/auxiliary/util/u_prim.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_prim.h
b/src/gallium/auxiliary/util/u_prim.h
ind
Move together (or add) functions to decompose/reduce/assemble a primitive,
give them consistent names, and document them. Add u_prim_vertex_count() so
that the vertex count information can be used elsewhere.
u_assembled_primitive() will be removed in a folow-on commit.
Signed-off-by: Chia-I Wu
The latter function is also removed as a result of the change.
Signed-off-by: Chia-I Wu
---
src/gallium/auxiliary/draw/draw_prim_assembler.c |4 ++--
src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c |2 +-
src/gallium/auxiliary/util/u_prim.h |8
It should be U_PRIM_H, not U_BLIT_H.
Signed-off-by: Chia-I Wu
---
src/gallium/auxiliary/util/u_prim.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_prim.h
b/src/gallium/auxiliary/util/u_prim.h
index b9c0c15..c6a0708 100644
--- a/src/gall
As a side effect, primitives with adjacency are now correctly validated.
Signed-off-by: Chia-I Wu
---
src/gallium/auxiliary/util/u_prim.h | 34 ++
1 file changed, 2 insertions(+), 32 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_prim.h
b/src/gallium/a
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 +++
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/
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
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
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
---
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
---
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
- 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
- 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
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
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
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:
https://bugs.freedesktop.org/show_bug.cgi?id=63404
Emilio Pozuelo Monfort changed:
What|Removed |Added
CC||poch...@gmail.com
--
You are r
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 ++
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
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 |
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
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 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
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/
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
https://bugs.freedesktop.org/show_bug.cgi?id=64153
Rafael Castillo changed:
What|Removed |Added
Priority|medium |highest
Assignee|i...@freede
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
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, 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
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.
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.
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
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.
---
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
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 |
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
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.
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
https://bugs.freedesktop.org/show_bug.cgi?id=64153
Rafael Castillo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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/
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
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/
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
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
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
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 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..
- 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 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
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/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
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 ++
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 |
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
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
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
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
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
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 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 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
> 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 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
- 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 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 -
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 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
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 +++
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
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
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
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
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
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
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
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
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 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
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
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
---
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
---
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/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
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
1 - 100 of 119 matches
Mail list logo
