summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* glsl: Add IR lisp for GLSL ES 3.00 pack/unpack functionsChad Versace2013-01-247-7/+43
| | | | | | | | | | | | | | For each of the following functions, add a declaration to builtins/profiles/300es.glsl and create new file builtins/ir/${funcname}.ir: packSnorm2x16 unpackSnorm2x16 packUnorm2x16 unpackUnorm2x16 packHalf2x16 unpackHalf2x16 Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Matt Tuner <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* glsl: Fix typo in commentChad Versace2013-01-241-1/+1
| | | | | | | | | s/num_operands()/get_num_operands()/ Discovered because Eclipse failed to resolve the false reference. Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* i965/disasm: Fix horizontal stride of dest registersChad Versace2013-01-241-3/+6
| | | | | | | | | | The bug: The printed horizontal stride was the numerical value of the BRW_HORIZONTAL_$N enum. The fix: Translate the enum before printing. Note: This is a candidate for the stable releases. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Fix glCopyTexSubImage on buffers whose width >= 32kbytesPaul Berry2013-01-241-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When possible, glCopyTexSubImage calls are performed using the hardware blitter. However, according to the Ivy Bridge PRM, Vol1 Part4, section 1.2.1.2 (Graphics Data Size Limitations): The BLT engine is capable of transferring very large quantities of graphics data. Any graphics data read from and written to the destination is permitted to represent a number of pixels that occupies up to 65,536 scan lines and up to 32,768 bytes per scan line at the destination. The maximum number of pixels that may be represented per scan line’s worth of graphics data depends on the color depth. With an RGBA32F color buffer (which has 16 bytes per pixel) this imposes a maximum width of 2048 pixels. Other pixel formats have accordingly larger limits. To make matters worse, if the pitch of the buffer is 32k or greater, intel_copy_texsubimage's call to intelEmitCopyBlit will overflow intelEmitCopyBlit's src_pitch and dst_pitch parameters (which are 16-bit signed integers). We can conveniently avoid both problems by avoiding use of the blitter when the miptree's pitch is >= 32k. Fixes gles3conform "framebuffer_blit_functionality_magnifying_blit" tests when the buffer width is equal to 8192. Note: this is very similar to the recent patch "intel: Fix ReadPixels on buffers whose width >= 32kbytes" except that it applies to glCopyTexSubImage instead of glReadPixels. In a future patch it would be nice to refactor the code so that (a) overflow is avoided, and (b) intelEmitCopyBlit is responsible for checking whether the blitter can handle the width, so that all callers of intelEmitCopyBlit work properly, rather than just these two. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Allow varying structs in GLSL ES 3.00 and GLSL 1.50.Paul Berry2013-01-241-4/+4
| | | | | | | | | | | | | | | | | | | | Previously I thought that varying structs had been added to GLSL ES 3.00 by mistake, because chapter 11 of the GLSL ES 3.00 spec ("Counting of Inputs and Outputs") failed to mention how structs should be handled. Khronos has clarified (https://cvs.khronos.org/bugzilla/show_bug.cgi?id=9828) that varying structs are indeed required, and that chapter 11 will be modified to indicate that the minimal reference packing algorithm flattens varying structs to their individual components. Mesa doesn't flatten varying structs to their individual components, but this is ok, since it packs varyings of all kinds with no wasted space at all (except where this is impossible due to differing interpolation modes), so it will outperform the minimal reference packing algorithm in all but the most pathological cases. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Disable transform feedback of varying structs.Paul Berry2013-01-241-1/+10
| | | | | | | | | | | | | | | | | | | | | | It is not clear from the GLSL ES 3.00 spec how transform feedback is supposed to apply to varying structs: - There is no specification for how the structure is to be packed when it is recorded into the transform feedback buffer. - There is no reasonable value for GetTransformFeedbackVarying to return as the "type" of the variable. We currently have a Khronos bug requesting clarification on how this feature is supposed to work (https://cvs.khronos.org/bugzilla/show_bug.cgi?id=9856). This patch just disables transform feedback of varying structs for now; we can implement the proper behaviour once we find out from Khronos what it is. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Update lower_packed_varyings to handle varying structs.Paul Berry2013-01-241-4/+18
| | | | | | | | | | | | | | | This patch adds code to lower_packed_varyings to handle varyings of type struct. Varying structs are currently packed in the most naive possible way (in declaration order, with no gaps), so there is a potential loss of runtime efficiency. In a later patch it would be nice to replace this with a "flattening" approach (wherein a varying struct is flattened to individual varyings corresponding to each of its structure elements), so that the linker can align each structure element independently. However, that would require a significantly more complex implementation. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Generalize compute_packing_order for varying structs.Paul Berry2013-01-241-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch paves the way for allowing varying structs by generalizing varying_matches::compute_packing_order to handle any type of varying. Previously, we packed in the order (vec4, vec2, float, vec3), with matrices being packed according to the size of their columns. Now, we pack everything according to its number of components mod 4, in the order (0, 2, 1, 3). There is no behavioural change for vectors. Matrices are now packed slightly differently: - mat2x2 gets assigned PACKING_ORDER_VEC4 instead of PACKING_ORDER_VEC2. This is slightly better, because it guarantees that the matrix occupies a single varying slot. - mat2x3 gets assigned PACKING_ORDER_VEC2 instead of PACKING_ORDER_VEC3. This is kind of a wash. Previously, mat2x3 had a 25% chance of having neither of its columns double parked, a 50% chance of having exactly one of its columns double parked, and a 25% chance of having both of its columns double parked. Now it always has exactly one of its columns double parked. - mat3x3 gets assigned PACKING_ORDER_SCALAR instead of PACKING_ORDER_VEC3. This doesn't affect much, since in both cases there is no guarantee of how the matrix will be aligned. - mat4x2 gets assigned PACKING_ORDER_VEC4 instead of PACKING_ORDER_VEC2. This is slightly better for the same reason as in mat2x2. - mat4x3 gets assigned PACKING_ORDER_VEC4 instead of PACKING_ORDER_VEC3. This is slightly better for the same reason as in mat2x2. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Disable structure splitting for shader ins/outs.Paul Berry2013-01-241-1/+2
| | | | | | | | | | | | Previously, it didn't matter whether structure splitting tried to split shader ins/outs, because structs were prohibited from being used for shader ins/outs. However, GLSL 3.00 ES supports varying structs. In order for varying structs to work, we need to make sure that structure splitting doesn't get applied to them, because if it does, then the linker won't be able to match up varyings properly. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Eliminate ambiguity between function ins/outs and shader ins/outsPaul Berry2013-01-2431-193/+205
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces the three ir_variable_mode enums: - ir_var_in - ir_var_out - ir_var_inout with the following five: - ir_var_shader_in - ir_var_shader_out - ir_var_function_in - ir_var_function_out - ir_var_function_inout This eliminates a frustrating ambiguity: it used to be impossible to tell whether an ir_var_{in,out} variable was a shader in/out or a function in/out without seeing where the variable was declared in the IR. This complicated some optimization and lowering passes, and would have become a problem for implementing varying structs. In the lisp-style serialization of GLSL IR to strings performed by ir_print_visitor.cpp and ir_reader.cpp, I've retained the names "in", "out", and "inout" for function parameters, to avoid introducing code churn to the src/glsl/builtins/ir/ directory. Note: a couple of comments in the code seemed to indicate that we were planning for a possible future in which geometry shaders could have shader-scope inout variables. Our GLSL grammar rejects shader-scope inout variables, and I've been unable to find any evidence in the GLSL standards documents (or extensions) that this will ever be allowed, so I've eliminated these comments. Reviewed-by: Carl Worth <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Clean up case statement in builtin_variables.cpp's add_variable.Paul Berry2013-01-241-2/+4
| | | | | | | | | | | The case statement purported to handle the addition of ir_var_const_in and ir_var_inout builtin variables. But no such variables exist. This patch removes the unnecessary cases, and adds a comment explaining why they're not needed. Reviewed-by: Carl Worth <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/vs: Do headerless texturing for texelFetchOffset().Kenneth Graunke2013-01-241-2/+4
| | | | | | | | | For texelFetchOffset(), we just add the texel offsets to the coordinate rather than using the message header's offset fields. So we don't actually need a header on Gen5+. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* libgl-xlib/build: Link with C++ when LLVM is usedMatt Turner2013-01-241-1/+9
| | | | | | Also link-in libX11 and libXext. Tested-by: Brian Paul <[email protected]>
* intel: Fix ReadPixels on buffers whose width >= 32kbytesPaul Berry2013-01-241-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When possible, glReadPixels calls are performed using the hardware blitter. However, according to the Ivy Bridge PRM, Vol1 Part4, section 1.2.1.2 (Graphics Data Size Limitations): The BLT engine is capable of transferring very large quantities of graphics data. Any graphics data read from and written to the destination is permitted to represent a number of pixels that occupies up to 65,536 scan lines and up to 32,768 bytes per scan line at the destination. The maximum number of pixels that may be represented per scan line’s worth of graphics data depends on the color depth. With an RGBA32F color buffer (which has 16 bytes per pixel) this imposes a maximum width of 2048 pixels. To make matters worse, if the pitch of the buffer is 32k or greater, intel_miptree_map_blit's call to intelEmitCopyBlit will overflow intelEmitCopyBlit's src_pitch and dst_pitch parameters (which are 16-bit signed integers). We can conveniently avoid both problems by avoiding the readpixels blit path when the miptree's pitch is >= 32k. Fixes gles3conform "half_float" tests when the buffer width is greater than 2048. Reviewed-by: Eric Anholt <[email protected]> Tested-by: Ian Romanick <[email protected]>
* intel: callocing a 32 byte temp is silly, so don'tIan Romanick2013-01-241-3/+3
| | | | | | | | | I believe that the size used to vary, so the dynamic allocation is necessary. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* st/mesa: implement ARB_internalformat_query v2Marek Olšák2013-01-244-0/+39
| | | | Reviewed-by: Brian Paul <[email protected]>
* st/mesa: advertise OES_depth_texture_cube_map if GLSL 1.30 is supportedMarek Olšák2013-01-241-1/+2
| | | | Reviewed-by: Brian Paul <[email protected]>
* st/dri: disallow recursion in dri_flushMarek Olšák2013-01-242-1/+13
| | | | | | | | | | | ST_FLUSH_FRONT may call driThrottle, which is implemented with dri_flush. This prevents double flush as well as fence leaks caused by a recursion in the middle of throttling. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58839 Reviewed-by: Michel Dänzer <[email protected]> Tested-by: Michel Dänzer <[email protected]>
* st/dri: add null-pointer check, remove duplicated local variableMarek Olšák2013-01-241-4/+5
| | | | | Reviewed-by: Michel Dänzer <[email protected]> Tested-by: Michel Dänzer <[email protected]>
* Revert "Revert "targets/opencl: Link against libgallium.la instead of ↵Tom Stellard2013-01-242-9/+1
| | | | | | | | | libgallium.a"" This reverts commit 7824ab807050c03c6df01c44774914dcbef88248. Now that we force linking with LLVM shared libs when building clover, we can link against libgallium.la with no problems.
* configure.ac: Force use of LLVM shared libs with --enable-opencl v2Tom Stellard2013-01-241-5/+33
| | | | | | | | | | | | | | | | | | | | If we build clover with LLVM static libraries, then clover and also each pipe_*.so driver that is built will contain their own static copy of LLVM. The recent automake changes have uncovered a problem where the pipe_*.so drivers try to use clover's LLVM symbols. This causes LLVM's static registry objects to be initialized each time a pipe_*.so driver is loaded by clover. Initializing these objects multiple times is not allowed and leads to assertion failures in the LLVM code. We can avoid all these problems by having clover and all the pipe_*.so drivers link against the same LLVM shared library. https://bugs.freedesktop.org/show_bug.cgi?id=59334 https://bugs.freedesktop.org/show_bug.cgi?id=59534 v2: - Fix shared library detection when LLVM is built with CMake
* configure.ac: Compute the required llvm static libraries only onceTom Stellard2013-01-242-11/+19
| | | | | | | | | | | In order to determine which static LLVM libraries are needed we pass a list of components to llvm-config and it generates the list of library dependencies for us. The advantage of only calling llvm-config one time is that it can determine if two components depend on the same library and then add it to the output list only once. The old practice of having each driver call llvm-config to add its own dependencies to $(LLVM_LIBS) caused many libraries to be added to this variable multiple times.
* radeonsi: Fall back to dummy pixel shader instead of trying indirect addressing.Michel Dänzer2013-01-241-0/+5
| | | | | | | | Indirect addressing isn't fully handled yet. Fixes crashes with piglit tests using indirect addressing. Signed-off-by: Michel Dänzer <[email protected]>
* radeonsi: make sure copying of all texture formats is acceleratedMarek Olšák2013-01-242-59/+54
| | | | | | [ Cherry-picked from r600g commit 7c371f46958910dd2ca9487c89af1b72bbfdada9 ] Signed-off-by: Michel Dänzer <[email protected]>
* radeonsi: Handle PIPE_FORMAT_L32A32_S/UINT for rendering.Michel Dänzer2013-01-241-0/+4
| | | | Signed-off-by: Michel Dänzer <[email protected]>
* radeonsi: Make sure to use float number format for packed float colour formats.Michel Dänzer2013-01-241-2/+4
| | | | | | | | These aren't covered by UTIL_FORMAT_TYPE_FLOAT. Fixes 15 piglit (sub)tests. Signed-off-by: Michel Dänzer <[email protected]>
* intel: Enable S3TC extensions alwaysIan Romanick2013-01-231-6/+4
| | | | | | | | | | | | | | | | | | | | | Always enable the use of pre-compressed texture data. The ability to perform on-line compression still requires the presence of libtxc_dxtn or an explicit driconf over-ride. Applications that just want to submit precompessed data when an on-line compressor is not available can look for the GL_EXT_texture_compression_dxt1 and GL_ANGLE_texture_compression_dxt[35] extensions. v2: Only enable the extensions that do not require on-line compression by default. The previous statement "This should not impact many (if any) real applications." proved to be false for at least Sauerbraten. This application mostly submits pre-compressed data, but it also can submit uncompressed data that it asks the driver to compress. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]> [v1] Reviewed-by: Kenneth Graunke <[email protected]> [v1] Acked-by: Eric Anholt <[email protected]> [v1] Acked-by: Lee Salzman <[email protected]>
* mesa: Like EXT_texture_compression_dxt1, advertise ↵Ian Romanick2013-01-233-20/+8
| | | | | | | | | | | | | | | ANGLE_texture_compression_dxt in all APIs This is technically outside the ANGLE spec, but it seems unlikely to cause any harm. v2: Simplify the extension checks by assuming the ANGLE extension will always be enabled by any driver that enables the EXT. Suggested by Eric Anholt. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Acked-by: Lee Salzman <[email protected]>
* mesa: Simplify _mesa_choose_tex_format handling of compressed formatsIan Romanick2013-01-231-167/+75
| | | | | | | | | | | | | For non-generic compressed format we assert two things: 1. The format has already been validated against the set of available extensions. 2. The driver only enables the extension if it supports all of the formats that are part of that extension. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Use a single flag for the S3TC extensions that don't require on-line ↵Ian Romanick2013-01-2313-17/+22
| | | | | | | | compression Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Acked-by: Lee Salzman <[email protected]>
* i965: Use swizzles to force R, G, and B to 0.0 for ALPHA textures.Carl Worth2013-01-231-3/+10
| | | | | | | | | | | | | | | | | Similar to the previous commit, we may be using a texture with actual RGBA storage for the GL_ALPHA format, so force the color values to 0.0. This commit fixes the following piglit (sub) tests: EXT_texture_snorm/fbo-blending-formats GL_ALPHA16_SNORM GL_ALPHA8_SNORM GL_ALPHA_SNORM Note: Haswell bypasses this swizzle code, so may require an independent fix for this bug. Reviewed-by: Eric Anholt <[email protected]>
* i965: Use swizzles to force alpha to 1.0 for RED, RG, or RGB textures.Carl Worth2013-01-231-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We may be using a texture with actual RGBA storage for these formats, so force the alpha value read to 1.0. This commit fixes the following piglit (sub) tests: ARB_texture_float/fb-blending-formats GL_RGB16F_ARB EXT_framebuffer_object/fbo-blending-formats GL_RGB10 GL_RGB12 GL_RGB16 EXT_texture_snorm/fbo-blending-formats GL_RGB16_SNORM GL_RGB8_SNORM GL_RGB_SNORM These test improvements depend on the previous commit as well. That commit smashes alpha to 1.0 for the case of ReadPixels (so fixes "FBO testing" as reported by this test), while this commit smashes alpha to 1.0 for the case of texturing (fixed the "window testing" as reported by this test). Note: Haswell bypasses this swizzle code, so may require an independent fix for this bug. Reviewed-by: Eric Anholt <[email protected]>
* ReadPixels: Force ALPHA to 1 while rebasing RGBA values for GL_RGB formatCarl Worth2013-01-231-0/+10
| | | | | | | | | | | | | | | | | | | | | | When performing a ReadPixels operation, we may be reading from a buffer that stores alpha values, but that is actually representing a buffer with no alpha channel. In this case, while rebasing the values, touch up all alpha values read to 1.0. This commit fixes the following piglit (sub) tests: ARB_texture_float/fbo-colormask-formats GL_RBG16F_ARB EXT_texture_snorm/fbo-colormask-formats GL_RGB16_SNORM GL_RGB8_SNORM GL_RGB_SNORM It likely improves the results of other tests as well, but a PASS remains elusive due to additional bugs. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965: Examine _BaseFormat when deciding to perform xRGB_alpha fixupsCarl Worth2013-01-231-1/+2
| | | | | | | | | | | | | | | | | | | | | The renderbuffer's Format field may have an alpha channel even when the underlying _BaseFormat does not. This can happen when mesa chooses to use RGBA16 for an RGB16 format, for example. So look at _BaseFormat when deciding whether to fixup the blend factors. This test improves the results of at least the following piglit tests: EXT_frambebuffer_object/fbo-blending-formats {GL_RGB10, GL_RGB12, GL_RGB16} EXT_texture_snorm/fbo-blending-formats {GL_RGB16_SNORM, GLRGB8_SNORM, GL_RGB_SNORM} But none of these actually change from FAIL to PASS yet. The R, G, and B probe values are fixed with this commit, but the tests still fail because the alpha values are still wrong. Reviewed-by: Eric Anholt <[email protected]>
* scons: Fix source lists parsing on Windows.José Fonseca2013-01-231-2/+7
| | | | | | | | | | | / vs \ mismatch was causing .objs to be put in the source tree, causing breakeage when doing different build types in the same tree (eg., debug vs release). Fix this by normalizing everything to / slashes. It's probably a good idea to purge all .objs from source tree to prevent issues completely.
* GL3.txt: i965 supports ARB_base_instanceMatt Turner2013-01-221-1/+1
| | | | Added in commit cdd3f549.
* wmesa: include api_exec.h to fix compilationBrian Paul2013-01-221-0/+1
|
* draw: fix MSVC divide-by-zero compilation errorBrian Paul2013-01-221-1/+2
| | | | Kind of lame, but it works.
* i965: Implement the GL_ARB_base_instance extension.Kenneth Graunke2013-01-222-2/+4
| | | | | | | | | | | | | Thanks to Fredrik Höglund, all the hard work was already done. Tested using a modified oglconform (that actually runs these tests on our driver); it looks like there may be some bugs when using client arrays. All applicable non-compatibility tests passed. For now, only enable it in core profiles. Reviewed-by: Eric Anholt <[email protected]> Tested-by: Ian Romanick <[email protected]>
* glsl/build: Build libglcpp and libglslcore in builtin_compilerMatt Turner2013-01-222-45/+34
| | | | | | And reuse them if not cross compiling. Tested-by: Andreas Boll <[email protected]>
* glsl/Makefile.sources: Correct BUILTIN_COMPILER_CXX_FILESMatt Turner2013-01-223-5/+4
| | | | | | | | | | | | | | | Squashed with two reverts: Revert "android: Update for builtin_stubs.cpp move" This reverts commit c0def90ede1e939173041b8785303de90f8fdc6c. Revert "scons: Update for builtin_stubs.cpp" This reverts commit 8ac4b82699ad0a59ae6ae6d3415702eaa5d4fe3b. Tested-by: Andreas Boll <[email protected]> Tested-on-Android-by: Chad Versace <[email protected]>
* build: Use AX_PROG_FLEXMatt Turner2013-01-222-1/+66
| | | | | | Tested-by: Andreas Boll <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47248
* build: Use AX_PROG_BISONMatt Turner2013-01-222-7/+74
| | | | | | | | No one tests yacc/byacc. Let's just request bison specifically. Tested-by: Andreas Boll <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46815
* builtin_compiler/build: Use generated parser filesMatt Turner2013-01-221-15/+4
| | | | | | ... instead of generating them again. Tested-by: Andreas Boll <[email protected]>
* glsl/build: Build tests via the glsl MakefileMatt Turner2013-01-225-41/+44
| | | | Tested-by: Andreas Boll <[email protected]>
* glsl/build: Build glcpp via the glsl MakefileMatt Turner2013-01-228-94/+95
| | | | | | Removing the subdirectory recursion provides a small speed up. Tested-by: Andreas Boll <[email protected]>
* glsl/build: Don't build builtin_compiler separately if not cross compilingMatt Turner2013-01-223-2/+30
| | | | | | | Reduces the number of times that src/glsl/ is compiled when not cross compiling. Tested-by: Andreas Boll <[email protected]>
* glsl/build: Don't build glsl_compilerMatt Turner2013-01-221-9/+0
| | | | | | Use glslparsertest from piglit instead. Tested-by: Andreas Boll <[email protected]>
* draw: fix problem in screen-space interpolation clip codeBrian Paul2013-01-221-3/+3
| | | | | | | | | | | | | | | | | | I don't see how this could have ever worked right. The screen-space interpolation code uses the vertex->data[pos_attr] position which contain window coords. But window coords are only computed for the unclipped vertices; the clipped vertices have undefined window coords (see draw_cliptest_tmp.h). Use the vertex clip coords instead which are always defined. Fixes http://bugs.freedesktop.org/show_bug.cgi?id=55476 (piglit fbo-blit-stretch failure on softpipe) Note: This is a candidate for the 9.0 branch. Reviewed-by: José Fonseca <[email protected]>
* draw: improve the clipper debug/printf codeBrian Paul2013-01-221-1/+20
| | | | Reviewed-by: José Fonseca <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 22:34:17 +0000