On 04/30/2013 12:56 PM, Eric Anholt wrote:
There was some comment about trying to avoid marking resolves in
updownsample, but if the downsample is never actually rendered to, then
the required resolve tracked in the downsample will never be executed, so
who cares?
---
On 04/30/2013 12:56 PM, Eric Anholt wrote:
Everyone was doing effectively the same thing, except for some funky code
reuse in Intel, and swrast mistakenly recomputing _BaseFormat instead of
using the texture's _BaseFormat. swrast's sRGB handling is left in place,
though it should be done by
On Tue, Apr 30, 2013 at 11:03:21AM -0700, Ian Romanick wrote:
On 04/29/2013 04:08 AM, Topi Pohjolainen wrote:
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
On Tue, Apr 30, 2013 at 11:03:20AM -0700, Ian Romanick wrote:
On 04/29/2013 04:08 AM, Topi Pohjolainen wrote:
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
include/GL/internal/dri_interface.h| 23 +++
src/egl/drivers/dri2/egl_dri2.c|
On Mon, Apr 29, 2013 at 4:08 AM, Topi Pohjolainen
topi.pohjolai...@intel.com wrote:
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.
On Wed, May 1, 2013 at 9:25 PM, Jordan Justen jljus...@gmail.com wrote:
pending resolution meant I'd figure out what the AMD driver is
doing, and follow that.
Indeed, sorry -- reading comprehension fail.
___
mesa-dev mailing list
On Wed, May 01, 2013 at 11:13:37PM -0700, Matt Turner wrote:
On Mon, Apr 29, 2013 at 4:08 AM, Topi Pohjolainen
topi.pohjolai...@intel.com wrote:
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
On 05/01/2013 08:42 PM, Marek Olšák wrote:
NOTE: This is a candidate for the 9.1 branch.
---
src/glsl/builtin_variables.cpp |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index b0c7a20..15f5bf3 100644
---
On 05/01/2013 08:42 PM, Marek Olšák wrote:
Const.MaxTextureImageUnits - Const.FragmentProgram.MaxTextureImageUnits
Const.MaxVertexTextureImageUnits - Const.VertexProgram.MaxTextureImageUnits
etc.
Thanks for doing this! It's much nicer this way.
Patches 1-5, 8, and 17 are:
Reviewed-by:
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..3b9be54
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
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
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
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
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
---
No functional change in preparation for supporting multiple planes
per image each having its own region.
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/intel/intel_fbo.c | 6 +--
src/mesa/drivers/dri/intel/intel_regions.h | 7 ++-
v2:
- refactor both occurences, not just one
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
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
Otherwise 'intel_set_texture_image_region()' won't have enough
details to work with.
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
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
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 topi.pohjolai...@intel.com
---
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 topi.pohjolai...@intel.com
---
include/GL/internal/dri_interface.h| 36 +-
Provides definitions for dma buffer import extension.
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
include/EGL/eglext.h | 45 ++---
1 file changed, 42 insertions(+), 3 deletions(-)
diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
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 topi.pohjolai...@intel.com
---
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
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 olva...@gmail.com
---
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
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 olva...@gmail.com
---
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
It should be U_PRIM_H, not U_BLIT_H.
Signed-off-by: Chia-I Wu olva...@gmail.com
---
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
As a side effect, primitives with adjacency are now correctly validated.
Signed-off-by: Chia-I Wu olva...@gmail.com
---
src/gallium/auxiliary/util/u_prim.h | 34 ++
1 file changed, 2 insertions(+), 32 deletions(-)
diff --git
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 olva...@gmail.com
---
The function returns the number of reduced/tessellated primitives for the
given vertex count.
Signed-off-by: Chia-I Wu olva...@gmail.com
---
src/gallium/auxiliary/util/u_prim.h | 20
1 file changed, 20 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_prim.h
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
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
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 Render
---
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
---
- 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 za...@vmware.com
---
- 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 za...@vmware.com
---
src/gallium/auxiliary/draw/draw_gs.c | 93
--
Alright. I'm deleting the patch.
Marek
On Thu, May 2, 2013 at 9:06 AM, Michel Dänzer mic...@daenzer.net 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
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
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: Lauri
https://bugs.freedesktop.org/show_bug.cgi?id=63404
Emilio Pozuelo Monfort poch...@gmail.com changed:
What|Removed |Added
CC|
From: Christian König christian.koe...@amd.com
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 christian.koe...@amd.com
---
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c |6 +++---
From: Christian König christian.koe...@amd.com
Still not perfect, but a step in the right direction.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_uvd.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
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 +++---
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 ++
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 ++
On 2 May 2013 02:13, Chris Wilson ch...@chris-wilson.co.uk 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
Sorry, it's a typo. I'll fix that.
Marek
On Thu, May 2, 2013 at 4:23 PM, Brian Paul bri...@vmware.com 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 ++
From: Christian König christian.koe...@amd.com
Kills tilling on UVD buffers, but we currently don't really need that.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/r600/r600_uvd.c |6 +++---
src/gallium/drivers/radeon/radeon_uvd.c |4 ++--
2 files
https://bugs.freedesktop.org/show_bug.cgi?id=64153
Rafael Castillo jrch2...@gmail.com changed:
What|Removed |Added
Priority|medium |highest
On Thu, 02 May 2013 00:45:13 +0400
Vadim Girlin vadimgir...@gmail.com 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
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-off-by: Zack Rusin
On Thu, May 2, 2013 at 12:08 AM, Topi Pohjolainen
topi.pohjolai...@intel.com wrote:
Provides definitions for dma buffer import extension.
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
Reviewed-by: Matt Turner matts...@gmail.com
___
From: Tom Stellard thomas.stell...@amd.com
---
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
https://bugs.freedesktop.org/show_bug.cgi?id=64153
--- Comment #1 from Tom Stellard tstel...@gmail.com ---
Created attachment 78784
-- https://bugs.freedesktop.org/attachment.cgi?id=78784action=edit
Build fix
This patch should fix it.
--
You are receiving this mail because:
You are the
On Wed, May 1, 2013 at 12:17 PM, Lauri Kasanen c...@gmx.com 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
From: Tom Stellard thomas.stell...@amd.com
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
From: Tom Stellard thomas.stell...@amd.com
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
From: Tom Stellard thomas.stell...@amd.com
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
---
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
On 05/02/2013 04:56 PM, Tom Stellard wrote:
From: Tom Stellard thomas.stell...@amd.com
---
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
https://bugs.freedesktop.org/show_bug.cgi?id=64153
--- Comment #2 from Rafael Castillo jrch2...@gmail.com ---
fixed thank you very much
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=64153
Rafael Castillo jrch2...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
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 can
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 vadimgir...@gmail.com
---
src/gallium/drivers/r600/sb/sb_ra_coalesce.cpp | 14 +-
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
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
---
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 vadimgir...@gmail.com wrote:
On 05/02/2013 11:06 AM, Michel Dänzer wrote:
On
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 thomas.stell...@amd.com
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 9 -
src/gallium/drivers/radeon/radeon_llvm_emit.cpp | 2 +-
2 files changed, 9
Chris Wilson ch...@chris-wilson.co.uk 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.
On Thu, May 2, 2013 at 11:55 AM, Marek Olšák mar...@gmail.com 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
- 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
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 only one,
On 05/01/2013 08:41 PM, Jordan Justen wrote:
On Tue, Apr 30, 2013 at 10:01 AM, Jordan Justen jljus...@gmail.com wrote:
On Tue, Apr 30, 2013 at 9:57 AM, Ian Romanick i...@freedesktop.org wrote:
On 04/27/2013 04:32 PM, Jordan Justen wrote:
This GLSL extension requires that
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 thomas.stell...@amd.com
Can you wrap those long line before you commit.
---
Marek Olšák mar...@gmail.com 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 ++
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
Marek Olšák mar...@gmail.com 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
+++
Marek Olšák mar...@gmail.com 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
On Fri, 12 Apr 2013 13:52:46 -0700
Eric Anholt e...@anholt.net wrote:
gregory hainaut gregory.hain...@gmail.com writes:
On Fri, 12 Apr 2013 12:38:19 -0700
Eric Anholt e...@anholt.net wrote:
Please, patches for Mesa have to actually be addressed to Mesa.
What do you mean? The github
On Thu, May 2, 2013 at 11:28 AM, gregory hainaut
gregory.hain...@gmail.com wrote:
On Fri, 12 Apr 2013 13:52:46 -0700
Eric Anholt e...@anholt.net wrote:
gregory hainaut gregory.hain...@gmail.com writes:
On Fri, 12 Apr 2013 12:38:19 -0700
Eric Anholt e...@anholt.net wrote:
Please, patches
On Thu, 2 May 2013 07:58:30 -0700
Matt Turner matts...@gmail.com 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:
On Thu, May 02, 2013 at 09:07:08AM -0700, Eric Anholt wrote:
Chris Wilson ch...@chris-wilson.co.uk 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
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're
On 2 May 2013 12:54, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, May 02, 2013 at 09:07:08AM -0700, Eric Anholt wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
On Thu, May 02, 2013 at 07:26:06AM -0700, Paul Berry wrote:
Can you provide a documentation reference for why
- 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_GENERATED.
On 05/02/2013 01:08 PM, Paul Berry wrote:
On 2 May 2013 12:54, Chris Wilson ch...@chris-wilson.co.uk
mailto:ch...@chris-wilson.co.uk wrote:
On Thu, May 02, 2013 at 09:07:08AM -0700, Eric Anholt wrote:
Chris Wilson ch...@chris-wilson.co.uk
mailto:ch...@chris-wilson.co.uk writes:
On Thu, May 2, 2013 at 11:52 AM, Lauri Kasanen c...@gmx.com wrote:
On Thu, 2 May 2013 07:58:30 -0700
Matt Turner matts...@gmail.com 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
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
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 chr...@ijw.co.nz [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
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.
---
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
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
On 05/02/2013 06:34 PM, Lauri Kasanen wrote:
On Thu, 02 May 2013 00:45:13 +0400
Vadim Girlin vadimgir...@gmail.com 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
1 - 100 of 126 matches
Mail list logo
