Previously, builtin_variables.cpp was written assuming that we
supported ARB_geometry_shader4 style geometry shader inputs, meaning
that each built-in varying input to a geometry was supplied via an
array variable whose name ended in "In", e.g. gl_PositionIn or
gl_PointSizeIn.
However, in GLSL 1.5
interface block
(gl_in[vertex].gl_ClipDistance[clip_plane]).
v2 (Paul Berry ): Fix indexing order for
gl_ClipDistance input lowering. Properly lower bulk assignment of
gl_ClipDistance inputs. Rework for GLSL 1.50 style geometry shaders.
---
src/glsl/lower_clip_distance.cpp | 223
gl_PointSize is stored in the w component of VARYING_SLOT_PSIZ, but
the geometry shader infrastructure assumes that it should look for all
geometry shader inputs of type float in the x component. So when
compiling a geomtery shader that uses a gl_PointSize input, fix it up
during the shader prolog
As part of its support for geometry shaders, GL 3.2 introduces four
new primitive types: GL_LINES_ADJACENCY, GL_LINE_STRIP_ADJACENCY,
GL_TRIANGLES_ADJACENCY, and GL_TRIANGLE_STRIP_ADJACENCY.
---
src/mesa/drivers/dri/i965/brw_context.h | 2 +-
src/mesa/drivers/dri/i965/brw_draw.c| 8 ++--
2
When we previously implemented primitive restart, we didn't add cases
to brw_primitive_restart.c's can_cut_index_handle_prims() for the
primitive types that are introduced with geometry shaders. It turns
out that all of the new primitive types are supported by hardware
primitive restart.
---
src/
On 15 September 2013 21:16, Kenneth Graunke wrote:
> On 09/03/2013 04:18 PM, Paul Berry wrote:
> > Since the SF/SBE stage is only capable of performing arbitrary
> > reorderings of 16 varying slots, we can't arrange the fragment shader
> > inputs in an arbitrary order
(CC'ing Mesa-dev since this is a Mesa bug).
On 16 September 2013 11:00, Chad Versace wrote:
> CC'ing Piglit.
>
>
> On 09/14/2013 08:54 AM, Paul Berry wrote:
>
>> I'm investigating a failure in spec/OES_fixed_point/**attribute-arrays,
>> specifically t
On 13 September 2013 11:25, Kenneth Graunke wrote:
> We now set the ARB_shader_bit_encoding flag for versions that support
> this functionality, so we don't need to double check it here.
>
> Signed-off-by: Kenneth Graunke
> Cc: Ian Romanick
> ---
> src/glsl/builtin_functions.cpp | 3 +--
> 1 f
On 13 September 2013 23:10, Kenneth Graunke wrote:
> This was an embarassingly large amount of copy and pasted code,
> and it wasn't particularly simple code either. By factoring it out
> into a helper function, we consolidate the complexity.
>
> Signed-off-by: Kenneth Graunke
>
I really like
On 13 September 2013 16:05, Kenneth Graunke wrote:
> Now we use gen7_upload_constant_state() for all three shader stages.
>
> Signed-off-by: Kenneth Graunke
> Cc: Paul Berry
>
Series is:
Reviewed-by: Paul Berry
___
mesa-dev mailin
t of drm_intel_bo_emit_reloc(), but the code you're removing
passed I915_GEM_DOMAIN_RENDER. Is this a problem?
> -
> - gen7_check_surface_setup(surf, true /* is_render_target */);
> + gen7_emit_image_surface_state(brw,
> +
On 16 September 2013 09:38, Eric Anholt wrote:
> Kenneth Graunke writes:
>
> > This was an embarassingly large amount of copy and pasted code,
> > and it wasn't particularly simple code either. By factoring it out
> > into a helper function, we consolidate the complexity.
> >
> > Signed-off-by:
On 13 September 2013 23:10, Kenneth Graunke wrote:
> Specifying a miptree layout makes no sense for constant buffers.
>
You might want to mention in the commit message that there's no functional
change since BRW_SURFACE_MIPMAPLAYOUT_BELOW == 0.
In any case, the patch is:
Review
with buffer_size that I mentioned in patch 1
applies to this patch too.
With that fixed, the patch is:
Reviewed-by: Paul Berry
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 98
> +---
> 1 file chan
On 17 September 2013 05:13, Rogovin, Kevin wrote:
> Hello,
>
> Thank you for the very fast answers, some more questions:
>
>
> > It's not a preference question. The registers are 8 floats wide.
> > Vertex shaders get invoked 2 vertices at a time, with a register
> containing these values:
> >
>
2. I'd
prefer to see each commit message stand on its own, since commits often
wind up getting cherry-picked into alternate orders, or viewed in
isolation, so it won't always be obvious to the reader what "ditto" means.
With that fixed, the patch is:
Reviewed-by: Paul B
On 15 September 2013 00:10, Francisco Jerez wrote:
> This patch introduces a pair of helper functions providing a common
> implementation of the "new" and "delete" operators for all C++ classes
> that are allocated by ralloc via placement new. The 'ralloc_new'
> helper function takes care of set
On 15 September 2013 00:10, Francisco Jerez wrote:
> ---
> src/glsl/ast_to_hir.cpp | 1 +
> src/glsl/builtin_type_macros.h | 2 ++
> src/glsl/builtin_types.cpp | 6 ++
> src/glsl/glsl_types.cpp | 2 ++
> src/glsl/g
On 17 September 2013 12:18, Paul Berry wrote:
> On 15 September 2013 00:10, Francisco Jerez wrote:
>
>>
>> /**
>> +* Return the amount of atomic counter storage required for a type.
>> +*/
>> + unsigned atomic_size() const
>> + {
>&g
On 15 September 2013 00:10, Francisco Jerez wrote:
> Add a subclass of ir_rvalue that represents an atomic operation on
> some ir_variable. Also define a new IR visitor method, and implement
> IR builder, printer and reader support for it.
>
I don't think this approach is going to be reliable.
On 15 September 2013 00:10, Francisco Jerez wrote:
> ---
> src/glsl/ast.h| 15 ++
> src/glsl/ast_to_hir.cpp | 68
> +--
> src/glsl/ast_type.cpp | 13 +++--
> src/glsl/glsl_lexer.ll| 2 +-
> src/glsl/glsl_p
On 15 September 2013 00:10, Francisco Jerez wrote:
> And fix the dead code elimination pass so atomic writes aren't
> optimized out in cases where the return value isn't used by the
> program.
>
As I mentioned in my comments on patch 9, I'd prefer if we went with a
different approach where we do
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
I'm halfway through the series and I'm out of time for code review today.
I sent comments on patches 3, 4, 8, 9, 10, and 12. Patches 1, 2, 5, 7, and
11 are:
Reviewed-by: Paul Berry
Patch 6 deserves the attention of s
On 18 September 2013 07:43, Ian Romanick wrote:
> On 09/15/2013 02:10 AM, Francisco Jerez wrote:
> > The _mesa_glsl_parse_state object relies on the memory allocator
> > zeroing out its contents before it's initialized, which seems rather
> > risky. One of the following commits will homogenize i
On 18 September 2013 13:04, Ian Romanick wrote:
> On 09/13/2013 01:45 PM, Paul Berry wrote:
> > On 11 September 2013 16:28, Ian Romanick > <mailto:i...@freedesktop.org>> wrote:
> > Another question which we haven't really addressed is how Mesa's front
>
On 18 September 2013 13:15, Ian Romanick wrote:
> On 09/18/2013 01:35 PM, Paul Berry wrote:
> > On 18 September 2013 07:43, Ian Romanick > <mailto:i...@freedesktop.org>> wrote:
> >
> > On 09/15/2013 02:10 AM, Francisco Jerez wrote:
> > > The _
On 19 September 2013 00:54, Rogovin, Kevin wrote:
> Hello all,
>
> ** **
>
> I thank all those that have answered my questions, I still have a few
> more. Here goes.
>
> ** **
>
> I saw that geometry shaders were landed recently in some form. My
> questions are:
>
> **· **W
t; + const unsigned max_atomic_buffers[MESA_SHADER_TYPES] = {
> + ctx->Const.VertexProgram.MaxAtomicBuffers,
> + ctx->Const.GeometryProgram.MaxAtomicBuffers,
> + ctx->Const.FragmentProgram.MaxAtomicBuffers
> + };
> + active_atomic_buffers_t abs = find_ac
gt; + bo,
> + offset,
> + BRW_SURFACEFORMAT_RAW,
> + size - 1,
>
Note: if you land this patch after Ken's "
comments in the .emit functions showing where it
refers to GL state, so that it's clear why each of the dirty bits is
needed. So above this line there should be the comment "/* _NEW_PROGRAM
*/".
Similar comments apply to brw_upload_{vs,wm}_abo_surfaces().
> +
> + if (prog)
> + b
On 17 September 2013 19:54, Chia-I Wu wrote:
> Hi Paul,
>
> On Mon, Sep 16, 2013 at 3:46 PM, Chia-I Wu wrote:
> > On Sat, Sep 14, 2013 at 5:15 AM, Paul Berry
> wrote:
> >> On 12 September 2013 22:06, Chia-I Wu wrote:
> >>>
> >>> From: Chia-I
Previously, we computed dFdy() using the following instruction:
add(8) dst<1>F src<4,4,0)F -src.2<4,4,0>F { align1 1Q }
That had the disadvantage that it computed the same value for all 4
pixels of a 2x2 subspan, which meant that it was less accurate than
dFdx(). This patch changes it to the f
On 21 September 2013 09:03, Kenneth Graunke wrote:
> On 09/21/2013 07:59 AM, Brian Paul wrote:
> > On Fri, Sep 20, 2013 at 7:52 PM, Eric Anholt wrote:
> >> Since it's only used for debug information, we can misalign the struct
> and
> >> save the disk space. Another 19k on a 64-bit build.
> >>
On 25 September 2013 10:18, Chad Versace wrote:
> On 07/22/2013 03:54 PM, Frank Henigman wrote:> Extend the fast texture
> upload from BGRA X-tiled to include RGBA,
> > diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
> b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
> > index 05e684c.
uld be nice to have a comment somewhere in the else block explaining
that on IVB, SIMD4x2 atomic operations aren't available, so we implement
them using SIMD8 messages, and we rely on the shader compiler to set the
execution mask accordingly.
With that comment added, this patch is:
Reviewed-by: Paul B
On 15 September 2013 00:10, Francisco Jerez wrote:
> Analogous to the GLSL IR predicate with the same name. This patch
> fixes the three dead code elimination passes and the VEC4/FS
> instruction scheduling passes so they leave instructions with side
> effects alone.
>
> At some point it might b
On 15 September 2013 00:19, Francisco Jerez wrote:
> This can deal with all the 15 32-bit untyped atomic operations the
> hardware supports, but only INC and PREDEC are going to be exposed
> through the API for now.
> ---
> src/mesa/drivers/dri/i965/brw_fs.h | 7 +++
> src/mesa/driver
On 15 September 2013 00:19, Francisco Jerez wrote:
> This can deal with all the 15 32-bit untyped atomic operations the
> hardware supports, but only INC and PREDEC are going to be exposed
> through the API for now.
> ---
> src/mesa/drivers/dri/i965/brw_vec4.h | 7 +++
> src/mesa/driv
2, 5, 7, 11, 17, 20, 23, and 24) are:
Reviewed-by: Paul Berry
However, there are two things which I expected to see in this patch series
but I didn't:
- Do atomic_uints need similar handling to ir_sampler_replacement_visitor
in opt_function_inlining?
- Do we need to update schedule_node::s
In a future patch, this will allow us to enforce invariants when the
interface type is updated.
---
src/glsl/ast_to_hir.cpp| 4 ++--
src/glsl/ir.h | 15 +++
src/glsl/link_interface_blocks.cpp | 17 +
Although it's not explicitly stated in the GLSL 1.50 spec, it is
clearly implied that unsized arrays are allowed in interface blocks
(the built-in interface gl_PerVertex contains an unsized array,
gl_ClipDistance, and examples added in GLSL 4.30 make use of unsized
arrays in interface blocks).
>Fr
Although it's not explicitly stated in the GLSL 1.50 spec, unsized
arrays are allowed in interface blocks.
section 1.2.3 (Changes from revision 5 of version 1.5) of the GLSL
1.50 spec says:
* Completed full update to grammar section. Tested spec examples
against it:
...
*
Future patches in this series will add calls to _mesa_glsl_error() to
ir.cpp. _mesa_glsl_error() calls _mesa_glsl_msg(), which calls
_mesa_shader_debug(), which is defined in mesa/main/errors.c (and
hence not available when compiling GLSL unit tests). To avoid link
errors, link uniform-initialize
Currently, when converting an access to an array element from ast to
IR, we need to see if the array is an ir_dereference_variable, and if
so update the variable's max_array_access.
When we add support for unsized arrays in interface blocks, we'll also
need to account for cases where the array is
For interface blocks that contain arrays, this field will contain the
maximum element of each contained array that is accessed by the
shader. This is a first step toward supporting unsized arrays in
interface blocks.
---
src/glsl/ir.cpp | 3 ++-
src/glsl/ir.h | 17 +
This patch adds an implementation of
ir_dereference_record::update_max_array_access(), which ensures that
ir_variable::max_ifc_array_access is properly updated to reflect the
shader's use of arrays appearing within interface blocks.
---
src/glsl/ir.cpp | 36
sr
---
src/glsl/ir_validate.cpp | 20
1 file changed, 20 insertions(+)
diff --git a/src/glsl/ir_validate.cpp b/src/glsl/ir_validate.cpp
index 2c64f4e..93bc4d9 100644
--- a/src/glsl/ir_validate.cpp
+++ b/src/glsl/ir_validate.cpp
@@ -674,6 +674,26 @@ ir_validate::visit(ir_variable
Unsized arrays appearing inside named interface blocks now get a
proper size assigned by the array_sizing_visitor.
Fixes piglit tests:
- spec/glsl-1.50/execution/unsized-in-named-interface-block
- spec/glsl-1.50/execution/unsized-in-named-interface-block-gs
- spec/glsl-1.50/linker/unsized-in-named
When multiple shaders of the same type access an interface block
containing an unsized array, we need to set the array size based on
the maximum array element accessed across all the shaders. This is
similar to what we already do with unsized arrays occurring outside of
interface blocks.
Note: on
We were already setting the array size of unsized arrays that appeared
inside unnamed interface blocks, but we weren't updating
ir_variable::interface_type to reflect the new array size, causing
bogus link errors.
This patch causes array_sizing_visitor to keep track of all the
unnamed interface ty
>From the bspec documentation of the SEND instruction:
"destination region cannot cross the 256-bit register boundary."
To avoid violating this restriction when executing SIMD16 texturing
operations (such as those used by blorp), we need to ensure that the
destination of the SEND instruction
>From GLSL ES 3.00 section 4.5.4 ("Default Precision Qualifiers"):
"The precision statement
precision precision-qualifier type;
can be used to establish a default precision qualifier. The type
field can be either int or float or any of the sampler types, and
the precision
On 13 February 2013 21:11, Eric Anholt wrote:
> Kenneth Graunke writes:
>
> > On 02/13/2013 06:31 PM, Eric Anholt wrote:
> >> Kenneth Graunke writes:
> >>
> >>> Meta-instructions that implicitly write then read/consume a MRF value
> >>> don't pose write-after-write conflicts with each other, si
le
> will still contain the optimized out varyings.)
>
> Signed-off-by: Jordan Justen
> Cc: Paul Berry
>
Reviewed-by: Paul Berry
(sorry it took me so long to get to this)
> ---
> src/glsl/link_varyings.cpp | 19 ++-
> 1 file changed, 18 insertions(+),
>From the Ivy Bridge PRM, p268 (3DSTATE_SBE), in the description of
"Point Sprite Texture Coordinate Enable":
"This field must be programmed to 0 when non-point primitives are
rendered."
A similar admonishment exists in the Sandy Bridge PRM.
Although I'm not aware of any known bugs due t
Pre-Gen6, the SF thread requires exact matching between VS output
slots (aka VUE slots) and FS input slots, even when the corresponding
VS output slot is unused due to being overwritten by point coordinate
replacement (glTexEnvi(GL_POINT_SPRITE, GL_COORD_REPLACE, GL_TRUE)).
As a result, we have a s
On 15 February 2013 23:16, Eric Anholt wrote:
> christopher.halse.rog...@canonical.com writes:
>
> > From: Christopher James Halse Rogers
> >
> > _mesa_delete_renderbuffer does not call the driver-specific
> > renderbuffer delete function, so the blorp code was leaking the
> > Intel-specific bit
brw_vs_prog_data::userclip hasn't been used since commit f0cecd4
(i965: Move VUE map computation to once at VS compile time).
brw_gs_prog_key::userclip_active hasn't been used since commit 9f3d321
(i965: Make the userclip flag for the VUE map come from VS prog data).
---
src/mesa/drivers/dri/i965
On 16 February 2013 10:58, Brian Paul wrote:
> This fixes a regression from ab74fee5e1a3fc3323b7238278637b232c2d0d95.
> When we use the clip coordinate to compute the screen-space interpolation
> factor, we need to first apply the divide-by-zero step to the clip
> coordinate.
>
I think you mean
On 16 February 2013 13:52, Kenneth Graunke wrote:
> On 02/16/2013 07:29 AM, Paul Berry wrote:
>
>> From the Ivy Bridge PRM, p268 (3DSTATE_SBE), in the description of
>> "Point Sprite Texture Coordinate Enable":
>>
>> "This field must be
ther
>> than looking in the FS symbol table. (The FS symbol table
>> will still contain the optimized out varyings.)
>>
>> Signed-off-by: Jordan Justen
>> Cc: Paul Berry
>>
>
> Is this a candidate for 9.1?
Since the spec doesn't require us to optim
On 20 February 2013 12:25, Eric Anholt wrote:
> Matt Turner writes:
>
> > From: Kenneth Graunke
> >
> > Previously, we had separate constructors for one, two, and four operand
> > expressions. This patch consolidates them into a single constructor
> > which uses NULL default parameters.
> >
>
On 16 February 2013 15:16, Paul Berry wrote:
> On 16 February 2013 13:52, Kenneth Graunke wrote:
>
>> On 02/16/2013 07:29 AM, Paul Berry wrote:
>>
>>> From the Ivy Bridge PRM, p268 (3DSTATE_SBE), in the description of
>>> "Point Sprite Texture Coordina
On 22 February 2013 08:02, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Use LDS for calculating the deltas between neighbouring pixels. Not sure
> the
> sign of the delta is correct for both dimensions (the sign doesn't seem to
> matter for the relevant piglit tests), but it'll be easy to fix
On 26 February 2013 01:47, Madan Mohan Chinnam wrote:
> Hi,
>
> I am trying to use "normalize" method at fragment test shader in my Open
> GL es2 application.
>
> precision mediump float;
> varying vec4 color;
>
> void main (void)
> {
> vec4 tmp_Color = color + vec4(0.25);
> gl_FragColor =
On 26 February 2013 02:10, Chris Forbes wrote:
> This series adds the core mesa bits for ARB_texture_multisample, and
> support
> in the i965 driver for Gen6 and Gen7.
>
> I've addressed the issues that were raised for V3, and also fixed some
> other
> bugs which I found while beefing up the pigl
On 1 March 2013 02:02, Aras Pranckevicius wrote:
> Hi,
>
> opt_constant_variable was marking a variable as constant as long as there
> was exactly one constant assignment to it, but did not take into account
> that this assignment might be in a dynamic branch or a loop.
>
> Was happening on a fra
On 1 March 2013 15:14, Ian Romanick wrote:
> Since last September I've been gradually working on an extension to let
> applications query information about the renderer before (and after)
> creating a context. I've talked it over with a few ISVs and with various
> other folks. I also gathered s
On 5 March 2013 15:56, Matt Turner wrote:
> Replaces (samples - 1) ADDs and a MUL with (samples - 1) LRPs.
> ---
> src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 31
> +++--
> 1 files changed, 14 insertions(+), 17 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_
On 3 March 2013 00:44, Aras Pranckevicius wrote:
> >> opt_constant_variable was marking a variable as constant as long as
> there was
> >> exactly one constant assignment to it, but did not take into account
> that this
> >> assignment might be in a dynamic branch or a loop.
> >> Was happening on
On 7 March 2013 14:15, Anuj Phogat wrote:
> Framebuffer blitting operation should be skipped if any of the
> dimensions (width/height) of src/dst rect are zero.
>
> Fixes: fbblit(negative.nullblit.zeroSize) in Intel oglconform
> https://bugs.freedesktop.org/show_bug.cgi?id=59495
>
> Note: Candida
Fast depth clears have the same depth/stencil alignment requirements
as other drawing operations. Therefore, we need to call
brw_workaround_depthstencil_alignment() from both the clear and
drawing paths.
Without this fix, we get image corruption if the following conditions
hold: (a) the first eve
Since apps typically begin rendering with a call to glClear(), it is
likely that when brw_workaround_depthstencil_alignment() moves a
miplevel to a temporary buffer, it can avoid doing a blit, since the
contents of the miplevel are about to be erased.
This patch adds the necessary plumbing to dete
This patch series combines the enums gl_vert_result, gl_geom_attrib,
gl_geom_result, and gl_frag_attrib into a single enum.
These four enums serve very similar purposes: they all identify data
that flows through the pipeline from vertex shader to fragment shader,
but their definitions don't match.
This patch updates the bitfields brw_context::wm.input_size_masks,
tracker::size_masks, and brw_wm_prog_key::proj_attrib_mask, all of
which are indexed by gl_frag_attrib, from 32-bit to 64-bit.
This paves the way for supporting geometry shaders, and for merging
the gl_frag_attrib and gl_vert_resul
Future patches will make use of the enum. It will eventually take the
place of the existing enums gl_vert_result, gl_geom_attrib,
gl_geom_result, and gl_frag_attrib, all of which represent essentially
the same information but using inconsistent values.
---
src/mesa/main/mtypes.h | 70
This paves the way for eliminating the gl_vert_result enum entirely.
---
src/mesa/main/mtypes.h| 67 +--
src/mesa/program/prog_print.c | 4 +++
2 files changed, 43 insertions(+), 28 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/m
This patch makes the following search-and-replace changes:
gl_vert_result -> gl_varying_slot
VERT_RESULT_* -> VARYING_SLOT_*
--
Note: this patch is very large, so for purposes of mailing list
discussion I've trimmed it down to representative example hunks. To
see the complete patch, please refer
This paves the way for eliminating the gl_geom_attrib enum entirely.
---
src/mesa/main/mtypes.h | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 1e62e19..b39c9c5 100644
--- a/src/mesa/main/mtypes.
This patch makes the following search-and-replace changes:
gl_geom_attrib -> gl_varying_slot
GEOM_ATTRIB_* -> VARYING_SLOT_*
GEOM_BIT_* -> VARYING_BIT_*
---
src/mesa/main/context.c | 2 --
src/mesa/main/mtypes.h | 41 -
src/mesa/progra
This paves the way for eliminating the gl_geom_result enum entirely.
---
src/mesa/main/mtypes.h | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index c01d584..d760d21 100644
--- a/src/me
This patch makes the following search-and-replace changes:
gl_geom_result -> gl_varying_slot
GEOM_RESULT_* -> VARYING_SLOT_*
---
src/mesa/main/context.c| 2 --
src/mesa/main/mtypes.h | 28 --
src/mesa/program/program.c |
This paves the way for eliminating the gl_frag_attrib enum entirely.
---
src/mesa/main/mtypes.h| 45 ++-
src/mesa/program/prog_print.c | 15 +++
2 files changed, 34 insertions(+), 26 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src
Now that there is no difference between the enums that represent
vertex outputs and fragment inputs, there's no need for a conversion
function. But we still need to be able to detect when a given vertex
output has no corresponding fragment input. So it is replaced by a
new function, _mesa_varying
Now that there is no difference between the enums that represent
vertex outputs and fragment inputs, there's no need for a conversion
function.
---
src/mesa/drivers/dri/i965/gen6_sf_state.c | 15 +++
src/mesa/main/mtypes.h| 26 +-
2 files cha
This patch makes the following search-and-replace changes:
gl_frag_attrib -> gl_varying_slot
FRAG_ATTRIB_* -> VARYING_SLOT_*
FRAG_BIT_* -> VARYING_BIT_*
--
Note: this patch is very large, so for purposes of mailing list
discussion I've trimmed it down to representative example hunks. To
see the
On 12 March 2013 12:28, Eric Anholt wrote:
> Paul Berry writes:
>
> > Fast depth clears have the same depth/stencil alignment requirements
> > as other drawing operations. Therefore, we need to call
> > brw_workaround_depthstencil_alignment() from both the cle
On 12 March 2013 22:23, Kenneth Graunke wrote:
> On 03/11/2013 03:51 PM, Paul Berry wrote:
>
>> This patch updates the bitfields brw_context::wm.input_size_**masks,
>> tracker::size_masks, and brw_wm_prog_key::proj_attrib_**mask, all of
>> which are indexed by gl_frag_a
On 12 March 2013 12:53, Paul Berry wrote:
> On 12 March 2013 12:28, Eric Anholt wrote:
>
>> Paul Berry writes:
>>
>> > Fast depth clears have the same depth/stencil alignment requirements
>> > as other drawing operations. Therefore, we need to call
>&g
On 12 March 2013 16:33, Eric Anholt wrote:
> Paul Berry writes:
> > void
> > -brw_workaround_depthstencil_alignment(struct brw_context *brw)
> > +brw_workaround_depthstencil_alignment(struct brw_context *brw,
> > +
On 12 March 2013 19:29, Eric Anholt wrote:
> Paul Berry writes:
>
> > Now that there is no difference between the enums that represent
> > vertex outputs and fragment inputs, there's no need for a conversion
> > function. But we still need to be able to detect w
The only format returned by _mesa_get_format_base_format() that
satisfies _mesa_is_depthstencil_format() is GL_DEPTH_STENCIL, so we
can simplify the check.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/in
Since apps typically begin rendering with a call to glClear(), it is
likely that when brw_workaround_depthstencil_alignment() moves a
miplevel to a temporary buffer, it can avoid doing a blit, since the
contents of the miplevel are about to be erased.
This patch adds the necessary plumbing to dete
Previously, right after calling _mesa_glsl_link_shader(), the fixed
function fragment shader code made several calls with the ostensible
purpose of setting up uniforms for the fragment shader it just
created.
These calls are unnecessary, since _mesa_glsl_link_shader() calls
driver->LinkShader(), w
Previous to this patch, when using fixed function fragment shading,
bit VARYING_BIT_POS of brw_wm_prog_key::proj_attrib_mask was being set
differently during precompiles and normal usage. During precompiles
it was being set only if the fragment shader reads from window
position (which it never doe
On 14 March 2013 12:38, Eric Anholt wrote:
> Paul Berry writes:
>
> > On 12 March 2013 16:33, Eric Anholt wrote:
> >
> >> Paul Berry writes:
> >> > void
> >> > -brw_workaround_depthstencil_alignment(struct brw_context *brw)
> >>
Since apps typically begin rendering with a call to glClear(), it is
likely that when brw_workaround_depthstencil_alignment() moves a
miplevel to a temporary buffer, it can avoid doing a blit, since the
contents of the miplevel are about to be erased.
This patch adds the necessary plumbing to dete
This debug flag prints out the native GEN assembly for a blitting
shader produced using BLORP. Hopefully this should be useful in
developing additional BLORP features.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 6 ++
src/mesa/drivers/dri/intel/intel_context.c | 1 +
src/mesa/drivers
Normally when submitting the first batch buffer after a flush, we
check whether the GPU has completed processing of the first batch
buffer of the previous frame. If it hasn't, we wait for it to finish
before submitting any more batches. This prevents GPU-heavy and
CPU-light applications from raci
On 19 March 2013 17:10, Eric Anholt wrote:
> Paul Berry writes:
>
> > Normally when submitting the first batch buffer after a flush, we
> > check whether the GPU has completed processing of the first batch
> > buffer of the previous frame. If it hasn't, we wai
601 - 700 of 2245 matches
Mail list logo
