summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* i965: Drop the degenerate brw_sampler_default_color structure.Kenneth Graunke2014-08-023-16/+8
| | | | | | | | | It's just an array of four floats, and we have an array of four floats, so this is literally just a memcpy...but with custom structs and strange macros to give the appearance of doing something more. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965: Write a better file comment for brw_sampler_state.c.Kenneth Graunke2014-08-021-7/+6
| | | | | | | The old one has been inaccurate for years. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965: Rename brw_wm_sampler_state.c to brw_sampler_state.c.Kenneth Graunke2014-08-023-2/+2
| | | | | | | | | | | | | | | When the driver was originally written, it only supported texturing in the pixel shader backend; vertex and geometry shader texturing came much later. Originally, the pixel shader was referred to as "WM" (the Windowizer/Masker unit). So, this code happened to only be relevant for the WM stage, at the time. However, sampler state really applies to all stages, so putting "wm" in the filename doesn't make sense. I dropped it in gen7_sampler_state.c; at this point the asymmetry just trips people up. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965/blorp: Don't set min_mag_neq bit in Gen6 SAMPLER_STATE.Kenneth Graunke2014-08-021-2/+0
| | | | | | | | | The "Min/Mag State Not Equal" bit is supposed to be set when the min/mag filters or address rounding modes differ. BLORP uses identical min/mag settings, so the bit should be unset. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* define GL_OES_standard_derivatives if extension is supportedKevin Rogovin2014-08-021-0/+2
| | | | | | | | | Define the macro GL_OES_standard_derivatives as 1 if the extension GL_OES_standard_derivatives is supported. V2 [Chris]: Correct trailing whitespace Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
* llvmpipe: don't store number of layers per levelRoland Scheidegger2014-08-012-78/+50
| | | | | | | | | | | | | | | | This could be recalculated, though it turns out the only use of it after resource allocation is for calculating whole resource size (for scene size accounting though that isn't quite ideal neither). Thus, instead just store the whole resource size and drop it (saving a couple bytes of storage per resource). It makes things simpler too. Note that for the accounting winsys resources always come back with size 0 but this is unchanged (we don't actually know the size in any case). Also reformat llvmpipe_texture_layout (drop unneded indentation). v2: adapt to previous changes. Reviewed-by: Jose Fonseca <jfonseca@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
* llvmpipe: integrate memory allocation into llvmpipe_texture_layoutRoland Scheidegger2014-08-011-45/+29
| | | | | | | | | | | | | | | Seems pointless to just duplicate some of the calculations (the calculation of actual memory used compared to what was predicted in llvmpipe_texture_layout actually could have differed slightly in some cases due to different alignment rules used though this should have been of no consequence). v2: keep the previous mip alignment of MAX2(64, cacheline). This was added for ARB_map_buffer_alignment - I'm not convinced it's needed for textures, but it was supposed to be cleanup without functional change. Also replace div with 64bit mul / comparison. Reviewed-by: Jose Fonseca <jfonseca@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
* llvmpipe: get rid of impossible code in alloc_image_dataRoland Scheidegger2014-08-011-26/+13
| | | | | | | Only used for non display target resources. Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
* i965/miptree: Layout 1D Array as 2D Array with height of 1Jordan Justen2014-08-011-0/+20
| | | | | | | | | | | | | | | | | | | 1D array miptrees were being laid out as a 2D texture with 1 slice. This happened due to the mesa core storing the 1D array slice count in the height field. On Intel hardware, we want to create a 2D array with a height of 1 for the 1D array case. Fixes assertion failure in piglit (gen6, gen8): spec/glsl-1.30/execution/tex-miplevel-selection textureOffset 1DArrayShadow In release builds of Mesa, this test was observed to cause a GPU hang on gen8. Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Cc: "10.2" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81450 Tested-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
* r600g: Implement gpu_shader5 textureGatherGlenn Kennard2014-08-013-7/+38
| | | | | | | | | | | | | | | Adds 0-3 textureGather component selection and non-constant offsets Caveat: 0 and 1 texture swizzles only work if textureGather component select is 3 or a component that does not exist in the sampler texture format. This is a hardware limitation, any other value returns 128/255=0.501961 for both 0 and 1. Passes all textureGather piglit tests on radeon 6670, except for those using 0/1 texture swizzles due to aforementioned reason. Signed-off-by: Glenn Kennard <glenn.kennard@gmail.com> Signed-off-by: Marek Olšák <marek.olsak@amd.com>
* mesa: Add missing atomic buffer bindings and unbindingsAditya Atluri2014-08-011-0/+31
| | | | Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* r600g/radeonsi: Prefer VRAM for CPU -> GPU streaming buffersMichel Dänzer2014-08-011-4/+11
| | | | Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* r600g/radeonsi: Reduce or even drop special treatment of persistent mappingsMichel Dänzer2014-08-011-4/+8
| | | | Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* target-helpers: Do not build kms_dri on libdrm-less platforms.Jon TURNEY2014-08-012-0/+3
| | | | | | | | Fix build since 3b176c441b7ddc5f7d2f891da3f76cf3c1814ce1 for dri_platform=none hosts. Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
* r600g: gpu_shader5 gl_SampleMaskIn supportGlenn Kennard2014-07-313-8/+41
| | | | | | | | Map TGSI_SEMANTIC_SAMPLEMASK to register/component. Enable face register when sample mask is needed by shader. Requires Evergreen/Cayman Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
* r600g: Implement gpu_shader5 integer opsGlenn Kennard2014-07-312-1/+191
| | | | Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
* r600g: Add IMUL_HI/UMUL_HI supportGlenn Kennard2014-07-311-6/+6
| | | | | | | Fixes fs-imulExtended, fs-imulExtended-only-msb, fs-umulExtended, fs-umulExtended-only-msb piglit tests. Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
* r600g: Implement GL_ARB_texture_query_lodGlenn Kennard2014-07-314-5/+16
| | | | | | | | Requires Evergreen or later v2 (Andreas): Update relnotes/10.3 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
* gbm: Log at least one dlerror() when we fail to open any drivers.Eric Anholt2014-07-301-0/+1
| | | | | | | | | | | | We don't want to log every single error (such as all the ones where the file wasn't even present in our list of search paths), but if you didn't find any driver, then seeing at least one error is useful (since the common case as a developer is a single DEFAULT_DRIVER_DIR or GBM_DRIVERS_PATH entry). v2: Rebase on swrast changes. Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
* gbm: Fix a debug log messageEric Anholt2014-07-301-1/+1
| | | | | Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
* gallium: Add a uif() helper function to complement fui()Eric Anholt2014-07-301-0/+8
| | | | | | | | | I found myself often wanting this when I'm printing out a uint32_t mapping of some GPU data, and I want to put in an interpretation of that value as a float. Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
* glapi: Do not use backtrace on DragonFly.Vinson Lee2014-07-301-1/+1
| | | | | | | | | | | | execinfo.h is not available on DragonFly. Fixes this build error. CC glapi_gentable.lo glapi_gentable.c:44:22: fatal error: execinfo.h: No such file or directory Signed-off-by: Vinson Lee <vlee@freedesktop.org> Reviewed-by: Brian Paul <brianp@vmware.com>
* gallivm: fix up out-of-bounds level when using conformant out-of-bound behaviorRoland Scheidegger2014-07-311-0/+1
| | | | | | | | | | | | | | | | | | | When using (d3d10) conformant out-of-bound behavior for texel fetching (currently always enabled) the level still needs to be set to a safe value even though the offset in the end won't get used because the level is used to look up the mip offset itself and the actual strides, which might otherwise crash. For simplicity, we'll use level 0 in this case (this ought to be safe, llvmpipe does not actually fill in level 0 information if first_level is larger, but some random strides / offsets shouldn't hurt as ultimately we always use offset 0 in this case). Fixes a crash in some in-house test where random huge levels appear in lp_build_fetch_texel() (the test actually uses level 0 always but if the fetching happens in a block with a execution mask random values may appear). CC: <mesa-stable@lists.freedesktop.org> Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
* dri: Add a new capabilities for drivers that can't share buffersGiovanni Campagna2014-07-307-12/+69
| | | | | | | | | | | | | | | | | | | The kms-dri swrast driver cannot share buffers using the GEM, so it must tell the loader to disable extensions relying on that, without disabling the image DRI extension altogether (which would prevent the loader from working at all). This requires a new gallium capability (which is queried on the pipe_screen and for swrast drivers it's forwarded to the winsys), and requires a new version of the DRI image extension. [Emil Velikov] - Rebased on top of gallium-dri megadrivers. - Drop PIPE_CAP_BUFFER_SHARE and sw_winsys::get_param hook. The can_share_buffer cap is set at InitScreen. We use a different InitScreen (and thus value for the cap) function for kms_dri, due to deeper differences originating from dri megadrivers. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* gallium: Add a dumb drm/kms winsys backed swrast providerGiovanni Campagna2014-07-3014-4/+564
| | | | | | | | | | | | | | | | | | | | | | Add a new winsys and target that can be used with a dri2 state tracker and loader instead of drisw. This allows to use gbm as a dri2/image loader and avoid the extra copy from the backbuffer to the shadow frontbuffer. The new driver is called "kms_swrast", and is loaded by gbm as a fallback, because it is only useful with the gbm platform (as no buffer sharing is possible) To force select the driver set the environment variable GBM_ALWAYS_SOFTWARE [Emil Velikov] - Rebase on top of gallium megadriver. - s/text/test/ in configure.ac (Spotted by Andreas Pokorny). - Add scons support for winsys/sw/kms-dri and fix the build. - Provide separate DriverAPI, due to different InitScreen hook. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* Add support for swrast to the DRM EGL platformGiovanni Campagna2014-07-305-48/+369
| | | | | | | | | | | | | | | | | | | | Turn GBM into a swrast loader (providing putimage/getimage backed by a dumb KMS buffer). This allows to run KMS+DRM GL applications (such as weston or mutter-wayland) unmodified on cards that don't have any client side HW acceleration component but that can do modeset (examples include simpledrm and qxl) [Emil Velikov] - Fix make check. - Split dri_open_driver() from dri_load_driver(). - Don't try to bind the swrast extensions when using dri. - Handle swrast->CreateNewScreen() failure. - strdup the driver_name, as it's free'd at destruction. - s/LIBGL_ALWAYS_SOFTWARE/GBM_ALWAYS_SOFTWARE/ - Move gbm_dri_bo_map/unmap to gbm_driiint.h. - Correct swrast fallback logic. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* st/gbm: don't segfault if the fail to create the screenEmil Velikov2014-07-301-1/+1
| | | | | | | Whenever dd_create_screen/pipe_loader_* fails, gdrm->dev may be NULL. Thus peeking inside the struct will lead to a crash. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* st/gbm: retrieve the driver-name via dd_driver_name()Emil Velikov2014-07-301-0/+6
| | | | | | | ... on static targets. Otherwise we'll crash badly as gdrm->dev is NULL when we try to copy the string driver_name. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* glsl/glcpp: rename ERROR to ERROR_TOKEN to fix MSVC buildBrian Paul2014-07-302-4/+4
| | | | | | | ERROR is a #define in the MSVC WinGDI.h header file. Add the _TOKEN suffix as we do for a few other lexer tokens. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* configure: Don't override user -g or -O options for debug buildsIan Romanick2014-07-291-2/+12
| | | | | | | | | | | | | | | | | | Principle of least surprise: --enable-debug should enable debugging. Ages ago, Mesa's build system only added -g in dri-debug builds (yay for the static Makefiles). If you forgot to change it (or wrap the build with custom scripts), you would often be disappointed when trying to gdb Mesa bugs. New developers, that may not yet have custom scripts, will have this same issue. I think we should enable experienced developers to do what they want, and make things easier for new developers. I already pass '-ggdb3 -O1' or '-ggdb3 -Og' for CFLAGS, and I don't want configure to change them for me. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
* glsl: Add flex options to eliminate the default ruleCarl Worth2014-07-291-10/+1
| | | | | | | | | | | | | | | | | | | | We've had bugs in the past where we have been inadvertently matching the default rule. Just as we did in the pre-processor in the previous commit, we can use: %option warn nodefault in the compiler to instruct flex to not generate the default rule, and further to warn if our set of rules could let any characters go unmatched. With this warning active, flex actually warns that the catch-all rule we recently added to the compiler could never be matched. Since that is all safely determined at compile time now, we can safely drop this run-time compiler error message, (as we do in this commit). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
* glsl/glcpp: Add flex options to eliminate the default rule.Carl Worth2014-07-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | We've had multiple bugs in the past where we have been inadvertently matching the default rule, (which we never want to do). We recently added a catch-all rule to avoid this, (and made this rule robust for future start conditions). Kristian pointed out that flex allows us to go one step better. This syntax: %option warn nodefault instructs flex to not generate the default rule at all. Further, flex will generate a warning at compile time if the set of rules we provide are inadequate, (such that it would be possible for the default rule to be matched). With this warning in place, I found that the catch-all rule was in fact missing something. The catch-all rule uses a pattern of "." which doesn't match newlines. So here we extend the newline-matching rule to all start conditions. That is enough to convince flex that it really doesn't need any default rule. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
* glsl/glcpp: Combine the two rules matching any characterCarl Worth2014-07-291-6/+6
| | | | | | | | | | Using a single rule here means that we can use the <*> syntax to match all start conditions. This makes the catch-all rule more robust against the addition of future start conditions, (no need to maintain an ever- growing list of start conditions for this rul). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
* glsl/glcpp: Alphabetize lists of start conditionsCarl Worth2014-07-291-3/+3
| | | | | | | | | | | | There is no behavioral change here. It's just easier to verify that lists of start conditions include all expected conditions when they appear in a consistent order. The <INITIAL> state is special, so it appears first in all lists. All others appear in alphabetical order. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
* glsl/glcpp: Add a catch-all rule for unexpected characters.Carl Worth2014-07-291-0/+13
| | | | | | | | | | | | | | | | | | 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 default rule in flex, which is that any unmatched character is implicitly matched and printed to stdout. To avoid this implicit matching and printing, here we add an explicit catch-all rule. If this rule ever matches it prints an internal compiler error. The correct response for any such error is fixing glcpp to handle the unexpected character in the correct way. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Treat carriage return as equivalent to line feed.Carl Worth2014-07-291-9/+8
| | | | | | | | | | | | | | | | | | | Previously, the '\r' character was not explicitly matched by any lexer rule. This means that glcpp would have been using the default flex rule to match '\r' characters, (where they would have been printed to stdout rather than actually correctly handled). With this commit, we treat '\r' as equivalent to '\n'. This is clearly an improvement the bogus printing to stdout. The resulting behavior is compliant with the GLSL specification for any source file that uses exclusively '\r' or '\n' to separate lines. For shaders that use a multiple-character line separator, (such as "\r\n"), glcpp won't be precisely compliant with the specification, (treating these as two newline characters rather than one), but this should not introduce any semantic changes to the shader programs. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Add test for a multi-line comment within an #if 0 blockCarl Worth2014-07-292-0/+14
| | | | | | | | | | | | | | | | | | | 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 on through all the subsequent rules while still in the NEWLINE_CATCHUP start condition, (which then triggered the internal-compiler-error catch-all rule). What is intended is for the return of the NEWLINE token to start a new iteration of the lexer loop, at which time the NEWLINE_CATCHUP-handling code will reset from the <NEWLINE_CATCHUP> to the <INITIAL> start condition. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Test that macro parameters substitute immediately after periodsCarl Worth2014-07-292-0/+8
| | | | | | | | | | | | 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 piglit tests that I originally found this issue. Here, I'm adding a test to "make check" to ensure that this behavior remains correct. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Add (non)-support for ++ and -- operatorsCarl Worth2014-07-294-1/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 looks like it is strictly adding support for these operators. And it is supporting them as far as passing them through to the subsequent compiler, (which was already happening anyway). What's less apparent in the commit is that with these tokens now being lexed, but with no change to the grammar for preprocessor expressions, these operators will now trigger errors there. A new "make check" test is added to verify the desired behavior. This commit fixes the following Khronos GLES3 CTS test: invalid_op_1_vertex invalid_op_1_fragment invalid_op_2_vertex invalid_op_2_fragment Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Emit error for duplicate parameter name in function-like macroCarl Worth2014-07-293-0/+35
| | | | | | | | | | | | | | | | | 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 invalid_function_definitions.unique_param_name_fragment Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Add an explanatory comment for "loc != NULL" checkCarl Worth2014-07-291-0/+4
| | | | | | | | | | | 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 comment to help the next reader. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Drop the HASH_ prefix from token names like HASH_IFCarl Worth2014-07-292-38/+39
| | | | | | | | | | | | | | | | | | | 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 for the same reason we use HASH_TOKEN instead of HASH, we also use DEFINE_TOKEN instead of DEFINE to avoid a conflict with the <DEFINE> start condition in the lexer.) There should be no behavioral change from this commit. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl: Properly lex extra tokens when handling # directives.Kenneth Graunke2014-07-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 commit in place, we generate the desired syntax error. This manifested as a weird bug where shaders with semicolons after extension directives, such as: #extension GL_foo_bar : enable; would print semicolons to the screen, but otherwise compile just fine (even though this is illegal). Fixes Piglit's extension-semicolon.frag test. This also fixes the following Khronos GLES3 conformance tests, (and for real this time): invalid_char_in_name_vertex invalid_char_in_name_fragment Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Carl Worth <cworth@cworth.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl: Add an internal-error catch-all ruleCarl Worth2014-07-291-0/+13
| | | | | | | | | | | | | | | | This is to avoid the default, silent flex rule which simply prints the character to stdout. For the following Khronos GLES3 conformance tests: invalid_char_in_name_vertex invalid_char_in_name_fragment With this commit, these tests now report Pass where they previously reported Fail, but Mesa isn't behaving correctly yet. It's now reporting the internal error where what is really desired is a syntax error. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Correctly parse directives with intervening commentsCarl Worth2014-07-2916-110/+242
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 directives. Our implementation does not use an actual separate phase for comment removal, so some extra care is necessary to correctly parse this. What we want is for '#' to introduce a directive iff it is the first token on a line, (ignoring whitespace and comments). Previously, we had a lexical rule that worked only for whitespace (not comments) with the following regular expression to find a directive-introducing '#' at the beginning of a line: HASH ^{HSPACE}*#{HSPACE}* In this commit, we switch to instead use a simple literal match of '#' to return a HASH_TOKEN token and add a new <HASH> start condition for whenever the HASH_TOKEN is the first non-space token of a line. This requires the addition of the new bit of state: first_non_space_token_this_line. This approach has a couple of implications on the glcpp parser: 1. The parser now sees two separate tokens, (such as HASH_TOKEN and HASH_DEFINE) where it previously saw one token (HASH_DEFINE) for the sequence "#define". This is a straightforward change throughout the grammar. 2. The parser may now see a SPACE token before the HASH_TOKEN token of a directive. Previously the lexical regular expression for {HASH} would eat up the space and there would be no SPACE token. This second implication is a bit of a nuisance for the parser. It causes a SPACE token to appear in a production of the grammar with the following two definitions of a control_line: control_line SPACE control_line This is really ugly, since normally a space would simply be a token separator, so it wouldn't appear in the tokens of a production. This leads to a further problem with interleaved spaces and comments: /* ... */ /* ... */ #define /* ..*/ For this, we must not return several consecutive SPACE tokens, or else we would need an arbitrary number of new productions: SPACE SPACE control_line SPACE SPACE SPACE control_line ad nauseam To avoid this problem, in this commit we also change the lexer to emit only a single SPACE token for any series of consecutive spaces, (whether from actual whitespace or comments). For this compression, we add a new bit of parser state: last_token_was_space. And we also update the expected results of all necessary test cases for the new compression of space tokens. Fortunately, the compression of spaces should not lead to any semantic changes in terms of what the eventual GLSL compiler sees. So there's a lot happening in this commit, (particularly for such a tiny feature). But fortunately, the lexer itself is looking cleaner than ever. The only ugly bit is all the state updating, but it is at least isolated to a single shared function. Of course, a new "make check" test is added for the new feature, (directives with comments and whitespace interleaved in many combinations). And this commit fixes the following Khronos GLES3 CTS tests: function_definition_with_comments_vertex function_definition_with_comments_fragment Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Rename HASH token to HASH_TOKENCarl Worth2014-07-292-5/+8
| | | | | | | | | | | 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 implemented as equivalent numeric types so the collision is undetected at compile time and simply leads to unpredictable behavior at run time.) Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Don't use start-condition stack when switching to/from <DEFINE>Carl Worth2014-07-291-3/+3
| | | | | | | | | | | | | | | | | | | | | 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 are planning to soon add a start condition for <HASH> with the following semantics: <HASH>: We just saw a directive-introducing '#' <DEFINE>: We just saw "#define" starting a directive With these two start conditions in place, the only correct behavior is to leave <DEFINE> by returning to <INITIAL>. But the old push/pop code would have returned to the <HASH> start condition which would then cause an error when the next directive-introducing '#' would be encountered. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Add a -d/--debug option to the standalone glcpp programCarl Worth2014-07-292-1/+7
| | | | | | | | | 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). Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Fix off-by-one error in column in first-line error messagesCarl Worth2014-07-2917-19/+19
| | | | | | | | | | | | | | 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 column 1). With this extremely minor change, many of the .expected files are updated such that error messages for the first line now have the correct column number in them. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Minor tweak to wording of error messageCarl Worth2014-07-293-3/+3
| | | | | | It makes more sense to print the directive name with the preceding '#'. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>