On 04.04.2013 21:53, Christoph Bumiller wrote:
On 04.04.2013 21:44, Jose Fonseca wrote:
I think that PIPE_BIND_INDIRECT_BUFFER would be more self-descriptive.
Marek suggested PIPE_BIND_DRAW_INDIRECT_BUFFER, but I think that's too
specific because there's also a DISPATCH_INDIRECT buffer for
- Original Message -
we break when the mask values are 0 not, 1, plus it's bit comparison
not a floating point comparison. This fixes both.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 26
---
1 file
On 04.04.2013 21:17, Brian Paul wrote:
I just did a quick skim and found a few minor things.
First, the subject might be mesa: implement GL_ARB_draw_indirect and
GL_ARB_multi_draw_indirect
This is a big patch and I think it could have been broken down into
smaller pieces, but I know it's a
On 05.04.2013 13:32, Christoph Bumiller wrote:
On 04.04.2013 21:17, Brian Paul wrote:
I just did a quick skim and found a few minor things.
First, the subject might be mesa: implement GL_ARB_draw_indirect and
GL_ARB_multi_draw_indirect
This is a big patch and I think it could have been
I don't feel strongly about it anyway. Can always change it later.
Jose
- Original Message -
On 04.04.2013 21:53, Christoph Bumiller wrote:
On 04.04.2013 21:44, Jose Fonseca wrote:
I think that PIPE_BIND_INDIRECT_BUFFER would be more self-descriptive.
Marek suggested
Intended for use with GL_ARB_draw_indirect's DRAW_INDIRECT_BUFFER
target or for D3D11_RESOURCE_MISC_DRAWINDIRECT_ARGS.
---
src/gallium/docs/source/screen.rst |3 +++
src/gallium/include/pipe/p_defines.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git
Split from patch implementing ARB_draw_indirect.
v2:
Const-qualify the struct gl_buffer_object *indirect argument.
---
src/mesa/drivers/dri/i965/brw_draw.c |3 ++-
src/mesa/drivers/dri/i965/brw_draw.h |3 ++-
src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c |9 ++---
---
src/mesa/state_tracker/st_cb_bufferobjects.c |3 +++
src/mesa/state_tracker/st_draw.c | 11 ++-
src/mesa/state_tracker/st_extensions.c |3 ++-
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c
v2:
Removed some stray extern qualifiers.
Documented use of Draw*IndirectCommand sizes.
Removed separate extension enable flag for ARB_multi_draw_indirect
since this can always be supported by looping.
Kept generation of GL_INVALID_OPERATION in display list compile.
The spec doesn't say
v2:
Added comments to util_draw_indirect, clarified and fixed map size.
Removed unlikely().
---
src/gallium/auxiliary/util/u_draw.c | 43 ++
src/gallium/auxiliary/util/u_draw.h |8
src/gallium/auxiliary/util/u_dump_state.c|3 ++
v2:
Fix for constness of indirect buffer argument.
Remove separate extension enable for multi_draw_indirect.
---
src/mesa/state_tracker/st_cb_bufferobjects.c |3 +++
src/mesa/state_tracker/st_cb_bufferobjects.h |6 ++
src/mesa/state_tracker/st_draw.c | 11 ++-
(Will be merged into the original patches.)
Calculating the actual limits is impossible, and softpipe drops
vertices that lie outside the specified range.
---
src/gallium/auxiliary/util/u_draw.c |4
src/mesa/state_tracker/st_draw.c|3 +++
src/mesa/vbo/vbo_exec_array.c |
- Original Message -
Don't check if there's sampler support for stencil if we're not
going to actually blit/copy stencil values. Fixes the case where
we mistakenly said we can't support a blit of depth values from
S8Z24 to X8Z24.
Also, rename the is_stencil variable to
On 04/05/2013 11:32 AM, Jose Fonseca wrote:
- Original Message -
Don't check if there's sampler support for stencil if we're not
going to actually blit/copy stencil values. Fixes the case where
we mistakenly said we can't support a blit of depth values from
S8Z24 to X8Z24.
Also,
From 1b3d69d7749e3b82f529d2a41b80f5cd64447d92 Mon Sep 17 00:00:00 2001
From: Wladimir J. van der Laan laa...@gmail.com
Date: Fri, 5 Apr 2013 18:58:32 +0200
Subject: [PATCH] gallium/auxiliary: Add ETC as compressed format
Add UTIL_FORMAT_LAYOUT_ETC to util_format_is_compressed. It was missing.
https://bugs.freedesktop.org/show_bug.cgi?id=47607
--- Comment #11 from Jordan Justen jljus...@gmail.com ---
I wanted to add one note. The game now works for me with
Mesa 9.0.3 via Steam, but it is crashing for me with Mesa 9.1.1
after the intro movie. I'll work with the game developer on
this...
On 04/05/2013 11:49 AM, Wladimir wrote:
From 1b3d69d7749e3b82f529d2a41b80f5cd64447d92 Mon Sep 17 00:00:00 2001
From: Wladimir J. van der Laan laa...@gmail.com
mailto:laa...@gmail.com
Date: Fri, 5 Apr 2013 18:58:32 +0200
Subject: [PATCH] gallium/auxiliary: Add ETC as compressed format
Add
This allows the computation of the offset to get written directly into the
message source.
shader-db results:
total instructions in shared programs: 3308390 - 3283025 (-0.77%)
instructions in affected programs: 442998 - 417633 (-5.73%)
No difference in GLB2.7 low res (n=9).
---
https://bugs.freedesktop.org/show_bug.cgi?id=63078
Chad Versace chad.vers...@linux.intel.com changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=56542
Jerome Glisse gli...@freedesktop.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Daniel Vetter dan...@ffwll.ch writes:
On Tue, Apr 02, 2013 at 06:46:32PM -0700, Eric Anholt wrote:
This still fails, since 8192*4bpp == 32768, which is too big to use the
blitter on.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |
From: Tom Stellard thomas.stell...@amd.com
Instead of emitting configuration values (e.g. number of gprs used) in a
predefined order, the LLVM backend now emits these values in
register/value pairs. The first dword contains the register address and
the second dword contians the value to write.
From: Tom Stellard thomas.stell...@amd.com
---
configure.ac| 2 ++
src/gallium/drivers/radeon/Makefile.am | 3 +-
src/gallium/drivers/radeon/radeon_llvm_emit.cpp | 38 ++---
3 files changed, 38 insertions(+), 5 deletions(-)
diff
From: Tom Stellard thomas.stell...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
index 218997f..0aeecc2
From: Tom Stellard thomas.stell...@amd.com
---
lib/Target/R600/AMDGPUAsmPrinter.cpp | 10 +-
test/CodeGen/R600/elf.ll | 1 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/lib/Target/R600/AMDGPUAsmPrinter.cpp
b/lib/Target/R600/AMDGPUAsmPrinter.cpp
index
From: Tom Stellard thomas.stell...@amd.com
Instead of emitting config values in a predefined order, the code
emitter will now emit a 32-bit register index followed by the 32-bit
config value.
---
lib/Target/R600/AMDGPUAsmPrinter.cpp | 19 ---
lib/Target/R600/SIDefines.h
From: Tom Stellard thomas.stell...@amd.com
---
lib/Target/R600/MCTargetDesc/AMDGPUAsmBackend.cpp | 29 ++--
.../R600/MCTargetDesc/AMDGPUELFObjectWriter.cpp| 39 ++
.../R600/MCTargetDesc/AMDGPUMCTargetDesc.cpp | 2 +-
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
This still fails, since 8192*4bpp == 32768, which is too big to use the
blitter on.
v2: Be more conservative about the size of the GTT -- I'd forgotten some
of the horror of older hardware.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 23 +++
1 file changed, 23
From: Tom Stellard thomas.stell...@amd.com
Using a NULL value for the platform_id is legal according to the spec,
however, passing a NULL value as the platform parameter to
clGetPlatformInfo() results in implementation defined behavior.
In order to avoid implementation defined behavior some apps
On Thu, Apr 4, 2013 at 1:02 AM, Ian Romanick i...@freedesktop.org wrote:
Reveiwed-by: Ian Romanick ian.d.roman...@intel.com
Please add the following lines to the commit message:
NOTE: This is a candidate for stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47478
From: Tom Stellard thomas.stell...@amd.com
Using a NULL value for the platform_id is legal according to the spec,
however, passing a NULL value as the platform parameter to
clGetPlatformInfo() results in implementation defined behavior.
In order to avoid implementation defined behavior some apps
On 04/05/2013 05:29 AM, Christoph Bumiller wrote:
v2:
Removed some stray extern qualifiers.
Documented use of Draw*IndirectCommand sizes.
Removed separate extension enable flag for ARB_multi_draw_indirect
since this can always be supported by looping.
Kept generation of GL_INVALID_OPERATION
From: Tom Stellard thomas.stell...@amd.com
Using a NULL value for the platform_id is legal according to the spec,
however, passing a NULL value as the platform parameter to
clGetPlatformInfo() results in implementation defined behavior.
In order to avoid implementation defined behavior some apps
Hello,
Please find an implementation of the ARB_separate_shader_objects extensions. I
concentrate mostly on the state part of
the extensions aka the pipeline object. I think GLSL already compiled program
separately anyway.
I test my implementation on the test that I send yesterday ago on
Nothings implemented yet but glProgramUniform* which are mostly
a copy/paste of the older function glUniform*
I create dedicated pipelineobj.[ch] file that will contains function
related to the new pipeline container object.
---
src/mapi/glapi/gen/ARB_separate_shader_objects.xml | 392
* Extend gl_shader_state as pipeline object state
* Add a new container gl_pipeline_shader_state that contains
binding point of the previous object
* Update mesa init/free shader state due to the extension of
the attibute
* Add an init/free pipeline function for the context
* Implement
CreateShaderProgramv is similar as CreateShaderProgramEXT. The 2 differences are
1/ it an array of strings
2/ it support the GL_PROGRAM_SEPARABLE (aka SeparateShader) flag
---
src/mesa/main/mtypes.h|5 +++
src/mesa/main/shaderapi.c | 90 +++--
2
---
src/mesa/main/pipelineobj.c | 73 +++
1 file changed, 73 insertions(+)
diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c
index e50416c..7a56c67 100644
--- a/src/mesa/main/pipelineobj.c
+++ b/src/mesa/main/pipelineobj.c
@@ -233,6
To avoid NULL pointer check a default pipeline object is installed in _Shader
when no
program is current
The spec say that UseProgram/UseShaderProgramEXT/ActiveProgramEXT got an higher
priority over the pipeline object. When default program is uninstall, the
pipeline is
used if any was bound.
Basically a sed but shaderapi.c and get.c.
get.c = GL_CURRENT_PROGAM always refer to the old UseProgram behavior
shaderapi.c = the old api stil update the Shader object directly
---
src/mesa/drivers/common/meta.c | 10 ++--
src/mesa/drivers/dri/i965/brw_gs.c |
save and restore _Shader/Pipeline binding point. Rational we don't want any
conflict
when the program will be unattached.
---
src/mesa/drivers/common/meta.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c
Implement _mesa_UseProgramStages =
arb_separate_shader_object-GetProgramPipelineiv is now pass :)
Extend use_shader_program to support a different target. Allow to reuse the
function to update
the pipeline state. Note I bypass the flush when target isn't current. Maybe it
would be better to
Test become green in piglit:
The updated ext_transform_feedback-api-errors:useprogstage_noactive
useprogstage_active bind_pipeline
arb_separate_shader_object-GetProgramPipelineiv
arb_separate_shader_object-IsProgramPipeline
For the moment I reuse Driver.UseProgram but I guess it will be better
---
src/mesa/main/get.c |9 +
src/mesa/main/get_hash_params.py |3 +++
2 files changed, 12 insertions(+)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 7ce2df1..f6311a5 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -356,6 +356,7 @@
Implementation note:
I don't use context for ralloc (don't know how).
The check on PROGRAM_SEPARABLE flags is also done when the pipeline isn't bound.
It doesn't make any sense in a DSA style API.
Maybe we could replace _mesa_validate_program_pipeline by
_mesa_validate_program_pipeline.
For
Note: it probably work on others drivers.
---
src/mesa/state_tracker/st_extensions.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 11db9d3..4af46f3 100644
--- a/src/mesa/state_tracker/st_extensions.c
On 04/05/2013 01:51 PM, Alexander Monakov wrote:
On Thu, Apr 4, 2013 at 1:02 AM, Ian Romanick i...@freedesktop.org wrote:
Reveiwed-by: Ian Romanick ian.d.roman...@intel.com
Please add the following lines to the commit message:
NOTE: This is a candidate for stable branches.
Bugzilla:
Rebase on top of lastest libdrm patch. With small modification to ddx you can
also
have tiled front buffer rendering. But again we need to wait next mesa release
before changing ddx to assume by default it is installed with a recent enough
mesa.
No regression, just new test that pass.
Cheers,
From: Jerome Glisse jgli...@redhat.com
v2: Remove left over code
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/radeonsi/r600_texture.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/r600_texture.c
From: Jerome Glisse jgli...@redhat.com
Most test pass, issue are with border color and swizzle.
Based on ircnickmaelcum patch.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/radeonsi/si_state.c | 165 +---
src/gallium/drivers/radeonsi/sid.h
On 04/05/2013 02:25 PM, gregory wrote:
Hello,
Please find an implementation of the ARB_separate_shader_objects extensions. I
concentrate mostly on the state part of
the extensions aka the pipeline object. I think GLSL already compiled program
separately anyway.
I test my implementation on
On Fri, Apr 05, 2013 at 01:17:43PM -0700, Eric Anholt wrote:
This still fails, since 8192*4bpp == 32768, which is too big to use the
blitter on.
v2: Be more conservative about the size of the GTT -- I'd forgotten some
of the horror of older hardware.
Agreed on your other comments, we
Chad Versace chad.vers...@linux.intel.com writes:
When moving the renderbuffer to a new miptree, we neglected to allocate
the hiz buffer for the new miptree. Oops.
Fixes all Piglit depthstencil-render-miplevels tests from crash to pass on
Sandybridge.
Reviewed-by: Eric Anholt
On 5 April 2013 15:28, Chad Versace chad.vers...@linux.intel.com wrote:
When moving the renderbuffer to a new miptree, we neglected to allocate
the hiz buffer for the new miptree. Oops.
Fixes all Piglit depthstencil-render-miplevels tests from crash to pass on
Sandybridge.
CC: Paul Berry
I just cherry picked (almost) all of the marked patches from master that
have been out for two weeks or more. There are a couple that I did not
pick.
c07c180 wayland: fix segfault when using software rendering
49c1fc7 r600g: don't emit SQ_DYN_GPR_RESOURCE_LIMIT_1 on cayman
I couldn't get
On Fri, Apr 5, 2013 at 7:03 PM, Ian Romanick i...@freedesktop.org wrote:
I just cherry picked (almost) all of the marked patches from master that
have been out for two weeks or more. There are a couple that I did not
pick.
With all that out of the way... how does a Mesa 9.1.2 release next
57 matches
Mail list logo
