So far we have been using CL_INVOCATION_COUNT to resolve this query but this
is no good with streams, as only stream 0 reaches the clipping stage. Instead
we will use SO_PRIM_STORAGE_NEEDED which can keep track of the primitives sent
to each individual stream.
Since SO_PRIM_STORAGE_NEEDED is
Hello,
while testing various scenarios for multi-stream support in geometry
shaders I came across one that I think might be a hardware bug, or at
the very least, a hardware limitation that creates a problem to
implement correct behavior according to ARB_transform_feedback3.
The conflictive
On 06/25/2014 06:38 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
The last_level from the sampler view may be limited by the state tracker
to a value lower than what the base texture provides.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=80541.
---
Tom Stellard thomas.stell...@amd.com writes:
From: Matt Arsenault arse...@gmail.com
If there were only warnings, they would not be added to the log.
Also fixes valgrind use after free errors.
This last comment is somewhat misleading now, as this doesn't fix any
valgrind errors anymore.
Tom Stellard thomas.stell...@amd.com writes:
From: Matt Arsenault arse...@gmail.com
v2:
-Fix indentation
---
src/gallium/state_trackers/clover/api/device.cpp | 11 +--
src/gallium/state_trackers/clover/core/device.cpp | 24
+++
Tom Stellard thomas.stell...@amd.com writes:
v2:
- Report correct values for CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE and
CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE.
- Only define cl_khr_fp64 if the extension is supported.
- Remove trailing space from extension string.
- Rename device
https://bugs.freedesktop.org/show_bug.cgi?id=80541
Roland Scheidegger srol...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=80561
Priority: medium
Bug ID: 80561
Assignee: mesa-dev@lists.freedesktop.org
Summary: Incorrect implementation of some VDPAU APIs.
Severity: normal
Classification: Unclassified
... as it's caller (the external program omxregister-bellagio) is the one
who frees all of the allocated memory.
Cc: Pedretti Fabio pedretti.fa...@gmail.com
Reported-by: Pedretti Fabio pedretti.fa...@gmail.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
On Sun, Jun 22, 2014 at 1:49 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
All of the bits appear to already be in place to support this in the
sampler (which the original AMD version didn't allow).
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
I'm probably missing some reason why this
On Thursday, June 26, 2014 12:53:11 PM Ilia Mirkin wrote:
On Sun, Jun 22, 2014 at 1:49 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
All of the bits appear to already be in place to support this in the
sampler (which the original AMD version didn't allow).
Signed-off-by: Ilia Mirkin
Here is my go at implementing the EGL_KHR_create_context extension for the
gallium state tracker. I'm new to Mesa development, so excuse me if I have
forgotten something.
This brings the EGL_KHR_create_context extension to the gallium egl state
tracker. It is requried to create Core profile
---
src/gallium/state_trackers/egl/common/egl_g3d.c | 1 +
src/gallium/state_trackers/egl/common/egl_g3d_api.c | 8
2 files changed, 9 insertions(+)
diff --git a/src/gallium/state_trackers/egl/common/egl_g3d.c
b/src/gallium/state_trackers/egl/common/egl_g3d.c
index d3f5e92..22b5e4a
On Thu, Jun 26, 2014 at 1:08 PM, Knut Andre Tidemann
knut.tidem...@gmail.com wrote:
---
src/gallium/state_trackers/egl/common/egl_g3d.c | 1 +
src/gallium/state_trackers/egl/common/egl_g3d_api.c | 8
2 files changed, 9 insertions(+)
diff --git
On 06/26/2014 07:25 PM, Ilia Mirkin wrote:
On Thu, Jun 26, 2014 at 1:08 PM, Knut Andre Tidemann
knut.tidem...@gmail.com wrote:
---
src/gallium/state_trackers/egl/common/egl_g3d.c | 1 +
src/gallium/state_trackers/egl/common/egl_g3d_api.c | 8
2 files changed, 9 insertions(+)
On Thu, Jun 26, 2014 at 1:31 PM, Knut Andre Tidemann
knut.tidem...@gmail.com wrote:
On 06/26/2014 07:25 PM, Ilia Mirkin wrote:
On Thu, Jun 26, 2014 at 1:08 PM, Knut Andre Tidemann
knut.tidem...@gmail.com wrote:
---
src/gallium/state_trackers/egl/common/egl_g3d.c | 1 +
On 06/26/2014 07:32 PM, Ilia Mirkin wrote:
On Thu, Jun 26, 2014 at 1:31 PM, Knut Andre Tidemann
knut.tidem...@gmail.com wrote:
On 06/26/2014 07:25 PM, Ilia Mirkin wrote:
On Thu, Jun 26, 2014 at 1:08 PM, Knut Andre Tidemann
knut.tidem...@gmail.com wrote:
---
On Thursday, June 26, 2014 07:31:20 PM Knut Andre Tidemann wrote:
On 06/26/2014 07:25 PM, Ilia Mirkin wrote:
On Thu, Jun 26, 2014 at 1:08 PM, Knut Andre Tidemann
knut.tidem...@gmail.com wrote:
---
src/gallium/state_trackers/egl/common/egl_g3d.c | 1 +
On Wed, Jun 25, 2014 at 12:05 PM, Jon Ashburn j...@lunarg.com wrote:
Existing texture read into PBO was using GPU Blit engine in which src and
dest formats must match. With commit 61e264f4fcdba, internally stored
texture
formats were no longer swizzled (BGRA instead of RGBA). This caused
On Wednesday, June 25, 2014 02:42:24 PM Gregory Hunt wrote:
From: Greg Hunt greg.h...@mobica.com
These cause a small slowdown when we are sending a large number of small
batches to the GPU. Removing these improves performance by upto 5% on some CPU
bound SynMark tests (Batch[4-7], DrvState1,
v2: fix style and wrong major version comparison.
---
src/gallium/state_trackers/egl/common/egl_g3d.c | 1 +
src/gallium/state_trackers/egl/common/egl_g3d_api.c | 8
2 files changed, 9 insertions(+)
diff --git a/src/gallium/state_trackers/egl/common/egl_g3d.c
As an alternative -- we know if we have this scenario at link time --
could we perhaps just not do anything in EmitStreamVertex if there are
no varyings captured to that stream?
On Thu, Jun 26, 2014 at 10:26 PM, Iago Toral ito...@igalia.com wrote:
Hello,
while testing various scenarios for
The preprocessor defines a notions of a preprocessing number that
starts with either a digit or a decimal point, and continues with zero
or more of digits, decimal points, identifier characters, or the sign
symbols, ('-' and '+').
Prior to this change, preprocessing numbers were lexed as some
Here's my latest series of patches to improve conformance of glcpp, (the glsl
preprocessor in mesa).
Most of these changes are fixes that only a test-suite author could love. Most
fix nit-picky tests that do things that no sance application would actually
do. They're all reasonable things to do,
The recent adddition of an error for #define followed by a non-identifier
was a bit to aggressive since it used a regular expression in the lexer to
flag any character that's not legal as the first character of an identifier.
But we need to allow comments to appear here, (since we aren't removing
Now that we have a common macro for returning tokens, it makes sense to
perform some of the common work there, (such as copying string values).
---
src/glsl/glcpp/glcpp-lex.l | 41 ++---
1 file changed, 18 insertions(+), 23 deletions(-)
diff --git
It's legal (though highly bizarre) for a pre-processor directive to look like
this:
# /* why? */ define FOO bar
This behavior comes about since the specification defines separate logical
phases in a precise order, and comment-removal occurs in a phase before the
identification of
The glcpp implementation has long had code to support a file that ends without
a final newline. But we didn't have a make check test for this.
Additionally, the EOF action was restricted only to the INITIAL state so
it would fail to get invoked if the EOF was encountered in the COMMENT or
the
Here, skipping refers to the lexer not emitting any tokens for portions of
the file within an #if condition (or similar) that evaluates to false.
Previously, the lexer had a special SKIP start condition used to control
this skipping. This start condition was not handled like a normal start
This is in preparation for the planned addition of a new HASH start
condition to the lexer. Both start conditions and token types are, of course,
in the same default C namespace, so a start condition and a token type with
the same name will collide. (And unfortunately, they are both apparently
Previously, if the preprocessor encountered a #define with a non-identifier,
such as:
#define 123 456
The lexer had no explicit rules to match non-identifiers in the DEFINE start
state. Because of this, flex's default rule was being invoked, (printing
characters to stdout), and all text
The NEWLINE_CATCHUP code is only intended to be invoked after we lex an actual
newline character ('\n'). The two extra calls here were apparently added
accidentally because the pattern happened to contain a (negated) '\n'.
I don't think either case could have caused any actual bug. (In the first
The verbose debug output from the parser is quite useful when debugging, and
having this available as a command-line option is much more convenient than
manually forcing this into the code when needed, (which is what I had been
doing for too long previously).
---
src/glsl/glcpp/glcpp-parse.y | 2
This is to avoid the default, silent flex rule which simply prints the
character to stdout.
---
src/glsl/glsl_lexer.ll | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll
index db7b1d1..1cadf1f 100644
--- a/src/glsl/glsl_lexer.ll
+++
It makes more sense to print the directive name with the preceding '#'.
---
src/glsl/glcpp/glcpp-parse.y| 2 +-
src/glsl/glcpp/tests/077-else-without-if.c.expected | 2 +-
src/glsl/glcpp/tests/078-elif-without-if.c.expected | 2 +-
3 files changed, 3 insertions(+), 3
The glcpp parser is line-based, so it needs to see a NEWLINE token at the end
of each line. This causes a trick for files that end without a final newline.
Previously, the lexer for glcpp punted in this case by unconditionally
returning a NEWLINE token at end-of-file, (causing most files to have
At one point while rewriting the lexing rule for pre-processing numbers, I
made it a bit too aggressive and within a replacement list sucked up a
parameter name that appeared immediately after a period. This caused the
parameter name to be unreplaced when the macro was expanded.
It was in some
This test is written to exercise a bug which I recently wrote, (but
fortunately caught and fixed before ever committing it).
For the curious:
The bug happened when the NEWLINE_CATCHUP code didn't actually return the
NEWLINE token (due to the skipping). This resulted in the lexer continuing
These operators aren't defined for preprocessor expressions, so we never
implemented them. This led them to be misinterpreted as strings of unary
'+' or '-' operators.
In fact, what is actually desired is to generate an error if these operators
appear in any preprocessor condition.
So this
From: Kenneth Graunke kenn...@whitecape.org
Without this, in the PP state, we would hit Flex's default rule, which
prints tokens to stdout, rather than returning them as tokens. (Or, after the
previous commit, we would hit the new catch-all rule and generate an internal
compiler error.)
With
This will emit an error for something like:
#define FOO(x,x) ...
Obviously, it's not a legal thing to do, and it's easy to check.
Add a make check test for this as well.
This fixes the following Khronos GLES3 CTS tests:
invalid_function_definitions.unique_param_name_vertex
Previously, the '\r' character was not explicitly matched by any rule. With
the recent addition of the catch-all rule for unrecognized characters, this
means glcpp would generate an internal-compiler error for any occurrence of
'\r' in a shader source string.
Prior to the internal error, glcpp
For the first line we were initializing the column to 1, but for all
subsequent lines we were initializing the column to 0. The column number is
advanced for each token read before any error message is printed. So the 0
value is the correct initialization, (so that the first column is reported as
In some of the recent glcpp bug-fixing, we found that glcpp was emitting
unrecognized characters from the input source file to stdout, and dropping
them from the source passed onto the compiler proper.
This was obviously confusing, and totally undesired.
The bogus behavior comes from an implicit
This commit does not cause any behavioral change for any valid program. Prior
to entering the DEFINE start condition, the only valid start condition is
INITIAL, so whether pushing/popping DEFINE onto the stack or explicit
returning to INITIAL is equivalent.
The reason for this change is that we
Previously, we had a single token for #if but now that we have two separate
tokens, it looks much better to see:
HASH_TOKEN IF
than:
HASH_TOKEN HASH_IF
(Note, that HASH_TOKEN instead of HASH, we also use DEFINE_TOKEN instead of
DEFINE to avoid a conflict with the DEFINE start
Just reading the code, it looked like a bug that _define_object_macro had this
check, but _define_function_macro did not. Upon further reading, that's
because the check is to allow for our builtins to be defined, (and there are
no builtin function-like macros).
Add my new understanding as a
Right now, the Intel driver is the only driver in mesa that implements this
extension. Is anyone using this? Is it ok if we purge it? I'm doing some
work on the texture format code and DUDV8 is an ugly special case.
Thanks,
--Jason Ekstrand
___
On 06/26/2014 05:30 PM, Jason Ekstrand wrote:
Right now, the Intel driver is the only driver in mesa that implements
Also as far as we can tell... it's the only driver that implements it.
git-blame says that VMware added it a long time ago... before there
was any support for SNORM textures.
This just drops all the GL types from the xmlconfig and use
std C types from stdint and stdbool.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/drivers/dri/common/xmlconfig.c | 176
src/mesa/drivers/dri/common/xmlconfig.h | 20 ++--
2 files changed,
This in theory changes ABI for the boolean-bool I think,
but nothing in the tree uses configQueryb AFAICS.
Signed-off-by: Dave Airlie airl...@redhat.com
---
include/GL/internal/dri_interface.h| 7 ---
src/mesa/drivers/dri/common/dri_util.c | 6 +++---
2 files changed, 7 insertions(+), 6
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/state_tracker/st_cb_queryobj.c| 2 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 10 +++---
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_queryobj.c
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
src/gallium/drivers/i915/i915_screen.c | 1 +
src/gallium/drivers/ilo/ilo_screen.c | 1 +
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/auxiliary/hud/hud_driver_query.c | 6 +++---
src/gallium/drivers/freedreno/freedreno_query.c | 2 +-
src/gallium/drivers/galahad/glhd_context.c | 6 --
src/gallium/drivers/i915/i915_query.c|
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/trace/tr_dump_state.c | 1 +
src/gallium/include/pipe/p_state.h | 1 +
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 1 +
3 files changed, 3 insertions(+)
diff --git a/src/gallium/drivers/trace/tr_dump_state.c
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_program.h | 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_query.c| 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +-
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/auxiliary/tgsi/tgsi_info.c | 4 ++--
src/gallium/docs/source/tgsi.rst | 8
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 26 +++---
.../nouveau/codegen/nv50_ir_lowering_nvc0.h| 1 +
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git
This patch fixes 592 clang parentheses-equality warnings on Fedora 20.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
tests/util/piglit-dispatch-gen.c.mako | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/tests/util/piglit-dispatch-gen.c.mako
60 matches
Mail list logo
