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.
I
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
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 refacto
In this commit, the function bodies of each of the
brw_upload__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 subsequent comm
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),
whene
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 guess
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
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 long
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
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 dirty-bit checking from each brw_upload__prog function is
split out into its a new brw__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.
---
src/mesa/drivers/dri/i965/brw_f
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 ---
src/mesa
This completes the refactoring being prepared for in the previous
commits. The function bodies of all brw_upadload__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 added a
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 no
ising the inexact exception, which I don't think we care
> about anyway.
All looks good to me, Matt.
For the series:
Reviewed-by: Carl Worth
-Carl
pgpJ8HMM5zZAh.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@l
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
-Carl
pgp1BOJRVmNZE.pgp
Descrip
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
-Carl
--
carl.d.wo...@intel.com
pgp5HqiGlRi7H.pgp
Description: PGP signature
___
mesa-dev m
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
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, 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
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 o
> 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:
Revi
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
-Carl
--
carl.d.wo...@intel.com
pgp9C0kDV4b3E.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
_
:
Reviewed-by: Carl Worth
-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
>
> What a useful warning. #ThanksGCC
Reviewed-by: Carl Worth
Sarcasm-by: Ian Romanick? ;-)
-Carl
pgph3XoYbTHGG.pgp
Description: PGP signature
___
mesa-dev mailing list
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
ter too much.
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
-Carl
pgpUYUpkJL7HF.pgp
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
immediate
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 fol
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 he
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 thi
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 whic
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, P
On Wed, Feb 04 2015, Tapani Pälli wrote:
> What would you think about changing this to use some defined maximum
> size (in MB)? I think for the user size is what matters and it could be
> a configurable option, number of items seems a bit vague and hard to
> predict (?)
Yes, changing over to a
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.
Actuall
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 hab
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 valu
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 b/docs/envvars.html
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 f
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 ha
From: Kristian Høgsberg
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 maximum number of entr
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
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
/.cache/mesa
Also with this patch, once the desired path is determined, the
directory is
Instead of writing directly to the desired , with this patch
we instead first write to .tmp and then use rename() to
atomically rename from .tmp to . This ensures that
any process that opens for reading will never see any
partially written file.
---
src/glsl/cache.c | 41 +
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
SHA
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
Thanks!
-Carl
pgpPQ3Jww2upP.pgp
Descripti
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
testing results
you get.
Thanks,
-Carl
From 07bd85f5c620361ad0ea358f01a8a0b5139f1239 Mon Sep 17 00:00:00 2001
From: Carl Worth
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
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
wil
A1_LIBS)
+
BUILT_SOURCES = $(MESA_UTIL_GENERATED_FILES)
CLEANFILES = $(BUILT_SOURCES)
diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
index 9e27424..39f87e4 100644
--- a/src/util/Makefile.sources
+++ b/src/util/Makefile.sources
@@ -1,10 +1,17 @@
+if HAVE_SHA1
+MESA_UTIL_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
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 | 3
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 c
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 t
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 th
On Thu, Dec 11 2014, Jason Ekstrand wrote:
> Yeah, this looks nifty.
Thanks!
> I've got some comments on the implementation though.
I really appreciate the careful review. I obviously didn't pay quite as
much attention to detail as I would like to when writing this patch. I'm
glad I didn't bury
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 al
cdir)/src/mapi \
-I$(top_srcdir)/src/mesa \
+ $(SHA1_CFLAGS) \
$(VISIBILITY_CFLAGS)
libmesautil_la_SOURCES = \
$(MESA_UTIL_FILES) \
$(MESA_UTIL_GENERATED_FILES)
+libmesautil_la_LIBADD = $(SHA1_LIBS)
+
BUILT_SOURCES = $(MESA_UTIL_GENERATED_FILES)
CL
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 high-lev
From: Kristian Høgsberg
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 piece.
As currentl
From: Tapani Pälli
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 the placeholder
value.
T
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 b
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 th
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 a
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 logic
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 5
On Thu, Dec 04 2014, Carl Worth wrote:
> So I think I'll follow up with a separate patch to clean these up.
Before I do that, I noticed the following in util/macros.h:
/**
* Unreachable macro. Useful for suppressing "control reaches end of
non-void
* funct
On Thu, Dec 04 2014, Matt Turner wrote:
> On Thu, Dec 4, 2014 at 2:00 PM, Carl Worth wrote:
>> + assert(!"Should not get here.");
>> + return error_type;
>
> Let's just use unreachable("not reached") here.
That's a good idea. I copied t
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.
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
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.
H
From: Tapani Pälli
Shader binary cache requires this to be able to cache hash data from
the gl_shader_program structure.
Signed-off-by: Tapani Pälli
Reviewed-by: Paul Berry
Reviewed-by: Carl Worth
---
src/mesa/program/hash_table.h | 8
1 file changed, 8 insertions(+)
diff --git a
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
src/glsl/glsl_types.
Emil Velikov 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
pgp0S6c9mNLZn.pgp
Description: PGP sign
Emil Velikov 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 any HTML test
summary)
Carl Worth writes:
> Emil Velikov 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 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
OK. These are both pushed now
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 callo
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 t
Carl Worth 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
Matt Turner 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 grep 'calloc.* \*
Emil Velikov 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 if someone can t
Kenneth Graunke 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
care in compiling!
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'.
Anuj Phogat writes:
> On Wed, Jul 30, 2014 at 4:09 PM, Carl Worth wrote:
>> Ian Romanick writes:
>>> Anuj: Can you verify this does not regress proxy_textures_invalid_size?
>> ...
>>> Cc: "10.2"
>>
>> Ian (or Anuj), is there an outstandin
ix assertion 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
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
h
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
s
before any newline 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
Appro
Carl Worth 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&
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 on
Erik Faye-Lund 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 for character set
Erik Faye-Lund writes:
> On Tue, Aug 5, 2014 at 11:22 PM, Carl Worth 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
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 includes
Carl Worth 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
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
1 - 100 of 477 matches
Mail list logo
