On Tue, Apr 9, 2013 at 3:18 AM, Marek Olšák mar...@gmail.com wrote:
Pushed, thanks. The transform feedback test still doesn't pass, but at least
the hardlocks are gone.
Thanks, I have looked into the other issue as well
http://lists.freedesktop.org/archives/mesa-dev/2013-March/036941.html
The
On Mon, 2013-04-08 at 13:46 -0400, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
v2: Remove left over code
v3: Restage properly the commit so hunk of first one are not in
second one.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/targets/opencl/Makefile.am | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/targets/opencl/Makefile.am
b/src/gallium/targets/opencl/Makefile.am
Am Dienstag, 9. April 2013, 11:17:39 schrieb Michel Dänzer:
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/targets/opencl/Makefile.am | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
I think the transform feedback code is correct, because all the other TFB
tests pass. If there is an issue, it must be in the shader.
Marek
On Tue, Apr 9, 2013 at 8:58 AM, Martin Andersson g02ma...@gmail.com wrote:
On Tue, Apr 9, 2013 at 3:18 AM, Marek Olšák mar...@gmail.com wrote:
Pushed,
https://bugs.freedesktop.org/show_bug.cgi?id=63117
--- Comment #3 from Kevin Hobbs hob...@ohiou.edu ---
The(In reply to comment #2)
Created attachment 77643 [details] [review]
patch for osmesa.c
I tried the patched mesa with VTK's LoadOpenGLExtension test and the test
passed.
I'm running the
ctx-DrawBuffer-Visual might be invalid if (NewState _NEW_BUFFERS) != 0.
v2: also fix:
- RGBA_INTEGER_MODE_EXT
- RGBA_FLOAT_MODE_ARB (also check API support)
- FRAMEBUFFER_SRGB_CAPABLE_EXT
NOTE: This is a candidate for stable branches.
---
Yes Eric, a few more enums need the same
https://bugs.freedesktop.org/show_bug.cgi?id=63078
--- Comment #1 from post+...@ralfj.de ---
I found the problem: In platform_x11.c, dri2_initialize_x11_dri2, the function
dri2_add_configs_for_visuals (which sets the maximum swap interval of the
EGLConfigs) is called before
https://bugs.freedesktop.org/show_bug.cgi?id=63078
--- Comment #2 from post+...@ralfj.de ---
Created attachment 77661
-- https://bugs.freedesktop.org/attachment.cgi?id=77661action=edit
this patch fixes the issue for me, but I don't know whether it's actually safe
to call
From: Christian König christian.koe...@amd.com
Separated from UVD patch for clarity.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 11 +++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 17 +
On 8 April 2013 19:27, Kenneth Graunke kenn...@whitecape.org wrote:
In the past, we preferred X-tiling for color buffers because our BLT
code couldn't handle Y-tiling. However, the BLT paths have been largely
replaced by BLORP on Gen6+, which can handle any kind of tiling.
We hadn't
gen7_blorp_emit_depth_stencil_config() is only called when
params-depth.mt is non-null. Therefore, it's not necessary to do an
if (params-depth.mt) test inside it. The presence of this if test
was misleading static analysis tools (and briefly, me) into thinking
that
https://bugs.freedesktop.org/show_bug.cgi?id=63117
--- Comment #5 from Brian Paul bri...@vmware.com ---
OK, great. If you find any significant differences between the old swrast and
llvmpipe results, please file another bug.
I'll push the patch today.
--
You are receiving this mail because:
On 8 April 2013 09:15, Eric Anholt e...@anholt.net wrote:
Paul Berry stereotype...@gmail.com writes:
The vec4_visitor functions don't use any VS specific data from
vec4_visitor::vp. So rename it to just p and change its type from
struct gl_vertex_program * to struct gl_program *. This
From: Christian König christian.koe...@amd.com
Drawing subtitles didn't increased the dirty area of the surface.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/vdpau/output.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Hi,
Can you please let me know how to check out the mesa code for UVD
implementation and how to apply the kernel patches
http://people.freedesktop.org/~agd5f/radeon_ucode/?C=N;O=D; to test the UVD
with AMD GPU in Linux.
Regards,
Ramesh
CAUTION - Disclaimer *
Hi list,
first of all, sorry if this is the wrong list for my issue. I tried
various IRC channels, but got no reply, and since I am not actually sure
there is a bug here, I decided to write to a list instead of filing a
bugreport.
My issue is as follows: I wrote a simple GL application which
On 8 April 2013 10:23, Ian Romanick i...@freedesktop.org wrote:
On 04/06/2013 07:20 PM, Paul Berry wrote:
This patch updates the interp[] array to match the enum
glsl_interp_qualifier.
Can we use STATIC_ASSERT to make sure these arrays are at least the
correct size?
Sure, that seems
As some of you may know, the X.Org Foundation was accepted as a GSoC
Project for 2013. If you would be interested in participating as
either a mentor or a student, please sign up here:
http://www.google-melange.com/gsoc/homepage/google/gsoc2013
For students, you can see some potential projects
Ian Romanick i...@freedesktop.org writes:
From: Ian Romanick ian.d.roman...@intel.com
This will eventually replace do_vec_index_to_cond_assign. This lowering
pass is called in all the places where do_vec_index_to_cond_assign or
do_vec_index_to_swizzle is called.
+
+ ir_constant
Ian Romanick i...@freedesktop.org writes:
From: Ian Romanick ian.d.roman...@intel.com
Now ir_dereference_array of a vector will never occur in the RHS of an
expression.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/ast_array_index.cpp | 23 +--
1
On 04/09/2013 06:32 AM, Paul Berry wrote:
gen7_blorp_emit_depth_stencil_config() is only called when
params-depth.mt is non-null. Therefore, it's not necessary to do an
if (params-depth.mt) test inside it. The presence of this if test
was misleading static analysis tools (and briefly, me) into
Ian Romanick i...@freedesktop.org writes:
This series gradually replaces array dereferences of vectors with two
expressions. It takes so many patches because changes are needed to the
existing lowering passes and because several places in the code generate
array dereferences of vectors
Paul Berry stereotype...@gmail.com writes:
On 8 April 2013 09:15, Eric Anholt e...@anholt.net wrote:
Paul Berry stereotype...@gmail.com writes:
The vec4_visitor functions don't use any VS specific data from
vec4_visitor::vp. So rename it to just p and change its type from
struct
From: Christian König christian.koe...@amd.com
Drawing subtitles didn't increased the dirty area of the surface.
v2: don't clear the surface
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/vdpau/output.c |4
1 file changed, 4 insertions(+)
diff
https://bugs.freedesktop.org/show_bug.cgi?id=63078
Chad Versace chad.vers...@linux.intel.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
---
On Tue, Apr 9, 2013 at 2:28 AM, Niels Ole Salscheider
niels_...@salscheider-online.de wrote:
Am Dienstag, 9. April 2013, 11:17:39 schrieb Michel Dänzer:
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/targets/opencl/Makefile.am
On 8 April 2013 09:28, Eric Anholt e...@anholt.net wrote:
Paul Berry stereotype...@gmail.com writes:
-/* Note: brw_vs_prog_data_compare() must be updated when adding fields
to this
- * struct!
+
+/* Note: brw_vec4_prog_data_compare() must be updated when adding
fields to
+ * this
I believe that prog can only be NULL for ARB programs. Neither
brw_fs_fp.cpp nor brw_vec4_vp.cpp call fail(), but not NULL checking
prog is obviously fragile.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 8 +---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 8 +---
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 446b4cf..e129816 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++
On 8 April 2013 09:41, Eric Anholt e...@anholt.net wrote:
Paul Berry stereotype...@gmail.com writes:
This patch moves the following data structures from vec4_visitor to
vec4_vs_visitor, since they contain VS-specific data:
- struct brw_vs_compile *c
- struct brw_vs_prog_data
On 04/09/2013 10:58 AM, Martin Andersson wrote:
On Tue, Apr 9, 2013 at 3:18 AM, Marek Olšák mar...@gmail.com wrote:
Pushed, thanks. The transform feedback test still doesn't pass, but at least
the hardlocks are gone.
Thanks, I have looked into the other issue as well
---
lib/Target/R600/R600ControlFlowFinalizer.cpp | 11 ++-
test/CodeGen/R600/loop-adress.ll | 44
2 files changed, 54 insertions(+), 1 deletion(-)
create mode 100644 test/CodeGen/R600/loop-adress.ll
diff --git
Ralf Jung p...@ralfj.de writes:
Hi list,
first of all, sorry if this is the wrong list for my issue. I tried
various IRC channels, but got no reply, and since I am not actually sure
there is a bug here, I decided to write to a list instead of filing a
bugreport.
My issue is as follows: I
On Tue, Apr 09, 2013 at 11:38:42PM +0200, Vincent Lejeune wrote:
---
Reviewed-by: Tom Stellard thomas.stell...@amd.com
lib/Target/R600/R600ControlFlowFinalizer.cpp | 11 ++-
test/CodeGen/R600/loop-adress.ll | 44
2 files changed, 54
Changes since v1:
- Consistently use the variable name shader_prog to refer to struct
gl_shader_program and prog to refer to struct gl_program.
- Move urb_read_length and urb_entry_size into brw_vec4_prog_data so
that they can be re-used by geometry shaders.
- When vec4_vs_visitor has a
The next patch is going to change the type of vec4_visitor::vp from
struct gl_vertex_program * to struct gl_program *, and rename it. The
sensible name to change it to is vec4_visitor::prog. However, prog is
already used in backend_visitor (which vec4_visitor derives from).
Since
The vec4_visitor functions don't use any VS specific data from
vec4_visitor::vp. So rename it to prog and change its type from
struct gl_vertex_program * to struct gl_program *. This will allow
the code to be re-used for geometry shaders.
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
This patch modifies the arguments to brw_compute_vue_map() so that
they no longer bake in the assumption that we are generating a VUE map
for vertex shader outputs. It also makes the function non-static so
that we can re-use it for geometry shader outputs.
Reviewed-by: Jordan Justen
In patches that follow, we'll be splitting structs brw_vs_prog_data
and brw_vs_compile into a vec4-generic base struct and a VS-specific
derived struct (this will allow the vec4-generic code to be re-used
for geometry shaders). Having brw_vs_compile point to
brw_vs_prog_data makes it difficult to
This will allow the generic parts to be re-used for geometry shaders.
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 8
src/mesa/drivers/dri/i965/brw_vs.c
This will allow the generic parts to be re-used for geometry shaders.
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 16 -
src/mesa/drivers/dri/i965/brw_vs.c |
This will allow the generic parts to be re-used for geometry shaders.
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
v2: Put urb_read_length and urb_entry_size in the generic struct.
---
src/mesa/drivers/dri/i965/brw_context.h| 29 +++---
This patch just creates the derived class; later patches will migrate
VS-specific functions and data structures from the base class into the
derived class.
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Eric Anholt e...@anholt.net
---
src/mesa/drivers/dri/i965/brw_vec4.cpp
This patch makes the following vec4_visitor functions virtual, since
they will need to be implemented differently for vertex and geometry
shaders. Some of the functions are renamed to reflect their generic
purpose, rather than their VS-specific behaviour:
- setup_attributes
-
The system values handled by vec4_visitor::visit(ir_variable *) are
VS-specific (vertex ID and instance ID). This patch moves the
handling of those values into a new virtual function,
make_reg_for_system_value(), so that this VS-specific code won't be
inherited by geomtry shaders.
Reviewed-by:
This patch moves functions from vec4_visitor to vec4_vs_visitor that
deal with ARB (assembly) vertex programs. There's no point in having
these functions in the base class since we don't intend to support
assembly programs for the GS stage. The following functions are
moved:
- setup_vp_regs
-
The next patch is going to change the type of vec4_generator::vp from
struct gl_vertex_program * to struct gl_program *, and rename it. The
sensible name to change it to is vec4_generator::prog. However, prog
is already used. Since the existing vec4_generator::prog is of type
struct
This patch removes the following field from vec4_generator, since it
is not used:
- struct brw_vs_compile *c
And changes the following field:
- struct gl_vertex_program *vp = struct gl_program *prog
With these changes, vec4_generator no longer refers to any VS-specific
data structures. This
Since this function is going to get used for geometry shaders too, it
deserves a more generic name: generate_vec4_instruction.
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_vec4.h| 6 +++---
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 8
This patch introduces a new function, vec4_visitor::emit_vertex(),
which contains the code for emitting vertices that will need to be
common between the vertex and geometry shaders.
Geometry shaders will need to use a different message header, and a
different opcode, for their URB writes, so we
On 04/09/2013 10:49 AM, Eric Anholt wrote:
Ian Romanick i...@freedesktop.org writes:
This series gradually replaces array dereferences of vectors with two
expressions. It takes so many patches because changes are needed to the
existing lowering passes and because several places in the code
This patch introduces a new function,
vec4_visitor::lower_attributes_to_hw_regs(), which replaces registers
of type ATTR in the instruction stream with the hardware registers
that store those attributes. This logic will need to be common
between the vertex and geometry shaders.
Reviewed-by:
Geometry shader inputs are arrays, but they use an unusual array
layout: instead of all array elements for a given geometry shader
input being stored consecutively, all geometry shader inputs are
interleaved into one giant array. As a result, the array stride we
use to access geometry shader
Since the vec4_visitor and vec4_generator classes are going to be
re-used for geometry shaders, we can't enable their debug
functionality based on (INTEL_DEBUG DEBUG_VS) anymore. Instead, add
a debug_flag boolean to these two classes, so that when they're
instantiated the caller can specify
From: Chad Versace chad.vers...@linux.intel.com
On Haswell, HiZ will selectively be enabled on individual miptree slices
to workaround a hardware bug. The two new functions below will permit us
to detect if hiz is enabled for a particular slice.
intel_miptree_slice_has_hiz
(I'm sending this out for Chad, whose email doesn't appear to be working.)
Enable hiz by setting intel_context::has_hiz. However, to work around
a hardware bug, we selectively enable hiz for only nicely aligned miptree
slices.
No Piglit regressions on Haswell 0x0d26 rev07 when based atop
From: Chad Versace chad.vers...@linux.intel.com
The hardware docs and the simulator require that the rectangle primitive
emitted during fast depth clears and hiz resolves must be aligned to 8x4
pixels.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
From: Chad Versace chad.vers...@linux.intel.com
When allocating the hiz miptree, we mark each slice as needing a hiz
ambiguate. This patch updates the initial marking to mark only slices for
which hiz is enabled.
No behavioral change is introduced, because currently hiz is always
enabled for all
From: Chad Versace chad.vers...@linux.intel.com
The new fields define the 2D miptree slice to be used. A following patch
will pass the new fields through to intel_miptree_slice_has_hiz().
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/i965/brw_blorp.cpp | 4
From: Chad Versace chad.vers...@linux.intel.com
Add new parameters `depth_level` and `depth_layer`, which specify depth
miptree's slice of interest. A following patch will pass the new
parameters through to intel_miptree_slice_has_hiz().
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
From: Chad Versace chad.vers...@linux.intel.com
When appropriate, replace each check `hiz_mt != NULL` with either a call
to intel_miptree_slice_has_hiz() or intel_renderbuffer_has_hiz(). No
behavioral change.
This prepares for selectively enabling hiz on individual miptree slices
for Haswell.
From: Chad Versace chad.vers...@linux.intel.com
After recent refactorings, the field is written but no longer read.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/i965/brw_context.h| 1 -
src/mesa/drivers/dri/i965/brw_misc_state.c | 2 --
2 files changed,
From: Chad Versace chad.vers...@linux.intel.com
Enable hiz by setting intel_context::has_hiz. However, to work around
a hardware bug, we selectively enable hiz for only nicely aligned miptree
slices.
No Piglit regressions on Haswell 0x0d26 rev07 when based atop
mesa-master-97e40a5.
Improves
Matt Turner matts...@gmail.com writes:
I believe that prog can only be NULL for ARB programs. Neither
brw_fs_fp.cpp nor brw_vec4_vp.cpp call fail(), but not NULL checking
prog is obviously fragile.
(shader != NULL) = (prog != NULL), so if you want consistency I'd
rather see the if (shader)
Kenneth Graunke kenn...@whitecape.org writes:
From: Chad Versace chad.vers...@linux.intel.com
The hardware docs and the simulator require that the rectangle primitive
emitted during fast depth clears and hiz resolves must be aligned to 8x4
pixels.
Signed-off-by: Chad Versace
Kenneth Graunke kenn...@whitecape.org writes:
From: Chad Versace chad.vers...@linux.intel.com
On Haswell, HiZ will selectively be enabled on individual miptree slices
to workaround a hardware bug. The two new functions below will permit us
to detect if hiz is enabled for a particular slice.
On Tue, Apr 9, 2013 at 3:55 PM, Eric Anholt e...@anholt.net wrote:
Matt Turner matts...@gmail.com writes:
I believe that prog can only be NULL for ARB programs. Neither
brw_fs_fp.cpp nor brw_vec4_vp.cpp call fail(), but not NULL checking
prog is obviously fragile.
(shader != NULL) = (prog
On 04/09/2013 10:29 AM, Eric Anholt wrote:
Ian Romanick i...@freedesktop.org writes:
From: Ian Romanick ian.d.roman...@intel.com
This will eventually replace do_vec_index_to_cond_assign. This lowering
pass is called in all the places where do_vec_index_to_cond_assign or
On 04/09/2013 10:38 AM, Eric Anholt wrote:
Ian Romanick i...@freedesktop.org writes:
From: Ian Romanick ian.d.roman...@intel.com
Now ir_dereference_array of a vector will never occur in the RHS of an
expression.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
Kenneth Graunke kenn...@whitecape.org writes:
From: Chad Versace chad.vers...@linux.intel.com
Enable hiz by setting intel_context::has_hiz. However, to work around
a hardware bug, we selectively enable hiz for only nicely aligned miptree
slices.
No Piglit regressions on Haswell 0x0d26
Marek Olšák mar...@gmail.com writes:
ctx-DrawBuffer-Visual might be invalid if (NewState _NEW_BUFFERS) != 0.
v2: also fix:
- RGBA_INTEGER_MODE_EXT
- RGBA_FLOAT_MODE_ARB (also check API support)
- FRAMEBUFFER_SRGB_CAPABLE_EXT
NOTE: This is a candidate for stable branches.
On 04/09/2013 10:49 AM, Eric Anholt wrote:
Ian Romanick i...@freedesktop.org writes:
This series gradually replaces array dereferences of vectors with two
expressions. It takes so many patches because changes are needed to the
existing lowering passes and because several places in the code
Hi Vadim,
your patch does not fix the test.
Marek
On Tue, Apr 9, 2013 at 11:30 PM, Vadim Girlin vadimgir...@gmail.com wrote:
On 04/09/2013 10:58 AM, Martin Andersson wrote:
On Tue, Apr 9, 2013 at 3:18 AM, Marek Olšák mar...@gmail.com wrote:
Pushed, thanks. The transform feedback test
From: Ian Romanick ian.d.roman...@intel.com
Fixes issue identified by Klocwork analysis:
Pointer 'field_type' returned from call to function 'glsl_type' at
line 4126 may be NULL and may be dereferenced at line 4139. Also
there are 2 similar errors on line(s) 4165, 4174.
In
From: Ian Romanick ian.d.roman...@intel.com
Ensure that process_array_type never returns NULL, and let
process_array_type handle the case where the supplied base type is NULL.
Fixes issues identified by Klocwork analysis:
Pointer 'type' returned from call to function 'get_type' at line
From: Ian Romanick ian.d.roman...@intel.com
Duh.
Fixes issues identified by Klocwork analysis:
Pointer 'table' returned from call to function 'calloc' at line 115
may be NULL and will be dereferenced at line 117.
and
Suspicious dereference of pointer 'table' before NULL check at
From: Ian Romanick ian.d.roman...@intel.com
dri2_create_surface can fail for a variety of reasons, including bad
input data. Dereferencing the NULL pointer and crashing is not okay.
Fixes issue identified by Klocwork analysis:
Pointer 'surf' returned from call to function
We want to both make sure we never divide by zero to not generate
sigfpe and that divide by zero is guaranteed to return 0x.
Based on José idea.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c | 29 +---
1 file changed,
We were missing the implementation of PIPE_QUERY_SO_STATISTICS
query, this change implements it on top of the existing
facilities.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/drivers/llvmpipe/lp_query.c | 19 +++
src/gallium/drivers/llvmpipe/lp_rast.c |3 +++
We were using simple temporaries, without using alloca or phi
nodes which meant that on every iteration of the loop our
temporaries holding the numbers of vertices and primitives
which were emitted were being reset to zero. Now we're using
alloca to allocate of those variables to preserve them
both mov and ucmp can be used to move variables of any type.
correctly note that about ucmp in the tgsi_info and make
sure gallivm can handle that by correctly casting the untyped
moves.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |8
https://bugs.freedesktop.org/show_bug.cgi?id=63117
Brian Paul bri...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Am 10.04.2013 02:22, schrieb Zack Rusin:
We want to both make sure we never divide by zero to not generate
sigfpe and that divide by zero is guaranteed to return 0x.
Based on José idea.
Signed-off-by: Zack Rusin za...@vmware.com
---
Am 10.04.2013 02:22, schrieb Zack Rusin:
We were missing the implementation of PIPE_QUERY_SO_STATISTICS
query, this change implements it on top of the existing
facilities.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/drivers/llvmpipe/lp_query.c | 19 +++
Am 10.04.2013 02:22, schrieb Zack Rusin:
We were using simple temporaries, without using alloca or phi
nodes which meant that on every iteration of the loop our
temporaries holding the numbers of vertices and primitives
which were emitted were being reset to zero. Now we're using
alloca to
Am 10.04.2013 02:22, schrieb Zack Rusin:
both mov and ucmp can be used to move variables of any type.
correctly note that about ucmp in the tgsi_info and make
sure gallivm can handle that by correctly casting the untyped
moves.
Signed-off-by: Zack Rusin za...@vmware.com
---
On 04/09/2013 04:03 PM, Eric Anholt wrote:
Kenneth Graunke kenn...@whitecape.org writes:
From: Chad Versace chad.vers...@linux.intel.com
On Haswell, HiZ will selectively be enabled on individual miptree slices
to workaround a hardware bug. The two new functions below will permit us
to detect
On 04/09/2013 04:59 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Fixes issue identified by Klocwork analysis:
Pointer 'field_type' returned from call to function 'glsl_type' at
line 4126 may be NULL and may be dereferenced at line 4139. Also
there are 2
On 04/09/2013 03:51 PM, Kenneth Graunke wrote:
From: Chad Versace chad.vers...@linux.intel.com
The hardware docs and the simulator require that the rectangle primitive
emitted during fast depth clears and hiz resolves must be aligned to 8x4
pixels.
Signed-off-by: Chad Versace
On 04/09/2013 03:55 PM, Eric Anholt wrote:
Matt Turner matts...@gmail.com writes:
I believe that prog can only be NULL for ARB programs. Neither
brw_fs_fp.cpp nor brw_vec4_vp.cpp call fail(), but not NULL checking
prog is obviously fragile.
(shader != NULL) = (prog != NULL), so if you want
The comment above glsl_type::name claimed that it could sometimes be
NULL. This was wrong--it is never NULL. Many error handling paths
would segfault if it were.
Fix the comment and add assertions to validate that it really is never
NULL.
---
src/glsl/glsl_types.cpp | 4
Hi Christian,
I working with MESA and want to test the UVD implementation in MESA and trying
to check-out the code for UVD implementation as said in following site and did
not find the code in mesa tree. Can you please guide me how to check-out the
code for UVD radeon/uvd: add UVD
On 04/09/2013 04:15 PM, Eric Anholt wrote:
Kenneth Graunke kenn...@whitecape.org writes:
From: Chad Versace chad.vers...@linux.intel.com
Enable hiz by setting intel_context::has_hiz. However, to work around
a hardware bug, we selectively enable hiz for only nicely aligned miptree
slices.
No
94 matches
Mail list logo
