You're right, that's a bad idea and doesn't work.
On Fri, Jun 27, 2014 at 6:09 PM, Iago Toral wrote:
> If by not doing anything you mean not processing or removing the
> ir_emit_vertex instructions for that stream this would have two problems
> at least:
>
> 1) We won't get correct results for GL
If by not doing anything you mean not processing or removing the
ir_emit_vertex instructions for that stream this would have two problems
at least:
1) We won't get correct results for GL_PRIMITIVES_GENERATED in that
stream (it will always be 0). This may be a minor problem.
2) If that stream is s
This patch fixes 592 clang parentheses-equality warnings on Fedora 20.
Signed-off-by: Vinson Lee
---
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
b/tests/util/piglit-dispatc
Signed-off-by: Ilia Mirkin
---
.../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 a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
Signed-off-by: Ilia Mirkin
---
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
b/src/gallium/drivers/trac
Signed-off-by: Ilia Mirkin
---
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 +
src/gallium/drivers/llvmpipe/lp_screen.c
This patch series is enough for xfb-streams to pass on a GK107 card. Haven't
done much more testing than that.
The mesa/st bits apply on top of Iago's v2 23-patch series, all the other
patches should be independent of that.
Ilia Mirkin (8):
gallium: add vertex stream argument to EMIT/ENDPRIM
Signed-off-by: Ilia Mirkin
---
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| 3 ++-
src/gallium/d
Signed-off-by: Ilia Mirkin
---
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 a/src/gallium/auxiliary/tgsi/tgsi_info.c
Signed-off-by: Ilia Mirkin
---
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
b/src/mesa/state_tracker/st_cb_queryobj.c
index 1a
Signed-off-by: Ilia Mirkin
---
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
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index
Signed-off-by: Ilia Mirkin
---
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 +-
src/gallium/drivers/nouve
This in theory changes ABI for the boolean->bool I think,
but nothing in the tree uses configQueryb AFAICS.
Signed-off-by: Dave Airlie
---
include/GL/internal/dri_interface.h| 7 ---
src/mesa/drivers/dri/common/dri_util.c | 6 +++---
2 files changed, 7 insertions(+), 6 deletions(-)
diff
This just drops all the GL types from the xmlconfig and use
std C types from stdint and stdbool.
Signed-off-by: Dave Airlie
---
src/mesa/drivers/dri/common/xmlconfig.c | 176
src/mesa/drivers/dri/common/xmlconfig.h | 20 ++--
2 files changed, 98 insertions(+), 9
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.
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
___
mesa-de
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 start condition, the only valid start condition is
, so whether pushing/popping onto the stack or explicit
returning to is equivalent.
The reason for this change is that we are planning to soon add a s
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 start condit
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 commen
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
c
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 wou
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 pig
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 commit
From: Kenneth Graunke
Without this, in the 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 commit in place, we ge
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 deleti
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 a
This is in preparation for the planned addition of a new 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
implemen
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 start
state. Because of this, flex's default rule was being invoked, (printing
characters to stdout), and all text was bei
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
c
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
+++ b
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 action was restricted only to the state so
it would fail to get invoked if the EOF was encountered in the or
the case. Neither of t
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 directi
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 removin
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 a/src/glsl/gl
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 start condition used to control
this skipping. This start condition was not handled like a normal start
condition
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, b
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
co
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 wrote:
> Hello,
>
> while testing various scenarios for multi-stream suppo
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
b/src/gallium/state_tra
Reviewed-by: Jordan Justen
On Sun, Jun 22, 2014 at 10:27 PM, Kenneth Graunke wrote:
> On i965, enabling and disabling the GS is not free: you have to do a
> full pipeline stall, reconfigure the URB and push constant space, and
> emit a bunch of state. Most clears aren't layered, so the GS isn't
On Wednesday, June 25, 2014 02:42:24 PM Gregory Hunt wrote:
> From: Greg Hunt
>
> 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, HdrBloom, Multith
On Wed, Jun 25, 2014 at 12:05 PM, Jon Ashburn 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
> existing
> ac
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
> > wrote:
> >> ---
> >> src/gallium/state_trackers/egl/common/egl_g3d.c | 1 +
> >> src/gallium/state_trackers/egl/common/
On 06/26/2014 07:32 PM, Ilia Mirkin wrote:
On Thu, Jun 26, 2014 at 1:31 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
wrote:
---
src/gallium/state_trackers/egl/common/egl_g3d.c | 1 +
src/gallium/s
On Thu, Jun 26, 2014 at 1:31 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
>> wrote:
>>>
>>> ---
>>> src/gallium/state_trackers/egl/common/egl_g3d.c | 1 +
>>> src/gallium/state_trackers/egl/common/e
On 06/26/2014 07:25 PM, Ilia Mirkin wrote:
On Thu, Jun 26, 2014 at 1:08 PM, Knut Andre Tidemann
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 a/src/gallium
On Thu, Jun 26, 2014 at 1:08 PM, Knut Andre Tidemann
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 a/src/gallium/state_trackers/egl/common/egl_g3d.c
>
---
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
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 conte
On Thursday, June 26, 2014 12:53:11 PM Ilia Mirkin wrote:
> On Sun, Jun 22, 2014 at 1:49 PM, Ilia Mirkin 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
> > ---
> >
> > I'
On Sun, Jun 22, 2014 at 1:49 PM, Ilia Mirkin 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
> ---
>
> I'm probably missing some reason why this wasn't already enabled, but sendin
... as it's caller (the external program omxregister-bellagio) is the one
who frees all of the allocated memory.
Cc: Pedretti Fabio
Reported-by: Pedretti Fabio
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/omx/vid_dec.c | 41 ++--
src/gallium/state_trac
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
OS
https://bugs.freedesktop.org/show_bug.cgi?id=80541
Roland Scheidegger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Tom Stellard 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 query function fro
Tom Stellard writes:
> From: Matt Arsenault
>
> v2:
> -Fix indentation
> ---
> src/gallium/state_trackers/clover/api/device.cpp | 11 +--
> src/gallium/state_trackers/clover/core/device.cpp | 24
> +++
> src/gallium/state_trackers/clover/core/device.hpp | 3 +++
Tom Stellard writes:
> From: Matt Arsenault
>
> 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. Without it, this patch is:
Reviewed-by
On 06/25/2014 06:38 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
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.
---
src/gallium/drivers/softpipe
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 scenar
63 matches
Mail list logo
