On 24 October 2011 14:17, Eric Anholt e...@anholt.net wrote:
These produce BRW_NEW_SURFACES (used by binding table emit()) and
BRW_NEW_NR_WM_SURFACES (used by WM unit emit()). Fixes a bug where
with no texturing and no color buffer, we wouldn't consider the null
renderbuffer in nr_surfaces.
On 26 October 2011 11:45, Eric Anholt e...@anholt.net wrote:
On Wed, 26 Oct 2011 10:11:15 -0700, Paul Berry stereotype...@gmail.com
wrote:
Non-text part: multipart/alternative
On 24 October 2011 14:17, Eric Anholt e...@anholt.net wrote:
These produce BRW_NEW_SURFACES (used by binding
On 26 October 2011 12:17, Eric Anholt e...@anholt.net wrote:
On Tue, 25 Oct 2011 20:38:26 -0700, Paul Berry stereotype...@gmail.com
wrote:
This required the following changes:
- WM setup now makes the appropriate set of barycentric coordinates
(perspective vs. noperspective) available
The implementation of ir_binop_nequal in constant_expression_value()
appears to have been copy-and-pasted from the implementation of
ir_binop_equal, but with all instances of '==' changed to '!='. This
is correct except for one minor flaw: one of those '==' operators was
in an assertion checking
In order to implement the GLSL 1.30 isinf() function, it will be
necessary to be able to represent infinity in the GLSL IR s-expression
format. This patch extends the s-expression parser so that it treats
the string #inf as a floating point value representing positive
infinity.
---
The implementations are as follows:
isinf(x) = (abs(x) == +infinity)
isnan(x) = (x != x)
Note: the latter formula is not necessarily obvious. It works because
NaN is the only floating point number that does not equal itself.
Fixes piglit tests isinf-and-isnan fs_basic and isinf-and-isnan
i965 graphics hardware has two floating point modes: ALT and IEEE. In
ALT mode, floating-point operations never generate infinities or NaNs,
and MOV instructions translate infinities and NaNs to finite values.
In IEEE mode, infinities and NaNs behave as specified in the IEEE 754
spec.
This patch adds the extension '.ir' to all the files in
src/glsl/builtins/ir/, and changes generate_builtins.py so that it no
longer globs on '*' to find the files to build. This prevents
spurious files (such as EMACS' infamous *~ backup files) from breaking
the build.
---
On 24 October 2011 14:17, Eric Anholt e...@anholt.net wrote:
This rearranges the code a bit, and makes the upload of the binding
table take only as many surfaces as there are in use.
---
src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 62
+-
1 files changed, 25
@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I don't understand enough of the code to give a reviewed-by, but I've read
through all of it, and other than the comments I've already made, nothing
jumped out at me as a problem.
Acked-by: Paul Berry stereotype...@gmail.com
]? {
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
mesa
On 27 October 2011 10:20, Ian Romanick i...@freedesktop.org wrote:
On 10/26/2011 11:11 AM, Brian Paul wrote:
I think the linker is mis-counting gl_TexCoord[] varying vars when
linking.
For example, if we have this vertex/fragment shader combination:
// vs
void main()
{
gl_Position =
On 27 October 2011 20:13, Kenneth Graunke kenn...@whitecape.org wrote:
On 10/26/2011 06:42 PM, Paul Berry wrote:
In order to implement the GLSL 1.30 isinf() function, it will be
necessary to be able to represent infinity in the GLSL IR s-expression
format. This patch extends the s
This patch ensures that gl_client_array::Integer is properly set to
GL_TRUE for vertex attributes specified using glVertexAttribIPointer,
and to GL_FALSE for vertex attributes specified using
glVertexAttribPointer, so that the vertex attributes can be
interpreted properly by driver back-ends.
---
When a vertex shader input attribute is declared with an integral type
(e.g. ivec4), we need to ensure that the generated vertex shader code
addresses the vertex attribute register using the proper register
type. (Previously, we assumed all vertex shader input attributes were
floating-point).
In
When converting an expression like ++x to GLSL IR we were failing to
account for the possibility that x might be an unsigned integral type.
As a result the user would receive a bogus error message Could not
implicitly convert operands to arithmetic operator.
Fixes piglit tests
On 31 October 2011 23:24, Kenneth Graunke kenn...@whitecape.org wrote:
On 10/31/2011 08:34 PM, Paul Berry wrote:
When converting an expression like ++x to GLSL IR we were failing to
account for the possibility that x might be an unsigned integral type.
As a result the user would receive
i965's MUL instruction can't take an immediate value as its first
argument. So normally, if constant propagation wants to propagate a
constant into the first argument of a MUL instruction, it swaps the
order of the two arguments.
This doesn't work for 32-bit integer (and unsigned integer)
Sorry I missed the first round of feedback on these patches. I hope my
comments aren't coming too late.
On 1 November 2011 12:48, Marek Olšák mar...@gmail.com wrote:
From: Dan McCabe zen3d.li...@gmail.com
Modify the linker to assign additional slots for varying
variables used by transform
On 1 November 2011 12:48, Marek Olšák mar...@gmail.com wrote:
This adds a function that takes an array of varyings from
glTranformFeedbackVaryingsEXT and generates gl_transform_feedback_info,
which is supposed to be consumed by drivers. Useful for ir_to_mesa
and glsl_to_tgsi.
v2:
- changes
for inputs that have user-defined (via
*glBindVertexAttribLocation) locations.
should be updated to mention glBindFragDataLocation.
Other than those nit-picks, this series is:
Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
On 4 November 2011 16:43, Marek Olšák mar...@gmail.com wrote:
Hi Paul,
I won't comment on the patch 1, because I didn't write it, I was just
preserving history.
On Fri, Nov 4, 2011 at 10:00 PM, Paul Berry stereotype...@gmail.com
wrote:
[snip]
+bool parse_tfeedback_decl(const void
This patch modifies the GLSL linker to assign additional slots for
varying variables used by transform feedback, and record the varying
slots used by transform feedback for use by the driver back-end.
This required modifying assign_varying_locations() so that it assigns
a varying location if
On 7 November 2011 17:34, Marek Olšák mar...@gmail.com wrote:
On Tue, Nov 8, 2011 at 1:13 AM, Paul Berry stereotype...@gmail.com
wrote:
+/**
+ * Update gl_transform_feedback_info to reflect this tfeedback_decl.
+ *
+ * If an error occurs, the error is reported through linker_error
This patch modifies the GLSL linker to assign additional slots for
varying variables used by transform feedback, and record the varying
slots used by transform feedback for use by the driver back-end.
This required modifying assign_varying_locations() so that it assigns
a varying location if
On 8 November 2011 05:15, Marek Olšák mar...@gmail.com wrote:
On Tue, Nov 8, 2011 at 7:28 AM, Paul Berry stereotype...@gmail.com
wrote:
This patch modifies the GLSL linker to assign additional slots for
varying variables used by transform feedback, and record the varying
slots used
Commit 1401b96b (radeon: cleanup radeon shared code after r300 and
r600 classic drivers removal) removed the file
src/mesa/drivers/dri/radeon/server/radeon.h, but it left behind the
symlink which was used to share that file into the
src/mesa/drivers/dri/r200/server directory.
This patch removes
);
}
ir_visitor_status
--
1.7.6.4
Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 8 November 2011 12:30, Jose Fonseca jfons...@vmware.com wrote:
At the moment MSVC build's failing with the error
mesa.lib(uniform_query.obj) : error LNK2001: unresolved external symbol
int MESA_VERBOSE (?MESA_VERBOSE@@3HA)
build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll :
(sampler2DShadow sampler, vec3 coord, float lod);
vec4 shadow1DProjLod(sampler1DShadow sampler, vec4 coord, float lod);
--
1.7.7.1
Other than the above comment, this patch is:
Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
On 8 November 2011 14:32, Kenneth Graunke kenn...@whitecape.org wrote:
These were only split for historical reasons: brw_wm_constants used to
be the prepare step, while brw_wm_constant_surface was emit. Now
that both happen at emit time, it makes sense to combine them.
Call the newly
On 31 October 2011 11:59, Ian Romanick i...@freedesktop.org wrote:
On 10/28/2011 02:59 PM, Eric Anholt wrote:
On Fri, 28 Oct 2011 10:42:44 -0700, Ian Romanicki...@freedesktop.org
wrote:
From: Ian Romanickian.d.romanick@intel.**com ian.d.roman...@intel.com
_mesa_ir_link_shader needs to
On 9 November 2011 11:33, Eric Anholt e...@anholt.net wrote:
With the gl_VertexID support, everything required should now be
supported.
---
src/mesa/drivers/dri/intel/intel_extensions.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git
*/
vec4 textureLodOffset( sampler1D sampler, float P, float lod, int offset);
--
1.7.7.2
Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
)
generate_fiu_sigs(txd, 2D, Offset)
generate_fiu_sigs(txd, 3D, Offset)
-generate_fiu_sigs(txd, Cube, Offset)
generate_fiu_sigs(txd, 1DArray, Offset)
generate_fiu_sigs(txd, 2DArray, Offset)
generate_sigs(, txd, 1DShadow, Offset | Single, 1);
--
1.7.7.2
Reviewed-by: Paul Berry stereotype
) {
--
1.7.4.4
Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
,
1,
- BRW_SAMPLER_SIMD_MODE_SIMD16);
+ BRW_SAMPLER_SIMD_MODE_SIMD16,
+ BRW_SAMPLER_RETURN_FORMAT_FLOAT32);
}
--
1.7.7
Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
mesa-dev
);
Minor quibble: I'd prefer to make match_is_exact a pointer, so that in the
caller, it's obvious that the value of match_is_exact is going to be
changed.
In any case, this patch is:
Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
is identical.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Very sensible. Thanks for making this refactoring a separate commit.
Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http
In order to implement transform feedback on Gen6, we need to create a
geometry shader program that will stream out the transformed vertices.
It makes sense to re-use parts of the vec4_visitor infrastructure to
do this, because (a) VS and GS handle data very similarly, (b) it
allows us to take
This patch removes two unused functions from vec4_visitor:
implied_mrf_writes() and emit_bool_comparison(). implied_mrf_writes()
is part of instruction scheduling, which has not been implemented for
vec4_visitor yet. emit_bool_comparison() has never been used.
It also removes two declarations
Previously, reg_allocate() (and reg_allocate_trivial()) stored the
total number of registers allocated (including payload registers) in
vec4_visitor::total_grf. Now, it returns this value to
vec4_visitor::run(), which stores it in total_grf.
This helps pave the way for separating the IR visiting
Previously, vec4_visitor::move_grf_array_access_to_scratch() stored
the value of last_scratch in the brw_vs_compile structure directly.
Now it returns it to vec4_visitor::run(), which stores it.
This helps pave the way for sharing vec4 code between the GS and the
VS, by making
Previously, vec4_visitor::setup_payload() stored the location of the
first non-payload GRF in vec4_visitor::first_non_payload_grf, where it
was later picked up by the register allocator. Now setup_payload()
returns the location to the caller (vec4_visitor::run()), which passes
it directly to the
Previously, vec4_visitor::run() called brw_set_access_mode() right
before calling vec4_visitor::generate_code(). It seems clearer to put
the call inside generate_code(), since the purpose of
brw_set_access_mode() is to set up the proper state for code
generation.
This helps pave the way for
Previously, vec4_visitor::run() was responsible for calling
reg_allocate() right before generate_code(). However, since there is
no reason for run() to do any further manipulation of the instructions
between calling reg_allocate() and generate_code(), it's just as
simple to have generate_code()
Previously, vec4_visitor flagged a failure by setting the failed
boolean and storing a string in fail_msg (which, up until the point
of failure, was undefined). This is redundant--it's just as easy to
have fail_msg be NULL when there is no failure, and a string pointer
when there is a failure.
To determine whether a debug dump should be performed, vec4_visitor
checks the DEBUG_VS bit in INTEL_DEBUG. This patch moves that check
into a single common function, get_debug_flag().
This helps pave the way for sharing code between VS and GS code
generation, by creating a function that can be
This patch moves vec4_visitor::run()'s optimization loop to its own
method.
This helps pave the way for separating the IR visiting parts of
vec4_visitor from the code generation parts, by reducing the number of
function calls between the two parts.
---
src/mesa/drivers/dri/i965/brw_vec4.h
Previously, get_assignment_lhs() was a static function. But it makes
just as much sense to make it a private member functions of
vec4_visitor, because it is one of vec4_visitor's implementation
details, just like the other functions in brw_vec4_visitor.cpp.
This will allow the implementation
This patch separates vec4_visitor into a base class, vec4_generator,
and a derived class, vec4_visitor. vec4_generator is responsible for
code generation, register allocation, and optimization; it is
independent of GLSL IR (with one trivial exception), and mostly
independent of the type of shader
This patch rearranges the class declarations for vec4_generator and
vec4_visitor, and adds private and protected modifiers, to clarify
how the code is organized and how the two classes relate to each
other. There is no functional change.
---
src/mesa/drivers/dri/i965/brw_vec4.h | 310
On 16 November 2011 11:07, Paul Berry stereotype...@gmail.com wrote:
In order to implement transform feedback on Gen6, we need to create a
geometry shader program that will stream out the transformed vertices.
It makes sense to re-use parts of the vec4_visitor infrastructure to
do
This patch series introduces a geometry shader program for i965 Gen6
(Sandy Bridge) that does nothing--it simply passes vertices through to
later stages of the graphics pipeline. This is a preliminary step
towards implementing transform feedback, since on Gen6, transform
feedback is accomplished
This patch adds a new bit to the ctx-NewState bitfield,
_NEW_TRANSFORM_FEEDBACK, to track state changes that affect
ctx-TransformFeedback. This bit can be used by driver back-ends to
avoid expensive recomputations when transform feedback state has not
been modified.
---
src/mesa/main/mtypes.h
Previously, the geometry shader program key was storing all the
information necessary to compute the exact structure of the VUE map
(attrs and userclip_active). However, the GS program doesn't depend
on the exact structure of the VUE map; only on the size (in 256-bit
registers) of the VUE. So we
Previously, GS generation code contained a lookup table that mapped
primitive types POLYGON, TRISTRIP, and TRIFAN to TRILIST, mapped
LINESTRIP to LINELIST, and left all other primitives unchanged. This
was silly, because we never generate a GS program for those primitive
types anyhow.
This patch
Normally when outputting instructions in SPF (single program flow)
mode, we convert IF and ELSE instructions to conditional ADD
instructions applied to the IP register, since this lets us avoid
having to emit an ENDIF instruction (and, in Gen4, lets us avoid using
up precious space in the
The function convert_IF_ELSE_to_ADD() assumes that it doesn't have to
modify the destination and src0 fields of the instruction that it's
modifying, since prior to Gen6, IF and ELSE instructions use the IP
register in these fields.
In Gen6 and later, this is no longer true. Currently this isn't
From: Kenneth Graunke kenn...@whitecape.org
The 50/50 split is just an attempt to get things working. We likely
want to tune this, and probably want to avoid allocating the GS any
space if we're not using it.
For now, this is good enough.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Prior to this patch, in the Gen4 and Gen5 GS, we used GRF 0 (called
R0 in the code) as a staging area to prepare the message header for
the FF_SYNC and URB_WRITE messages. This cleverly avoided an
unnecessary MOV operation (since the initial value of GRF 0 contains
data that needs to be included
R02_PRIM_END and R02_PRIM_START don't actually refer to bits in DWORD
2 of R0 (as the name, and comments in the code, would seem to
indicate). Actually they refer to bits in DWORD 2 of the header for
URB_WRITE messages.
This patch renames the defines to reflect what they actually mean. It
also
In Gen6, transform feedback is accomplished by having the geometry
shader send vertex data to the data port using Streamed Vertex Buffer
Write messages, while simultaneously passing vertices through to the
rest of the graphics pipeline (if rendering is enabled).
This patch adds a geometry shader
On 5 December 2011 11:54, Kenneth Graunke kenn...@whitecape.org wrote:
On 12/05/2011 09:40 AM, Paul Berry wrote:
Normally when outputting instructions in SPF (single program flow)
mode, we convert IF and ELSE instructions to conditional ADD
instructions applied to the IP register, since
On 5 December 2011 14:53, Eric Anholt e...@anholt.net wrote:
On Mon, 5 Dec 2011 09:40:45 -0800, Paul Berry stereotype...@gmail.com
wrote:
Previously, the geometry shader program key was storing all the
information necessary to compute the exact structure of the VUE map
(attrs
On 5 December 2011 18:42, Eric Anholt e...@anholt.net wrote:
On Mon, 5 Dec 2011 15:14:13 -0800, Paul Berry stereotype...@gmail.com
wrote:
On 5 December 2011 14:53, Eric Anholt e...@anholt.net wrote:
On Mon, 5 Dec 2011 09:40:45 -0800, Paul Berry
stereotype...@gmail.com
wrote
On 5 December 2011 14:50, Eric Anholt e...@anholt.net wrote:
These statechanges should probably be flagged using FLUSH_VERTICES(ctx,
_NEW_TRANSFORM_FEEDBACK), since we're about to change something that
would be used by existing glBegin()/glEnd() rendering that is batched up
in the vbo
On 6 December 2011 07:31, Paul Berry stereotype...@gmail.com wrote:
On 5 December 2011 14:50, Eric Anholt e...@anholt.net wrote:
These statechanges should probably be flagged using FLUSH_VERTICES(ctx,
_NEW_TRANSFORM_FEEDBACK), since we're about to change something that
would be used
On 5 December 2011 14:57, Eric Anholt e...@anholt.net wrote:
On Mon, 5 Dec 2011 09:40:50 -0800, Paul Berry stereotype...@gmail.com
wrote:
From: Kenneth Graunke kenn...@whitecape.org
The 50/50 split is just an attempt to get things working. We likely
want to tune this, and probably
On 5 December 2011 15:14, Paul Berry stereotype...@gmail.com wrote:
On 5 December 2011 14:53, Eric Anholt e...@anholt.net wrote:
What I really want is to compute the vue map at the top of the pipeline
and reuse it from the various places that want it.
Yeah, me too. I'll write a follow-up
On 9 November 2011 11:09, Paul Berry stereotype...@gmail.com wrote:
On 31 October 2011 11:59, Ian Romanick i...@freedesktop.org wrote:
On 10/28/2011 02:59 PM, Eric Anholt wrote:
On Fri, 28 Oct 2011 10:42:44 -0700, Ian Romanicki...@freedesktop.org
wrote:
From: Ian Romanickian.d.romanick
On 6 December 2011 11:53, Eric Anholt e...@anholt.net wrote:
On Tue, 6 Dec 2011 08:17:57 -0800, Paul Berry stereotype...@gmail.com
wrote:
On 5 December 2011 14:57, Eric Anholt e...@anholt.net wrote:
On Mon, 5 Dec 2011 09:40:50 -0800, Paul Berry
stereotype...@gmail.com
wrote
On 6 December 2011 11:43, Eric Anholt e...@anholt.net wrote:
On Tue, 6 Dec 2011 09:19:15 -0800, Paul Berry stereotype...@gmail.com
wrote:
On 5 December 2011 15:14, Paul Berry stereotype...@gmail.com wrote:
On 5 December 2011 14:53, Eric Anholt e...@anholt.net wrote:
What I
On 6 December 2011 23:31, Kenneth Graunke kenn...@whitecape.org wrote:
On 12/05/2011 09:40 AM, Paul Berry wrote:
R02_PRIM_END and R02_PRIM_START don't actually refer to bits in DWORD
2 of R0 (as the name, and comments in the code, would seem to
indicate). Actually they refer to bits
On 6 December 2011 23:54, Kenneth Graunke kenn...@whitecape.org wrote:
+ if (intel-gen == 6) {
+ /* On Gen6, GS is used for transform feedback. */
+ key-need_gs_prog = ctx-TransformFeedback.CurrentObject-Active;
+ } else if (intel-gen = 7) {
+ /* On Gen7 and later, we
Ok, I've cleaned up and made changes according to the suggestions made
on the mailing list. I believe all that needs review now is patch 5/8
(Allocate URB space for GS). On Eric's suggestion, I changed this
patch to only allocate URB space for the GS when the GS is actually in
use. The PRM
This patch adds a new bit to the ctx-NewState bitfield,
_NEW_TRANSFORM_FEEDBACK, to track state changes that affect
ctx-TransformFeedback. This bit can be used by driver back-ends to
avoid expensive recomputations when transform feedback state has not
been modified.
Reviewed-by: Kenneth Graunke
Previously, GS generation code contained a lookup table that mapped
primitive types POLYGON, TRISTRIP, and TRIFAN to TRILIST, mapped
LINESTRIP to LINELIST, and left all other primitives unchanged. This
was silly, because we never generate a GS program for those primitive
types anyhow.
This patch
Normally when outputting instructions in SPF (single program flow)
mode, we convert IF and ELSE instructions to conditional ADD
instructions applied to the IP register. On platforms prior to Gen6,
flow control instructions cause an implied thread switch, so this is a
significant savings.
From: Kenneth Graunke kenn...@whitecape.org
We never filled this in before because we didn't care.
I'm skeptical these are correct; my sources indicate that both the VS
and GS # of entries are 256 on both GT1 and GT2.
I'm also loathe to change it and break stuff.
Reviewed-by: Paul Berry
When the GS is not in use, the entire URB space is available for the
VS. When the GS is in use, we split the URB space 50/50.
The 50/50 split is probably not optimal--we'll probably want tune this
for performance in a future patch. For example, in most situations,
it's probably worth allocating
Prior to this patch, in the Gen4 and Gen5 GS, we used GRF 0 (called
R0 in the code) as a staging area to prepare the message header for
the FF_SYNC and URB_WRITE messages. This cleverly avoided an
unnecessary MOV operation (since the initial value of GRF 0 contains
data that needs to be included
R02_PRIM_END and R02_PRIM_START don't actually refer to bits in DWORD
2 of R0 (as the name, and comments in the code, would seem to
indicate). Actually they refer to bits in DWORD 2 of the header for
URB_WRITE messages.
This patch renames the defines to reflect what they actually mean. It
also
On 7 December 2011 13:03, Eric Anholt e...@anholt.net wrote:
On Wed, 7 Dec 2011 11:09:11 -0800, Paul Berry stereotype...@gmail.com
wrote:
- assert(!p-single_program_flow);
+ /* In principle, we shouldn't be patching IF and ELSE instructions in
+* single program flow mode when gen
On 7 December 2011 13:32, Eric Anholt e...@anholt.net wrote:
On Wed, 7 Dec 2011 11:09:16 -0800, Paul Berry stereotype...@gmail.com
wrote:
In Gen6, transform feedback is accomplished by having the geometry
shader send vertex data to the data port using Streamed Vertex Buffer
Write
On 7 December 2011 13:16, Eric Anholt e...@anholt.net wrote:
On Wed, 7 Dec 2011 11:09:12 -0800, Paul Berry stereotype...@gmail.com
wrote:
From: Kenneth Graunke kenn...@whitecape.org
We never filled this in before because we didn't care.
I'm skeptical these are correct; my sources
On 7 December 2011 15:02, Paul Berry stereotype...@gmail.com wrote:
On 7 December 2011 13:16, Eric Anholt e...@anholt.net wrote:
On Wed, 7 Dec 2011 11:09:12 -0800, Paul Berry stereotype...@gmail.com
wrote:
From: Kenneth Graunke kenn...@whitecape.org
We never filled this in before
This patch adds the field gl_transform_feedback_info::BufferStride,
which records the total number of components (per vertex) that
transform feedback is being instructed to store in each buffer. The
i965 gen6 back-end needs this information in order to set up binding
tables, and it seems better
In _mesa_BindBufferRange(), we need to verify that the offset and size
specified by the client do not exceed the size of the underlying
buffer. We were accidentally doing this check using = rather than
, so we were generating a bogus error if the client specified an
offset and size that fit
The Sandy Bridge PRM, volume 4, part 2, section 5.3.10 (5.3.10
Register Region Restrictions) contains the following restriction on
the execution size and operand width of instructions:
3. ExecSize must be equal to or greater than Width.
When emitting an IF instruction in single program flow
This patch stores the geometry shader VUE map from a local variable in
compile_gs_prog() to a field in the brw_gs_compile struct, so that it
will be available while compiling the geometry shader. This is
necessary in order to support transform feedback on Gen6, because the
Gen6 geometry shader
This patch adds basic transform feedback capability for Gen6 hardware.
This consists of several related pieces of functionality:
(1) In gen6_sol.c, we set up binding table entries for use by
transform feedback. We use one binding table entry per transform
feedback varying (this allows us to
This patch advertises support for EXT_transform_feedback on Intel Gen6
and higher.
Since transform feedback support is not completely finished yet, for
now we only advertise support for it when MESA_GL_VERSION_OVERRIDE is
3.0 or greater (since transform feedback is required by GL version
3.0).
Previous to this patch, the function intel_batchbuffer_emit_mi_flush()
was a bit of a misnomer. On Gen4+, when not using the blit engine, it
didn't actually flush the pipeline--it simply generated a
_3DSTATE_PIPE_CONTROL command with the necessary bits set to flush GPU
caches. This was usually
A common use case for transform feedback is to perform one draw
operation that writes transform feedback output to a buffer, followed
by a second draw operation that consumes that buffer as vertex input.
Since vertex input is consumed at an earlier pipeline stage than
writing transform feedback
On 14 December 2011 01:44, Kenneth Graunke kenn...@whitecape.org wrote:
On 12/13/2011 03:35 PM, Paul Berry wrote:
A common use case for transform feedback is to perform one draw
operation that writes transform feedback output to a buffer, followed
by a second draw operation that consumes
A common use case for transform feedback is to perform one draw
operation that writes transform feedback output to a buffer, followed
by a second draw operation that consumes that buffer as vertex input.
Since vertex input is consumed at an earlier pipeline stage than
writing transform feedback
On 14 December 2011 02:33, Kenneth Graunke kenn...@whitecape.org wrote:
On 12/13/2011 03:35 PM, Paul Berry wrote:
The Sandy Bridge PRM, volume 4, part 2, section 5.3.10 (5.3.10
Register Region Restrictions) contains the following restriction on
the execution size and operand width
On 14 December 2011 02:51, Kenneth Graunke kenn...@whitecape.org wrote:
On 12/13/2011 03:35 PM, Paul Berry wrote:
This patch advertises support for EXT_transform_feedback on Intel Gen6
and higher.
Since transform feedback support is not completely finished yet, for
now we only
On 14 December 2011 02:59, Kenneth Graunke kenn...@whitecape.org wrote:
On 12/13/2011 03:35 PM, Paul Berry wrote:
Previous to this patch, the function intel_batchbuffer_emit_mi_flush()
was a bit of a misnomer. On Gen4+, when not using the blit engine, it
didn't actually flush the pipeline
1 - 100 of 2110 matches
Mail list logo
