On 04/10/2013 03:58 AM, Marek Olšák wrote:
Hi Vadim,
your patch does not fix the test.
Hmm, I'm out of ideas then. Thanks for testing.
I've checked the shader dump few times but I don't see anything
obviously wrong there, and the same code (except the minor ALU grouping
changes due to the V
On 04/09/2013 10:49 PM, Chad Versace wrote:
On 04/09/2013 04:15 PM, Eric Anholt wrote:
Kenneth Graunke writes:
From: Chad Versace
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 Pigl
On 04/09/2013 04:15 PM, Eric Anholt wrote:
Kenneth Graunke writes:
From: Chad Versace
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 b
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 implementati
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
src/glsl/glsl_type
On 04/09/2013 03:55 PM, Eric Anholt wrote:
Matt Turner 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
ra
On 04/09/2013 03:51 PM, Kenneth Graunke wrote:
From: Chad Versace
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
---
src/mesa/drivers/dri/i965/brw_blorp.cpp
On 04/09/2013 04:59 PM, Ian Romanick wrote:
From: Ian Romanick
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)
On 04/09/2013 04:03 PM, Eric Anholt wrote:
Kenneth Graunke writes:
From: Chad Versace
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.
inte
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
> ---
> src/gallium/auxiliary/
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 t
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
> ---
> src/gallium/drivers/llvmpipe/lp_query.c | 19 +++
> src/galliu
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
> ---
> src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c | 29
https://bugs.freedesktop.org/show_bug.cgi?id=63117
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |8
src/gallium/au
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 acro
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
---
src/gallium/drivers/llvmpipe/lp_query.c | 19 +++
src/gallium/drivers/llvmpipe/lp_rast.c |3 +++
2 files changed
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
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c | 29 +---
1 file changed, 25 insertions(+),
From: Ian Romanick
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 'dri2_create_surface'
at line 285 may
From: Ian Romanick
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 line
119.
Signed-off-
From: Ian Romanick
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
1907 may be NULL and may
From: Ian Romanick
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 practice, it should be impossible
Hi Vadim,
your patch does not fix the test.
Marek
On Tue, Apr 9, 2013 at 11:30 PM, Vadim Girlin wrote:
> On 04/09/2013 10:58 AM, Martin Andersson wrote:
>
>> On Tue, Apr 9, 2013 at 3:18 AM, Marek Olšák wrote:
>>
>>> Pushed, thanks. The transform feedback test still doesn't pass, but at
>>> l
On 04/09/2013 10:49 AM, Eric Anholt wrote:
Ian Romanick 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 derefere
Marek Olšák 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.
Reviewed
Kenneth Graunke writes:
> From: Chad Versace
>
> 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.
>
On 04/09/2013 10:38 AM, Eric Anholt wrote:
Ian Romanick writes:
From: Ian Romanick
Now ir_dereference_array of a vector will never occur in the RHS of an
expression.
Signed-off-by: Ian Romanick
---
src/glsl/ast_array_index.cpp | 23 +--
1 file changed, 17 insertions(
On 04/09/2013 10:29 AM, Eric Anholt wrote:
Ian Romanick writes:
From: Ian Romanick
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 *const
On Tue, Apr 9, 2013 at 3:55 PM, Eric Anholt wrote:
> Matt Turner 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 wan
Kenneth Graunke writes:
> From: Chad Versace
>
> 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
> intel_r
Kenneth Graunke writes:
> From: Chad Versace
>
> 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
> ---
> src/mesa/drivers/dri/i965/brw_blorp.cpp | 29 ++
Matt Turner 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) changed to if (p
From: Chad Versace
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 the performance of GLB27_TRex_C
From: Chad Versace
After recent refactorings, the field is written but no longer read.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_context.h| 1 -
src/mesa/drivers/dri/i965/brw_misc_state.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/br
From: Chad Versace
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.
This refactoring had several
From: Chad Versace
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
---
src/mesa/drivers/dri/i965/brw_context.h| 2 ++
s
From: Chad Versace
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
---
src/mesa/drivers/dri/i965/brw_blorp.cpp | 4
src/mesa/drivers/dri/i965/brw_blorp.h | 11 +++
From: Chad Versace
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 slices. However, that will c
From: Chad Versace
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
---
src/mesa/drivers/dri/i965/brw_blorp.cpp | 29 +
1 file change
(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
mesa-ma
From: Chad Versace
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
intel_renderbuffer_has_hiz
The functions are n
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 whet
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 input
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: Jorda
On 04/09/2013 10:49 AM, Eric Anholt wrote:
Ian Romanick 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 derefere
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 in
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
---
src/mesa/drivers/dri/i965/brw_vec4.h| 6 +++---
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 8
2 files changed, 7 inser
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 w
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 gl_shader_pr
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 (renamed to vs_compile)
- struct brw_vs_prog_data *prog_data (renamed to vs_prog_data)
- src_reg *vp_temp_regs
- src_reg vp_addr_reg
Since brw_vs_co
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
- ge
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: Jo
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
- emit_attribute_fixup
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
Reviewed-by: Eric Anholt
---
src/mesa/drivers/dri/i965/brw_vec4.cpp| 2 +-
src/mesa/drivers
This will allow the generic parts to be re-used for geometry shaders.
Reviewed-by: Jordan Justen
v2: Put urb_read_length and urb_entry_size in the generic struct.
---
src/mesa/drivers/dri/i965/brw_context.h| 29 +++---
src/mesa/drivers/dri/i965/brw_curbe.c | 6 +-
This will allow the generic parts to be re-used for geometry shaders.
Reviewed-by: Jordan Justen
---
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 | 47 +---
This will allow the generic parts to be re-used for geometry shaders.
Reviewed-by: Jordan Justen
---
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 | 4 ++--
src/mes
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 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
Reviewed-by:
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
v2: Use the name "prog" ra
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 backend_visitor:
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
On Tue, Apr 09, 2013 at 11:38:42PM +0200, Vincent Lejeune wrote:
> ---
Reviewed-by: Tom Stellard
> lib/Target/R600/R600ControlFlowFinalizer.cpp | 11 ++-
> test/CodeGen/R600/loop-adress.ll | 44
>
> 2 files changed, 54 insertions(+), 1 deletion(-)
>
Ralf Jung 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 wrote
---
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 a/lib/Target/R600/R600ControlFlowFinalize
On 04/09/2013 10:58 AM, Martin Andersson wrote:
On Tue, Apr 9, 2013 at 3:18 AM, Marek Olšák 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
On 8 April 2013 09:41, Eric Anholt wrote:
> Paul Berry 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 *prog_data
> > - src_reg *vp_temp_re
---
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
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cp
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
On 8 April 2013 09:28, Eric Anholt wrote:
> Paul Berry 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 struct!
> > */
> > -struct
On Tue, Apr 9, 2013 at 2:28 AM, Niels Ole Salscheider
wrote:
> Am Dienstag, 9. April 2013, 11:17:39 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>>
>> Signed-off-by: Michel Dänzer
>> ---
>> src/gallium/targets/opencl/Makefile.am | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>
https://bugs.freedesktop.org/show_bug.cgi?id=63078
Chad Versace changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Chad Versace
From: Christian König
Drawing subtitles didn't increased the dirty area of the surface.
v2: don't clear the surface
Signed-off-by: Christian König
---
src/gallium/state_trackers/vdpau/output.c |4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/state_trackers/vdpau/output.c
Paul Berry writes:
> On 8 April 2013 09:15, Eric Anholt wrote:
>
>> Paul Berry 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 w
Ian Romanick 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 (e.g., lowering access
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) i
Ian Romanick writes:
> From: Ian Romanick
>
> Now ir_dereference_array of a vector will never occur in the RHS of an
> expression.
>
> Signed-off-by: Ian Romanick
> ---
> src/glsl/ast_array_index.cpp | 23 +--
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --gi
Ian Romanick writes:
> From: Ian Romanick
>
> 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 *const cmp_indices =
> + new(facto
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 id
On 8 April 2013 10:23, Ian Romanick 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 reasonable.
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 make
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
From: Christian König
Drawing subtitles didn't increased the dirty area of the surface.
Signed-off-by: Christian König
---
src/gallium/state_trackers/vdpau/output.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/g
On 8 April 2013 09:15, Eric Anholt wrote:
> Paul Berry 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 will allow
> > the code to be
https://bugs.freedesktop.org/show_bug.cgi?id=63117
--- Comment #5 from Brian Paul ---
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:
You are the assigne
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 gen7_blorp_emit_depth_sten
On 8 April 2013 19:27, Kenneth Graunke 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 measured any performance
From: Christian König
Separated from UVD patch for clarity.
Signed-off-by: Christian König
---
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 11 +++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 17 +
src/gallium/winsys/radeon/drm/radeon_winsys.h |
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=77661&action=edit
this patch fixes the issue for me, but I don't know whether it's actually safe
to call dri2_setup_swap_interv
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 dri2_setup_swap_interva
https://bugs.freedesktop.org/show_bug.cgi?id=63117
--- Comment #4 from Kevin Hobbs ---
The patched OSMesa allows VTK to pass most tests.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists
"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=63117
--- Comment #3 from Kevin Hobbs ---
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 rest of VTK's
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 wrote:
> On Tue, Apr 9, 2013 at 3:18 AM, Marek Olšák wrote:
> > Pushed, thanks. The transform feedback t
Am Dienstag, 9. April 2013, 11:17:39 schrieb Michel Dänzer:
> From: Michel Dänzer
>
>
> Signed-off-by: Michel Dänzer
> ---
> 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/galli
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
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
index 389eecc..810f9bb 100644
--- a/src/gallium/t
On Mon, 2013-04-08 at 13:46 -0400, j.gli...@gmail.com wrote:
> From: Jerome Glisse
>
> 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
> ---
> src/gallium/drivers/radeonsi/r600_texture.c | 11 ++--
>
97 matches
Mail list logo
