summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* mesa: Use MAX2 to calculate maximum uniform elementIan Romanick2014-08-071-3/+1
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Have validate_uniform_parameters return the gl_uniform_storage pointerIan Romanick2014-08-071-31/+30
| | | | | | | | This simplifies all the callers, and it enables the removal of one of the function parameters. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl/glcpp: Rename one test to avoid a duplicate test numberCarl Worth2014-08-072-0/+0
| | | | | | | | | | | With two tests both numbered 118, there was a confusing off-by-two difference between the last test number and the total number of tests (as reported by glcpp-test). With this rename, there's only an off-by-one difference left, (which is easy to understand given the zero-based test numbering). Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Fix handling of commas that result from macro expansionCarl Worth2014-08-073-12/+45
| | | | | | | | | | | | | | | | | | | | | | | | Here is some additional stress testing of nested macros where the expansion of macros involves commas, (and whether those commas are interpreted as argument separators or not in subsequent function-like macro calls). Credit to the GCC documentation that directed my attention toward this issue: https://gcc.gnu.org/onlinedocs/gcc-3.2/cpp/Argument-Prescan.html Fixing the bug required only removing code from glcpp. When first testing the details of expansions involving commas, I had come to the mistaken conclusion that an expanded comma should never be treated as an argument separator, (so had introduced the rather ugly COMMA_FINAL token to represent this). In fact, an expanded comma should be treated as a separator, (as tested here), and this treatment can be avoided by judicious use of parentheses (as also tested here). With this simple removal of the COMMA_FINAL token, the behavior of glcpp matches that of gcc's preprocessor for all of these hairy cases. Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Integrate recent glcpp-test-cr-lf test into "make check"Carl Worth2014-08-074-13/+42
| | | | | | | | | | | | Beyond just listing this in the TESTS variable in Makefile.am, only minor changes were needed to make this work. The primary issue is that the build system runs the test script from a different directory than the script itself. So we have to use the $srcdir variable to find the test input files. Using $srcdir in this way also ensures that this test works when using an out-of-tree build. Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Fix glcpp-test to correctly extract test-specific argumentsCarl Worth2014-08-071-1/+1
| | | | | | | | | | | | | | | | | | | | | The (optional) test-specific command-line arguments to be passed to glcpp are embedded within the source files of some tests, and glcpp-test uses grep to extract them. Of course, grep is line-based and looks for the native line-separator to determine line boundaries. So, for files using non-native line separators, grep was getting quite confused and passing bogus arguments to glcpp. Fix this by canonical-izing the line separators in the source file prior to using grep. With this commit, the glcpp-test-cr-lf tests pass entirely: \r: 143/143 tests pass \r\n: 143/143 tests pass \n\r: 143/143 tests pass Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Fix line-continuation code to handle multiple newline flavorsCarl Worth2014-08-071-9/+87
| | | | | | | | | | | | | | | | | | | | | | | | | 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 first character of the line separator. Also, when re-inserting newlines to replace collapsed newlines, we carefully insert newlines of the same flavor. With this commit, almost all remaining test are fixed as tested by glcpp-test-cr-lf: \r: 142/143 tests pass \r\n: 142/143 tests pass \n\r: 143/143 tests pass (The only remaining failures have nothing to do with the actual pre-processor code, but are due to a bug in the way the test suite uses grep to try to extract test-specific command-line options from the source files.) Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Don't include any newline characters in #error tokenCarl Worth2014-08-071-1/+1
| | | | | | | | | | | | | | | | | | Some tests were failing because the message printed by #error was including a '\r' character from the source file in its output. This is easily avoided by fixing the regular expression for #error to never include any of the possible newline characters, (neither '\r' nor '\n'). With this commit 2 tests are fixed for each of the '\r' and '\r\n' cases. Current results after the commit are: \r: 137/143 tests pass \r\n 142/143 tests pass \n\r: 139/143 tests pass Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Treat CR+LF pair as a single newlineCarl Worth2014-08-072-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GLSL specification says that either carriage-return, line-feed, or both together can be used to terminate lines. Further, it says that when used together, the pair of terminators shall be interpreted as a single line. This final requirement has not been respected by glcpp up until now, (it has been emitting two newlines for every CR+LF pair). Here, we fix the lexer by using a regular expression for NEWLINE that eats up both "\r\n" (or even "\n\r") if possible before also considering a single '\n' or a single '\r' as a line terminator. Before this commit, the test results are as follows: \r: 135/143 tests pass \r\n: 4/143 tests pass \n\r: 4/143 tests pass After this commit, the test results are as follows: \r: 135/143 tests pass \r\n: 140/143 tests pass \n\r: 139/143 tests pass So, obviously, a dramatic improvement. Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Add test script for testing various line-termination charactersCarl Worth2014-08-072-11/+137
| | | | | | | | | | | | | | | | | | | | | | The GLSL specification has a very broad definition of what is a newline. Namely, it can be the carriage-return character, '\r', the newline character, '\n', or any combination of the two, (though in combination, the two are treated as a single newline). Here, we add a new test-runner, glcpp-test-cr-lf, that, for each possible line-termination combination, runs through the existing test suite with all source files modified to use those line-termination characters. Instead of using the .expected files for this, this script assumes that the regular test suite has been run already and expects the output to match the .out files. This avoids getting 4 test failures for any one bug, and instead will hopefully only report bugs actually related to the line-termination characters. The new testing is not yet integrated into "make check". For that, some munging of the testdir option will be necessary, (to support "make check" with out-of-tree builds). For now, the scripts can just be run directly by hand. Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Fix for macros that expand to include "defined" operatorsCarl Worth2014-08-073-45/+387
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this commit, the following snippet would trigger an error in glcpp: #define FOO defined BAR #if FOO #endif The problem was that support for the "defined" operator was implemented within the grammar, (where the parser was parsing the tokens of the condition itself). But what is required is to interpret the "defined" operator that results after macro expansion is performed. I could not find any fix for this case by modifying the grammar alone. The difficulty is that outside of the grammar we already have a recursive function that performs macro expansion (_glcpp_parser_expand_token_list) and that function itself must be augmented to be made aware of the semantics of the "defined" operator. The reason we can't simply handle "defined" outside of the recursive expansion function is that not only must we scan for any "defined" operators in the original condition (before any macro expansion occurs); but at each level of the recursive expansion, we must again scan the list of tokens resulting from expansion and handle "defined" before entering the next level of recursion to further expand macros. And of course, all of this is context dependent. The evaluation of "defined" operators must only happen when we are handling preprocessor conditionals, (#if and #elif) and not when performing any other expansion, (such as in the main body). To implement this, we add a new "mode" parameter to all of the expansion functions to specify whether resulting DEFINED tokens should be evaluated or ignored. One side benefit of this change is that an ugly wart in the grammar is removed. We previously had "conditional_token" and "conditional_tokens" productions that were basically copies of "pp_token" and "pp_tokens" but with added productions for the various forms of DEFINED operators. With the new code here, those ugly copy-and-paste productions are eliminated from the grammar. A new "make check" test is added to stress-test the code here. This commit fixes the following Khronos GLES3 CTS tests: conditional_inclusion.basic_2_vertex conditional_inclusion.basic_2_fragment Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Swallow empty #pragma directives.Carl Worth2014-08-072-1/+7
| | | | | | | | | | | | | | Previously, we were passing these through, just like any other pragma. But the downstream compiler was tripping up on them. It seems easier to swallow these in the preprocessor and not pass them on at all rather than fixing the downstream compiler. This fixes the following Khronos GLES3 CTS tests: preprocessor.pragmas.pragma_vertex preprocessor.pragmas.pragma_fragment Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Fix #pragma to not over-increment the line-number countCarl Worth2014-08-073-2/+12
| | | | | | | | | | | | | | Previously, the #pragma directive was swallowing an entire line, (including the final newline). At that time it was appropriate for it to increment the line count. More recently, our handling of #pragma changed to not include the newline. But the code to increment yylineno stuck around. This was causing __LINE__ to be increased by one more than desired for every #pragma. Remove the bogus, extra increment, and add a test for this case. Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Add testing for null directives with spaces and commentsCarl Worth2014-08-072-0/+18
| | | | | | | | This new "make check" test stresses out the support from the last two commits, (to esnure that '#' is correctly interpreted as the null directives, regardless of any whitespace or comments on the same line). Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Fix NULL directives when followed by a single-line commentCarl Worth2014-08-071-1/+1
| | | | | | | | | | | | | | | | | | | This is the fix for the following line: # // comment to ignore here According to the translation-phase rules, the comment should be removed before the preprocessor looks to interpret the null directive. So in our implementation we must explicitly look for single-line comments in the <HASH> start condition as well. This commit fixes the following Khronos GLES3 CTS tests: null_directive_vertex null_directive_fragment Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Add tests for #define followed by commentsCarl Worth2014-08-072-2/+8
| | | | | | | This simply tests the previous commit, (that #define followed by a comment will still generate the expected "#define without macro name" error message). Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Allow single-line comments immediately after #defineCarl Worth2014-08-071-1/+1
| | | | | | | | | | | | | | | | We were already correctly supporting single-line comments in case like: #define FOO bar // comment here... The new support added here is simply for the none-too-useful: #define // comment instead of macro name With this commit, this line will now give the expected "#define without macro name" error message instead of the lexer just going off into the weeds. Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Add test for "#define without macro name"Carl Worth2014-08-072-0/+4
| | | | | | | | This ensures that the previous commit indeed generates the expected error message when a "#define" directive is not followed by anything except for a newline. Reviewed-by: Ian Romanick <[email protected]>
* glsl/glcpp: Add explicit error for "#define without macro name"Carl Worth2014-08-073-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | Previously, glcpp would emit an error like this if <EOF> happened to occur immediately after the "#define", but in general would just get confused, (leading to un-helpful error messages). To fix things to generate a clean error message, we do a few things: 1. Don't require horizontal whitespace immediately after #define 2. Add a production for the error case, (DEFINE_TOKEN followed immediately by a NEWLINE token). 3. Make the lexer reset to the <INITIAL> state after every NEWLINE. This 3rd point prevents the lexer from getting so confused and generating further spurious errors in the file because it was stuck in the <DEFINE> start condition. We also drop the similar error message from the <EOF> rule since the newly-added rule will have already printed the error message. Reviewed-by: Ian Romanick <[email protected]>
* i965/vec4: Remove unused emit_bool_comparison method.Matt Turner2014-08-072-15/+0
| | | | | | Apparently unused since it was added in commit af3c9803. Reviewed-by: Anuj Phogat <[email protected]>
* mesa: Drop USE_IEEE define.Matt Turner2014-08-074-48/+4
| | | | | | | | | | | | | I think OpenVMS was the only platform that Mesa ran on that used a non-IEEE representation for floats. We removed OpenVMS support a while back, and this should alleviate the need to continue updating the this-platform-uses-IEEE list. The one bit of this patch that needs review is the IS_INF_OR_NAN, because I'm not sure if MSVC supports isfinite. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82268 Reviewed-by: Brian Paul <[email protected]>
* mesa: Group gl_system_value values by the stage where they existIan Romanick2014-08-072-9/+35
| | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* glsl_to_tgsi: Assert that the _mesa_sysval_to_semantic mapping is correctIan Romanick2014-08-071-0/+15
| | | | | | | | | | | | | Future patches will rearrange the values in gl_system_value, and I want to catch errors. Designated initializers would make all of this unnecessary. v2: Don't use STATIC_ASSERT. Not only does it not work, but GCC doesn't tell you that it's not going to work. Thanks for nothing! Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* mesa/st: Only one copy of mesa_sysval_to_semanticIan Romanick2014-08-073-11/+5
| | | | | | | | | Future patches will necessitate changes to the table, and I only want to update one. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* glsl_to_tgsi: Constify mesa_sysval_to_semanticIan Romanick2014-08-071-1/+1
| | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* i965/clip: Fix brw_clip_unfilled.c/compute_offset's assembly.Kenneth Graunke2014-08-071-3/+3
| | | | | | | | | | | | | | Due to the destination register width of 1 or 2, these instructions get ExecSize 1 or 2. But dir and offset (used as src0) are both registers of width 4, violating the execsize >= width assertion. I honestly don't think this could have ever worked. Fixes Piglit's polygon-offset and polygon-mode-offset tests on Gen4-5. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70441 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* glsl: support unsigned increment in ir_loop controlsTapani Pälli2014-08-071-3/+14
| | | | | | | | | | Current version can create ir_expression where operands have different base type, patch adds support for unsigned type. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Tested-by: Michel Dänzer <[email protected]> https://bugs.freedesktop.org/show_bug.cgi?id=80880
* mesa/formats: Fix the size of ETC2_SRGB8_PUNCHTHROUGH_ALPHA1Jason Ekstrand2014-08-061-1/+1
| | | | | Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* mesa/formats: Use the correct swizzle parameter for the 11-bit EAC formatsJason Ekstrand2014-08-061-4/+4
| | | | | | | Red-only formats should be x001 and RG formats should be xy01. Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* draw: fix clipvertex trouble if position comes from gsRoland Scheidegger2014-08-061-1/+5
| | | | | | | | | | | | | | | If the vertex shader has no position but the gs has, the clipvertex output was -1 (because it's the same as vs position in this case if there's no explicit clipvertex output). This caused crashes (or assertion failures) in clipping since in the end position (which came from gs) was different from cv (-1) and we then tried to use the bogus cv input. Rather than just test for -1 cv value in clipping, make it explicitly return the position output of the gs instead which seems cleaner (since we really don't want to use the clipvertex value from the vs (it could be a valid value in the (unsupported) case of vs writing clipvertex but still using a gs). This fixes piglit shader_runner clip-distance-out-values.shader_test. Reviewed-by: Zack Rusin <[email protected]>
* draw: don't run pipeline stages when gs has no position outputRoland Scheidegger2014-08-062-1/+5
| | | | | | | | | | | | | | | | The clip stage may crash if there's no position output, for this reason code was added to avoid running the pipeline stages in this case (c7c7186045ec617c53f7899280cbe12e59503e4d). However, this failed to actually work when there was a geometry shader, since unlike the vertex shader it did not initialize the position output to -1, hence the code trying to detect this didn't trigger. So simply initialize the position output to -1 just like the vs does. This fixes piglit glsl-1.50-transform-feedback-type-and-size (segfault->pass). clip-distance-out-values.shader_test goes from segfault to assertion failure, suggesting more fixes are needed, no other piglit changes. Reviewed-by: Dave Airlie <[email protected]> Reviewed-by: Zack Rusin <[email protected]>
* dri/xmlconfig: s/uint/unsigned int/Vinson Lee2014-08-051-2/+2
| | | | | | | | | | | | | | | | This patch fixes this build error on Mac OS X. ./xmlconfig.h:61:5: error: unknown type name 'uint'; did you mean 'int'? uint nRanges; /**< \brief Number of ranges */ ^~~~ int ./xmlconfig.h:79:5: error: unknown type name 'uint'; did you mean 'int'? uint tableSize; ^~~~ int Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa include stdint.h in formats.hBrian Paul2014-08-051-0/+1
| | | | | To get uint8_t type, to fix MSVC build. Trivial.
* mesa/texstore: Add a generic rgba integer texture upload pathJason Ekstrand2014-08-051-479/+73
| | | | | | | | | | Again, we delete a lot of functions that aren't really doing anything interesting anymore. v2: Comment the texstore_rgba_integer function Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa/texstore: Add a generic float/normalized rgba texture upload pathJason Ekstrand2014-08-051-1906/+98
| | | | | | | | | | This commit also removes a bunch of functions which aren't doing anything more interesting than the general path does. v2: Better comment the texstore_via_float function Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa/texstore: Use _mesa_swizzle_and_convert when possibleJason Ekstrand2014-08-051-15/+171
| | | | | | | | | | This should be both faster and more accurate than our general slow-path of converting everything to float. v2: Add a comment to top of the texstore_swizzle function Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* main/texstore: Split texture storage into three functionsJason Ekstrand2014-08-051-71/+100
| | | | | | | | | | | | This commit splits the texture storage into three functions: texstore_depth_stencil, texstore_compressed, and texstore_rgba. Right now this split seems artificial since we just have one function pointer per format and there is no difference between these three categories. However, this split makes it much easier to write a more general function upload path for one of these categories than the current function pointers. Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa/format_utils: Add a function to convert a mesa_format to an array formatJason Ekstrand2014-08-052-0/+111
| | | | | | | | | | | | | This commits adds the _mesa_format_to_array function that determines if the given format can be represented as an array format and computes the array format parameters. This is a direct helper function for using _mesa_swizzle_and_convert v2: Better documentation and commit message v3: Fixed a potential segfault from an invalid endianness swizzle Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa/format_utils: Add a general format conversion functionJason Ekstrand2014-08-053-0/+912
| | | | | | | | | | | | | | | | | | Most format conversion operations required by GL can be performed by converting one channel at a time, shuffling the channels around, and optionally filling missing channels with zeros and ones. This adds a function to do just that in a general, yet efficient, way. v2: * Add better comments including full docs for functions * Don't use __typeof__ * Use inline helpers instead of writing out conversions by hand, * Force full loop unrolling for better performance v3: Add another set of parens around the MAX_INT macro Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa/imports: Add a _mesa_half_is_negative helper functionJason Ekstrand2014-08-051-0/+5
| | | | | Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa/formats: Add layout and swizzle informationJason Ekstrand2014-08-053-0/+86
| | | | | | | v2: Move the MESA_FORMAT_SWIZZLE enum to the top of the file Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa/formats: Remove IndexBitsJason Ekstrand2014-08-052-3/+2
| | | | | | | | Mesa hasn't supported color-indexed textures for some time. This is 0 for all texture formats, so we don't need to store it. Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa/formats: Autogenerate the format_info structure from a CSV fileJason Ekstrand2014-08-054-1738/+19
| | | | | | | | | | | | | | | Instead of a having all of the format metadata in a gigantic hard-to-edit array of type struct format_info, we now have a human-readable CSV file. The CSV file also contains more format information than the format_info struct contained so we can potentially make format_info more detailed later. The python to generate the format information was added the previous commit. This commit turns it on in both automake and scons builds. v2: Split into two commits and stuff to generate format_info.c from scons Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa/main: Add python code to generate the format_info structureJason Ekstrand2014-08-051-0/+181
| | | | | | | | This adds a python script called format_info.py that is used to generate a single format_info.c file that contains the filled-out format_info array. Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Add python to parse the formats CSV fileJason Ekstrand2014-08-051-0/+521
| | | | | | | | | | | | | | | The basic concept for the format parser was taken from the format CSV parser in gallium/auxilliary/util. However, this one has been altered in a number of ways: * Removed big endian vs. little endian stuff (mesa doesn't need it) * Better documentation: Almost every method has a full docstring * An actual Swizzle class with methods for composition and inverses * Over-all cleaner (in my opinion) implementation and class interactions * A few bug fixes Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Add a format description CSV fileJason Ekstrand2014-08-051-0/+282
| | | | | Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* util/tests/hash_table: Link against libmesautil instead of libmesaJason Ekstrand2014-08-051-4/+2
| | | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82159 Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* st/mesa: adjust Z coordinates for quad clearingBrian Paul2014-08-051-2/+5
| | | | | | | | | | | | | | | | | | | | | | Specify the quad's Z position in clip coordinate space, not normalized Z space. Use viewport scale, translation = 0.5, 0.5. Before, we were specifying the quad's Z position in [0,1] and using viewport scale=1.0, translate=0.0. That works fine, unless your driver needs to work in clip coordinate space and needs to reconstruct viewport near/far values from the scale/translation factors. The VMware svga driver falls into that category. When we did that reconstruction we wound up with near=-1 and far=1 which are outside the limits of [0,1]. In some cases, this caused the quad to be drawn at the wrong depth. In other cases it was clipped away. Fixes some scissored depth clears with VMware driver. This should have no effect on other drivers. We're already using these values for the glBitmap and glDraw/CopyPixels code. Reviewed-by: Roland Scheidegger <[email protected]>
* mesa: make vertex array type error checking a little more efficientBrian Paul2014-08-052-30/+59
| | | | | | | Compute the bitmask of supported array types once instead of every time we call a GL vertex array function. Reviewed-by: Matthew McClure <[email protected]>
* glsl_to_tgsi: Fix typo shader_program -> shaderMichel Dänzer2014-08-051-2/+1
| | | | | | | | | | | This was a regression introduced by commit f4b0ab7afd83c811329211eae8167c9bf238870c ('st/mesa: fix incorrect size of UBO declarations') which caused an assertion failure while compiling shaders of e.g. UE4 demos. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81834 Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Brian Paul <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 17:01:50 +0000