Hi folks,
I've pushed the latest version of my shader-cache work to a branch named
shader-cache at:
git://people.freedesktop.org/~cworth/mesa
I've rebased this against the latest master branch and verified that it
at least compiles and works with at least some trivial test programs.
On Tue, Jun 09 2015, Ian Romanick wrote:
From section 3.4 (Preprocessor) of the GLSL ES 3.00 specification:
#line must have, after macro substitution, one of the following forms:
#line line
#line line source-string-number
where line and source-string-number are constant integral
Yes. That patch was severely broken in several ways.
In its place, here is a pair of patches intending to do the same thing
in two steps. Thanks to Ken for helpful review and guidance to get to
this point.
At this point, I'm quite confident that the logic of the code is
undisturbed by the
In this commit, the function bodies of each of the
brw_upload_stage_prog functions are manually inlined into
brw_upload_programs. This commit is intended to have no functional
change.
The resulting function body of brw_upload_programs is fairly messy,
and is expected to be cleaned up by
This refactor idetnfies as much common code as possible across the various
stages within brw_upload_programs. The resulting code is a loop over all
relevant stages and various accessory functions (per_stage_state_dirty,
per_stage_populate_key, per_stage_codegen, and per_stage_vue_map_update),
On Wed, Apr 08 2015, Neil Roberts wrote:
It seems a bit strange that this has stopped working for you.
Yes. I don't understand exactly what's going on.
mode. The C and C++ modes both inherit from prog-mode, as well as a
bunch of other ones such as Python and lisp files.
That's what I
On Fri, Apr 03 2015, Jordan Justen wrote:
- (fill-column . 78)
Do we want to remove this? Or does it match the default?
The default is actually 70. I didn't mean to have that part in the
commit. Thanks for noticing.
+ (.git (nil (fill-column . 70)))
Should the commit subject line be under
I recently noticed (after upgrading to emacs 24?) that I was no longer
getting automatic C-style settings in emacs like I was accustomed to
getting. That is, I was now getting a default indentation of 8 and
indentation with tabs instead of spaces.
It appears that the .dir-locals.el file is no
On Fri, Mar 20 2015, Chris Forbes wrote:
I think that having both the existing `struct brw_vs_compile` and a
function with the same name is going to cause confusion. (same with
the other non-fs stages)
In an earlier version of the patch I had brw_vs_do_compile, (there is a
do precedent in the
On Fri, Mar 20 2015, Ian Romanick wrote:
+brw_gs_populate_key(struct brw_context *brw,
+struct brw_gs_prog_key *key)
Tabs. There may be some in other places too. Thunderbird's editor
isn't too smart to be able to search for tabs... it matches any
whitespace.
Sorry about
This completes the refactoring being prepared for in the previous
commits. The function bodies of all brw_upadload_stage_prog
functions are pulled up into brw_upload_programs where there are
unified with loops and switch statements.
The purpose of this refactoring is to allow for new code to
be
This commit splits portions of the existing brw_upload_vs_prog and
brw_upload_gs_prog function into new brw_vs_populate_key and
brw_gs_populate_key functions. This follows the same style as is
already present for all other stages, (see brw_wm_populate_key, etc.).
This commit is intended to have
The dirty-bit checking from each brw_upload_stage_prog function is
split out into its a new brw_stage_state_dirty function.
This commit is intended to have no functional change. It exists in
preparation for some upcoming code movement in preparation for the
shader cache.
---
The rename here is in preparation for these functions to be exported
to other files.
This commit is intended to have no functional change. It exists in
preparation for some upcoming code movement in preparation for the
shader cache.
---
src/mesa/drivers/dri/i965/brw_ff_gs.c | 7 ---
, which I don't think we care
about anyway.
All looks good to me, Matt.
For the series:
Reviewed-by: Carl Worth cwo...@cworth.org
-Carl
pgpJ8HMM5zZAh.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http
On Mon, Mar 16 2015, Matt Turner wrote:
textdata bss dec hex filename
9663 0 0966325bf intel_tiled_memcpy.o before
8215 0 082152017 intel_tiled_memcpy.o after
Reviewed-by: Carl Worth cwo...@cworth.org
-Carl
pgp1BOJRVmNZE.pgp
On Fri, Mar 13 2015, Matt Turner wrote:
Perhaps something like the following?
Round \x to the nearest even integer (returned in floating-point
format).
I didn't read this closely enough the first time, but if I had I think
I could have short circuited a lot of the confusion.
On Fri, Mar 13 2015, Kenneth Graunke wrote:
This is already copied in two places, and I want to copy it to a third
place.
Reviewed-by: Carl Worth cwo...@cworth.org
-Carl
--
carl.d.wo...@intel.com
pgp5HqiGlRi7H.pgp
Description: PGP signature
On Thu, Mar 12 2015, Matt Turner wrote:
I think you misread. rint() *does* provide the behavior we want
(round-to-nearest, half to even) when the rounding mode is the default
round-to-nearest.
Thanks. I did at least verify that behaviorally as I just mentioned in a
separate mail.
As Eric
On Thu, Mar 12 2015, Matt Turner wrote:
+/* The C standard library has functions round()/rint()/nearbyint() that round
+ * their arguments according to the rounding mode set in the floating-point
+ * control register. While there are trunc()/ceil()/floor() functions that do
+ * a specific
On Thu, Mar 12 2015, Carl Worth wrote:
But beyond that, I'm actually confused---how can the default rounding
mode (rounding toward nearest number, right?) give us an adequate
implementation for roundeven()?
Of course, I had asked for (and received) a patch with a test. And the
test verifies
ARB_shading_language_packing is part of GLSL 4.2, not 4.0 as I
mistakenly believed. The following functions are available only with
ARB_shading_language_packing, GLSL 4.2 (not GLSL 4.0), or ES 3.0:
I'll trust you that you're correct on the specification version, so:
Reviewed-by: Carl Worth
or four commits here:
1. Change _mesa_round_to_even to return a float
2. Fix rounding bug in _mesa_round_to_even
3. Add unit test for recent rounding-bug fix
4. Optimize _mesa_round_to_even with SSE 4.1 ROUND if available
With that: Reviewed-by: Carl Worth cwo
-by: Carl Worth cwo...@cworth.org
-Carl
pgpSkpdVeZKDc.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Feb 27 2015, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
What a useful warning. #ThanksGCC
Reviewed-by: Carl Worth cwo...@cworth.org
Sarcasm-by: Ian Romanick? ;-)
-Carl
pgph3XoYbTHGG.pgp
Description: PGP signature
On Sat, Feb 28 2015, Ilia Mirkin wrote:
Another clean alternative is to leave the name of the variable out, i.e.
function(struct gl_context *)
Wow. Less is more! I hadn't realized that's a solution for this, but
it's really elegant.
-Carl
pgpHapVflSAmW.pgp
Description: PGP signature
Commit f82f2fb3dc770902f1657ab1c22e6004faa3afab added use of the Mesa
IR optimizer for both ARB_fragment_program and ARB_vertex_program, but
only justified the vertex-program portions with measured performance
improvements.
Meanwhile, the optimizer was seen to generate hundreds of unused
Across the board of the various generations, the intial few atoms in
all of the atom lists are basically the same, (performing uploads for
the various programs). The only difference is that prior to gen6
there's an ff_gs upload in place of the later gs upload.
In this commit, instead of using the
.
Thanks for the fix, Neil. The analysis and patch look sound to me, and
thanks for contributing a piglit test as well. Additionally, we ran the
patch through some benchmarks and didn't notice any negative performance
impact.
Reviewed-by: Carl Worth cwo...@cworth.org
-Carl
pgpUYUpkJL7HF.pgp
Across the board of the various generations, the intial few atoms in
all of the atom lists are basically the same, (performing uploads for
the various programs). The only difference is that prior to gen6
there's an ff_gs upload in place of the later gs upload.
In this commit, instead of using the
This code provides for an on-disk cache of objects. Objects are stored
and retrieved via names that are arbitrary 20-byte sequences,
(intended to be SHA-1 hashes of something identifying for the
content). The directory used for the cache can be specified by means
of environment variables in the
On Mon, Feb 09 2015, Jose Fonseca wrote:
Just one more tweak to InterlockedExchangeAdd64 as per patch attached.
..
With that u_test_atomic builds and passes for me both on 32 and
64bits.
Excellent. Thanks for the fix and for the testing report.
Sorry for the delay. And thanks for your help
This provides for atomic addition, which will be used by an upcoming
shader-cache patch. A simple test is added to make check as well.
Note: The various O/S functions differ on whether they return the
original value or the value after the addition, so I did not provide
an add_return() macro which
On Fri, Feb 06 2015, Aaron Watry wrote:
Ignore me if this is a stupid question, but should those both be
sizeof(short)? I'd expect the first to be sizeof(char).
Not a stupid question. That was a copy-and-paste (kill-and-yank ?) bug
of mine.
Thanks for your attention to detail. I've fixed this
On Wed, Feb 04 2015, Carl Worth wrote:
First, when mapping the index file:
/* FIXME: We map this shared, which is a start, but we need to think about
* how to make it multi-process safe. */
cache-index = (unsigned char *)
mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED
From: Kristian Høgsberg k...@bitplanet.net
This code provides for an on-disk cache of objects. Objects are stored
and retrieved (in ~/.cache/mesa) via names that are arbitrary 20-byte
sequences, (intended to be SHA-1 hashes of something identifying for
the content).
The cache is limited to a
This API forms the base infrastructure for the future shader cache. At
this point, the cache is simply a persistent, on-disk store of objects
stored and retrieved by 20-byte keys.
---
src/glsl/cache.h | 121 +++
1 file changed, 121 insertions(+)
Hi folks,
This series adds a layer of code to store a cache of objects on
disk. Thanks to Kristian Høgsberg for the initial proof-of-concept
implementation here. I've take his original code and added my own
cleanups and documentation to the cache API. I've also fixed up a
couple of the items he
With this patch, there are now three different options for the shader
cache directory, (considered in order until the first variable is
set):
$MESA_GLSL_CACHE_DIR
$XDG_CACHE_HOME/mesa
user-home-directory/.cache/mesa
Also with this patch, once the desired path is
Instead of writing directly to the desired filename, with this patch
we instead first write to filename.tmp and then use rename() to
atomically rename from filename.tmp to filename. This ensures that
any process that opens filename for reading will never see any
partially written file.
---
The user can put the cache directory anywhere, so it's not safe to use
fixed-size arrays to store filenames. Instead, allocate the cache
pointer itself as a ralloc context and use that to dynamically
allocate all filenames.
While making this change, simplify the error handling in cache_get
with a
If Mesa is being compiled with no shader cache, (whether due to
explicit user request or due to a missing library dependency), then we
want to incur no cost on the implementation. To achieve this with as
little fuss as possible, (that is, without sprinkling #ifdef
throughout every call into cache
This patch adds support for a new variable, MESA_GLSL_CACHE_DISABLE.
If this variable is set, then all use of the shader cache will be
disabled at run time.
---
docs/envvars.html | 1 +
src/glsl/cache.c | 4
2 files changed, 5 insertions(+)
diff --git a/docs/envvars.html
On Wed, Feb 04 2015, Kenneth Graunke wrote:
The cache will need to be much larger than 1024 entries - perhaps by an
order of magnitude.
Thanks for the feedback. I had meant to add a comment next to that 1024
in the code along the lines of This value was chosen arbitrarily. An
appropriate value
On Wed, Feb 04 2015, Matt Turner wrote:
Is there some reason we should do this as a separate patch instead of
just squashing it?
Not really. I've just squashed it, (while also fixing the space before
the parenthesis---I should probably add a pre-commit check for those to
help me break that
On Wed, Feb 04 2015, Matt Turner wrote:
Rebase needed. I removed GLSL_SRCDIR a week and a half ago.
Was this the removal of all those subdir-objects warnings? Thank you!
I don't think it makes a difference to autotools, but I think I'd list
cache.h here instead of in LIBGLSL_FILES.
Actually,
On Fri, Jan 16 2015, Jose Fonseca wrote:
Oh, just saying that in fact I got it to build that module on Windows.
Thanks. That's good to know. I appreciate that testing.
I've just pushed this series along with your fixes.
And for the sake of everyone that contributed to the discussion on the
On Thu, Jan 08 2015, Jose Fonseca wrote:
Note that Windows build is only supported with SCons. Never with
autobuild.
OK. That's good for me to learn. I've requested that the folks doing our
automated build testing here will also start testing scons builds, so
hopefully on our end we can avoid
On Thu, Jan 15 2015, Matt Turner wrote:
I wouldn't put the spaces after and before the [ ] (there's an
occurrence of this in the previous patch as well, that gets removed in
this one).
OK. I'll fix that.
Both are:
Reviewed-by: Matt Turner matts...@gmail.com
Thanks!
-Carl
07bd85f5c620361ad0ea358f01a8a0b5139f1239 Mon Sep 17 00:00:00 2001
From: Carl Worth cwo...@cworth.org
Date: Wed, 7 Jan 2015 11:07:59 -0800
Subject: [PATCH] Exercise the recently-added sha1 code.
This commit is not intended to be pushed upstream. It simply adds a
print message for each compiled shader, giving the computed sha1
On Fri, Dec 12 2014, Jose Fonseca wrote:
Yes, ideally we'd have something small that we could bundle into mesa
source tree, for sake of non Linux OSes.
Ken has pointed to an implementation that might be suitable for this.
I haven't reviewed that code myself, nor am I signing up to maintain a
--- /dev/null
+++ b/src/util/sha1.c
@@ -0,0 +1,316 @@
+/* Copyright © 2007 Carl Worth
+ * Copyright © 2009 Jeremy Huddleston, Julien Cristau, and Matthieu Herrb
+ * Copyright © 2009-2010 Mikhail Gusarov
+ * Copyright © 2012 Yaakov Selkowitz and Keith Packard
+ * Copyright © 2014 Intel Corporation
We don't actually have the code for the shader cache just yet, but
this configure machinery puts everything in place so that the shader
cache can be optionally compiled in.
Specifically, if the user passes no option (neither
--disable-shader-cache, nor --enable-shader-cache), then this feature
In addition to exercising all of the functions in blob.h, this
includes a stress test that forces some reallocing, and also tests to
verify the alignment and overrun-detection code in blob.c.
---
src/glsl/Makefile.am | 7 +
src/glsl/tests/.gitignore | 1 +
src/glsl/tests/blob_test.c |
This new interface allows for writing a series of objects to a chunk
of memory (a blob).. The allocated memory is maintained within the
blob itself, (and re-allocated by doubling when necessary).
There are also functions for reading objects from a blob as well. If
code attempts to read beyond the
On Fri, Dec 12 2014, Jason Ekstrand wrote:
Should be MAX2(blob-allocated * 2, blob-size + additional)
Yikes! Yes. That's really embarrassing.
Something to tuck in the back of your brain in case you have a need to grow
this datastructure: The above write functions could be generated with three
On Fri, Dec 12 2014, Ian Romanick wrote:
In addition to the (mostly) nits below, this seems ripe for some unit
tests. Especially for the overrun cases and the data alignment cases.
Thanks for the review, Ian. Testing makes sense. I'll cook something up.
And thanks for the nit-picking. I've
The unreachable macro has the advantage (for modern compilers) of
hinting to the compiler that this code is actually unreachable. This
allows us to drop things like return statements or assignments that
existed only to quiet compiler warnings.
Also, this version is a bit easier to type correctly
This new interface allows for writing a series of objects to a chunk
of memory (a blob).. The allocated memory is maintained within the
blob itself, (and re-allocated by doubling when necessary).
There are also functions for reading objects from a blob as well. If
code attempts to read beyond the
Here are two patches that add some functions for serializing and
deserializing simple data structures, (integers of various sizes,
pointers, and strings).
This code will be used by my upcoming shader-cache work. I'm
submitting it here now because it is self-contained and documented, so
it should
From: Tapani Pälli tapani.pa...@intel.com
These functions are useful when serializing an unknown number of items
to a blob. The caller can first save the current offset, write a
placeholder uint32, write out (and count) the items, then use
blob_overwrite_uint32 with the saved offset to replace
From: Kristian Høgsberg k...@bitplanet.net
The upcoming shader cache uses the SHA-1 algorithm for cryptographic
naming. These new mesa_sha1 functions are implemented with the nettle
library.
---
This patch is another in support of my upcoming shader-cache work. Thanks to
Kritian for coding this
On Thu, Dec 11 2014, Brian Paul wrote:
We'll need a solution for Windows too. I don't have time right now to
do any research into that.
The code from xserver seems to cover that. I'll follow up with a
(largely untested) patch that I ported over from xserver.
If people can give some
a/src/util/sha1.c b/src/util/sha1.c
new file mode 100644
index 000..d6c2c98
--- /dev/null
+++ b/src/util/sha1.c
@@ -0,0 +1,291 @@
+/* Copyright © 2007 Carl Worth
+ * Copyright © 2009 Jeremy Huddleston, Julien Cristau, and Matthieu Herrb
+ * Copyright © 2009-2010 Mikhail Gusarov
+ * Copyright
Prior to copying in code from the xserver configure.ac file, it makes
sense to have the license of this file clearly marked, (to show that
it's licensed identically to the configure.ac file from the xserver
repository).
And since the text of the license refers to the above copyright
notice it
Previously, if __builtin_unreachable() was unavailable, the
unreachable macro was defined to do nothing. We do better here, by at
least still making it an assert.
---
src/util/macros.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/macros.h b/src/util/macros.h
index
The unreachable macro has the advantage (for modern compilers) of
hinting to the compiler that this code is actually unreachable, which
can help reduce spurious warnings, etc.
Also, this version is a bit easier to type correctly and understand
when reading without that seemingly out-of-place
This is similar to the existing functions get_instance, get_array_instance,
etc. for getting a type singleton. The new get_sampler_instance() function
will be used by the upcoming shader cache.
---
src/glsl/glsl_types.cpp | 111
From: Tapani Pälli tapani.pa...@intel.com
Shader binary cache requires this to be able to cache hash data from
the gl_shader_program structure.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
Reviewed-by: Paul Berry stereotype...@gmail.com
Reviewed-by: Carl Worth cwo...@cworth.org
---
src
There is an internal implementation detail that the hash table
underlying the struct string_to_uint_map stores each value internally
as (value+1). The user needn't be very concerned with this (other than
knowing that a value of UINT_MAX cannot be stored) since put() adds 1
and get() subtracts 1.
On Thu, Dec 04 2014, Ian Romanick wrote:
Should this just get squashed with the previous commit?
Yes. I only hesitated because I wrote the second and not the first, (so
I didn't want to lose authorship in the history).
But it's not useful to have an iterate in the history that actually does
the
On Thu, Dec 04 2014, Ian Romanick wrote:
Shouldn't type be glsl_base_type instead of unsigned?
Yes, thanks for the catch. Fixed.
+ if (shadow)
+return (array ? sampler2DArrayShadow_type : sampler2DShadow_type
+);
It's weird that the closing paren ended up here. I don't
On Thu, Dec 04 2014, Matt Turner wrote:
On Thu, Dec 4, 2014 at 2:00 PM, Carl Worth cwo...@cworth.org wrote:
+ assert(!Should not get here.);
+ return error_type;
Let's just use unreachable(not reached) here.
That's a good idea. I copied this line from the surrounding code in the
same
Emil Velikov emil.l.veli...@gmail.com writes:
Would appreciate admin access to clear up some of the patches that I've
committed on behalf of other people :)
I just went to add this, but it looks like someone beat me to it
already.
Have fun!
-Carl
--
carl.d.wo...@intel.com
Emil Velikov emil.l.veli...@gmail.com writes:
There is a recent bug in piglit (+ it's fix [1]) that causes the env vars used
not to be printed in the HTML test summary.
That would be a good bug fix. But the problem I had was that piglit
wasn't running this test at all, (so I wasn't even getting
Carl Worth cwo...@cworth.org writes:
Emil Velikov emil.l.veli...@gmail.com writes:
I will not have the chance to run piglit on a i965 system until next
week so I would love if someone can take a look at this.
I should be able to take a look at this today or tomorrow.
I didn't see any
Matt Turner matts...@gmail.com writes:
- configs = calloc(1, (num_modes + 1) * sizeof *configs);
+ configs = calloc((num_modes + 1), sizeof *configs);
I'd drop the extra parentheses.
Thanks for reading carefully, Matt!
With that, both are
Reviewed-by: Matt Turner matts...@gmail.com
Matt Turner matts...@gmail.com writes:
git blaming that turns up a sloppy search and replace commit that
replaced _mesa_calloc(x) (taking only one argument) with calloc(1, x),
even when x was a multiplication expression.
Thanks for chasing that down.
If someone wants to fix these up: git
Carl Worth cwo...@cworth.org writes:
And here's another that isn't the same pattern, (no 1, so not part of
the same search/replace issue), but potentially still worth looking
at. Here, there are three things being multiplied. I haven't looked at
...
src/mesa/tnl/t_vertex.c: vtx-vertex_buf
As explained in the previous commit, we want to avoid the possibility of
integer-multiplication overflow while allocating buffers.
In these two cases, the final allocation size is the product of three values:
one variable and two that are fixed constants at compile time.
In this commit, we move
In commit 32f2fd1c5d6088692551c80352b7d6fa35b0cd09, several calls to
_mesa_calloc(x) were replaced with calls to calloc(1, x). This is strictly
equivalent to what the code was doing previously.
But for cases where x involves multiplication, now that we are explicitly
using the two-argument
Emil Velikov emil.l.veli...@gmail.com writes:
This patch seems to regress two tests when running classic swrast. The gallium
swrast is OK.
glean:
fragProg1-CMP
glsl1-Preprocessor test 11 (#elif)
I will not have the chance to run piglit on a i965 system until next
week so I would love
Kenneth Graunke kenn...@whitecape.org writes:
Erm. Shouldn't there be a star here? ^^^
Yikes! I don't know which is more embarrassing. The regression that I
committed that showed I didn't take enough care in running piglit, or
this patch which I submitted to fix it which showed I took even less
Mesa 10.3 release candidate 1 is now available for testing. The current
plan is to have an additional release candidate each Friday until the
eventual 10.3 release, (Ian can follow up to state what the planned date
is for that).
The tag in the git repository for Mesa 10.3-rc1 is 'mesa-10.3-rc1'.
in _mesa_drawbuffers()
Carl Worth (3):
docs: Add sha256 sums to the 10.2.5 release notes
Update VERSION to 10.2.6
Add release notes for the 10.2.6 release
Ilia Mirkin (1):
mesa/st: only convert AND(a, NOT(b)) into MAD when not using native
integers
Jordan Justen (1):
i965
Anuj Phogat anuj.pho...@gmail.com writes:
On Wed, Jul 30, 2014 at 4:09 PM, Carl Worth cwo...@cworth.org wrote:
Ian Romanick i...@freedesktop.org writes:
Anuj: Can you verify this does not regress proxy_textures_invalid_size?
...
Cc: 10.2 mesa-sta...@lists.freedesktop.org
Ian (or Anuj
character. So we can use a simple [\r\n] to get the desired
behavior while avoiding the flex bug.
Fixes Piglit's 16385-consecutive-chars and
17000-consecutive-chars-identifier tests.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82472
Signed-off-by: Carl Worth cwo...@cworth.org
Approach
I noticed that with /bin/sh on Mac OS X, echo -n does not work as
desired, (it actually prints -n rather than suppressing the final
newline). There is a /bin/echo that could be used (it actually works)
instead of the builtin echo.
But I decided it's more robust to just use printf rather than
There were two problems with the way this script used sed on OS X:
1. The OS X sed doesn't interpret \r in a replacement list as a
carriage-return character, (instead it was inserting a literal
'r' character).
We fix this by putting an actual ^M character into the source of
Carl Worth cwo...@cworth.org writes:
Normally, I would have completed my own testing of the branch prior to
pushing the candidate. This time, I'm a little late, but I plan to
follow up tomorrow with my own testing results, (which hopefully will
not lead to any changes in the branch).
I've
I've just made my pass over the stable queue and pushed out a new
candidate branch for the upcoming 10.2.6 release. You can see the 25
patches included (and the 42 still awaiting review) here:
http://cworth.org/~cworth/mesa-stable-queue/
As usual, I plan to make the next stable release
Erik Faye-Lund kusmab...@gmail.com writes:
It seems to me like this is there to support non-ASCII identifiers and
strings, but GLSL doesn't support either. I'm not able to come up with
a conclusion here.
That's almost always the case with GLSL. The GLSL specification does
have its own section
The desired behavior here is that there is no error for an illegal character
appearing in the replacement list of a macro definition.
However, any expansion of such a macro, causing the illegal character to
appear in the preprocessed source, should emit an error.
These two tests exercise both of
The GLSL Language Specification (version 4.30.6) is quite clear about the GLSL
character set and the expected behavior for other characters:
Section 3.1 Character Set
The source character set used for the OpenGL shading languages, outside of
comments, is a subset of UTF-8. It
Erik Faye-Lund kusmab...@gmail.com writes:
On Tue, Aug 5, 2014 at 11:22 PM, Carl Worth cwo...@cworth.org wrote:
Now, what we could do if we were so inclined, would be to defer the
errors for illegal characters until they actually appeared in the
pre-processor output.
What you describe here
Ian Romanick i...@freedesktop.org writes:
Are the preprocessor patches on the gles3conform-v4 branch of my fd.o
repo the most up to date?
Yes. The state of those patches matches what I have on my branch, (at
least as far as GLES3 conformance is concerned---I have some subsequent
preprocessor
Sometimes the newline separator is a single character, and sometimes it is two
characters. Before we can fold away and line-continuation backslashes, we
identify the flavor of line separator that is in use.
With this identified, we then correctly search for backslashes followed
immediately by the
Carl Worth cwo...@cworth.org writes:
It probably wouldn't be too hard to fix this code to be more general. I
might take a whack at that now that I have this test in hand.
It wasn't too hard. I just sent a v2 patch in reply to the original (and
also force-pushed a new glcpp-fixup branch to my
odd-looking exceptional behavior).
-Carl
From b57b0a5a88c318b71ac58a7c1569f07d416e6486 Mon Sep 17 00:00:00 2001
From: Carl Worth cwo...@cworth.org
Date: Tue, 5 Aug 2014 11:31:56 -0700
Subject: [PATCH] glsl/glcpp: Add testing for no space between macro name and
replacement list
GCC's preprocessor
Of course, these aren't really useful for anything, but the GLSL language
specification does allow them:
The source character set used for the OpenGL shading languages,
outside of comments, is a subset of UTF-8. It includes the following
characters:
...
1 - 100 of 459 matches
Mail list logo
