summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* glsl: Add an ir_variable::max_ifc_array_access field.Paul Berry2013-10-093-1/+25
| | | | | | | | | For interface blocks that contain arrays, this field will contain the maximum element of each contained array that is accessed by the shader. This is a first step toward supporting unsized arrays in interface blocks. Reviewed-by: Jordan Justen <[email protected]>
* glsl: Make accessor functions for ir_variable::interface_type.Paul Berry2013-10-099-33/+51
| | | | | | | In a future patch, this will allow us to enforce invariants when the interface type is updated. Reviewed-by: Jordan Justen <[email protected]>
* glsl: Move update of max_array_access into a separate function.Paul Berry2013-10-091-17/+30
| | | | | | | | | | | | | | | | | Currently, when converting an access to an array element from ast to IR, we need to see if the array is an ir_dereference_variable, and if so update the variable's max_array_access. When we add support for unsized arrays in interface blocks, we'll also need to account for cases where the array is an ir_dereference_record and the record is an interface block. To make this easier, move the update into its own function. v2: Use an ordinary function in ast_array_index.cpp rather than a virtual function in ir_rvalue. Reviewed-by: Jordan Justen <[email protected]>
* glsl: Add parser support for unsized arrays in interface blocks.Paul Berry2013-10-091-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although it's not explicitly stated in the GLSL 1.50 spec, unsized arrays are allowed in interface blocks. section 1.2.3 (Changes from revision 5 of version 1.5) of the GLSL 1.50 spec says: * Completed full update to grammar section. Tested spec examples against it: ... * add unsized arrays for block members And section 7.1 (Vertex and Geometry Shader Special Variables) includes an unsized array in the built-in gl_PerVertex interface block: out gl_PerVertex { vec4 gl_Position; float gl_PointSize; float gl_ClipDistance[]; }; Furthermore, GLSL 4.30 contains an example of an unsized array occurring inside an interface block. From section 4.3.9 (Interface Blocks): uniform Transform { // API uses "Transform[2]" to refer to instance 2 mat4 ModelViewMatrix; mat4 ModelViewProjectionMatrix; vec4 a[]; // array will get implicitly sized float Deformation; } transforms[4]; This patch adds the parser rule to support unsized arrays inside interface blocks. Later patches in the series will add the appropriate semantics to handle them. Fixes piglit tests: - spec/glsl-1.50/execution/unsized-in-unnamed-interface-block - spec/glsl-1.50/linker/unsized-in-unnamed-interface-block Reviewed-by: Jordan Justen <[email protected]>
* glsl: Rename the fourth argument to get_interface_instance.Paul Berry2013-10-092-5/+5
| | | | | | | | | Interface declarations have two names associated with them: the block name and the instance name. It's the block name that needs to be passed to get_interface_instance(). This patch renames the argument so that there's no confusion. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: Allow format conversions for CopyTexSubImage.Kenneth Graunke2013-10-091-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | BLORP performs blits by drawing a rectangle with a shader that samples from the source texture, and writes color data to the destination. The sampler always returns 32-bit RGBA float data, regardless of the source format's component ordering or data type. Likewise, the render target write message takes 32-bit RGBA float data, and converts it appropriately. So the bulk of the work is already taken care of for us. This greatly accelerates a lot of CopyTexSubImage calls, and makes Legends of Aethereus playable on Ivybridge. At the default settings, LOA continually blits between SRGBA8888 (the window format) and RGBA16_FLOAT. Since neither BLORP nor our BLT paths supported this, it fell back to meta, spending 33% of the CPU in floorf() converting between floats and half-floats. v2: Use != instead of ^ (suggested by Ian). Note that only CopyTexSubImage is affected by this patch (caught by Eric). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
* i965/blorp: Rework sRGB override behavior.Kenneth Graunke2013-10-092-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous code for sRGB overrides assumes that the source and destination formats are equal, other than the color space. This won't be feasible when we add support for format conversions. Here are a few cases, and how the old code handled them: 1. RGB8 -> SRGB8, MSAA ==> SRGB8 -> SRGB8 2. RGB8 -> SRGB8, single ==> RGB8 -> RGB8 3. SRGB8 -> RGB8, MSAA ==> RGB8 -> RGB8 4. SRGB8 -> RGB8, single ==> SRGB8 -> SRGB8 Apparently, preserving the behavior of #1 is important. When doing a multisample to single-sample resolve, blending the samples together in an sRGB correct fashion results in a noticably higher quality image. It also is necessary to pass Piglit's EXT_framebuffer_multisample accuracy color tests. Paul, Eric, Anuj, and I talked about this, and aren't sure that it matters in the other cases. This patch preserves the behavior of #1, but otherwise reverts to doing everything in linear space, changing the behavior of case #4. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
* i965/blorp: Explain why Z24 can't use a sensible format.Kenneth Graunke2013-10-091-1/+5
| | | | | | | | | | | | | | | | | We could conceivably use BRW_SURFACEFORMAT_R24_UNORM_X8_TYPELESS for Z24 source images, allowing conversions from Z24 to either Z16 or Z32F. Unfortunately, we can't use it for destination images since it isn't supported as a render target. Using different formats for sources or destinations would be painful, so for now, punt. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
* i965/blorp: Use R32_FLOAT for Z32F surfaces.Kenneth Graunke2013-10-091-6/+8
| | | | | | | | | | | | | | | | | Currently, all that matters is that we copy the correct number of bits, so any format that has 32-bits of data will work fine. Once BLORP begins handling format conversions, the sampler will need to correctly interpret the data. We don't need a depth format, but we do need the right number of components and data type (FLOAT). For Z32F, this means using R32_FLOAT. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
* i965/blorp: Use R16_UNORM for Z16 surfaces.Kenneth Graunke2013-10-091-6/+1
| | | | | | | | | | | | | | | | | Currently, all that matters is that we copy the correct number of bits, so any format that has 16-bits of data will work fine. Once BLORP begins handling format conversions, the sampler will need to correctly interpret the data. We don't need a depth format, but we do need the right number of components and data type (UNORM). For Z16, this means using R16_UNORM. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
* i965/blorp: Add support for non-render-target formats.Kenneth Graunke2013-10-091-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Once blorp gains the ability to do format conversions, it's conceivable that the source format may be texturable but not supported as a render target. This would break Paul's code, which assumes that it can use the render_target_format array even for the source format. There are three ways to convert MESA_FORMAT enums to BRW_SURFACEFORMAT enums: 1. brw_format_for_mesa_format() This translates the Mesa format to the most equivalent BRW format. 2. brw->render_target_format[] This is used for renderbuffers, and handles the subset of formats that are renderable. However, it's not always equivalent, since it overrides a few non-renderable formats. For example, it converts B8G8R8X8_UNORM to B8G8R8A8_UNORM so it can be rendered to. 3. translate_tex_format() This is used for textures. It wraps brw_format_for_mesa_format(), but overrides depth textures, and one sRGB case on Gen4. BLORP has a fourth function, which uses brw->render_target_format[] and overrides depth formats (differently than translate_tex_format). This patch makes the BLORP function to use brw_format_for_mesa_format() for textures/source data, since not everything will be a render target. It continues using brw->render_target_format[] for render targets, since it needs the format overrides that provides. We don't use translate_tex_format() since the additional overrides are not useful or simply redundant. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
* i965/blorp: Add an is_render_target parameter to surface_info::set.Kenneth Graunke2013-10-094-6/+8
| | | | | | | | | | | This allows us to determine whether we're setting up a format for the source (as a texture) or destination (as a render target). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
* util/u_math: Fix C++ include of u_math.h on MSVC.José Fonseca2013-10-101-1/+1
| | | | | | | GNU C++ compiler declares the C99 lrint, etc. when _GNU_SOURCE is defined, but MSVC does not. Trivial.
* llvmpipe: abstract the code to set number of subpixel bitsZack Rusin2013-10-093-10/+15
| | | | | | | | | | As we're moving towards expanding the number of subpixel bits and the width of the variables used in the computations we need to make this code a bit more centralized. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: implement 64 bit mul opcodes in llvmpipeZack Rusin2013-10-091-0/+60
| | | | | | | | | Both the imul_hi and umul_hi are working with this patch. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* gallium: Add support for 32x32 muls with 64 bit resultsZack Rusin2013-10-098-1/+103
| | | | | | | | | | | | | | The code introduces two new 32bit integer multiplication opcodes which can be used to produce correct 64 bit results. GLSL, OpenCL and D3D10+ require them. We use two seperate opcodes, because they match the behavior of GLSL and OpenCL, are a lot easier to add than a single opcode with multiple destinations and because there's not much (any) difference wrt code-generation. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* gallivm: support printing of 64 bit integersZack Rusin2013-10-091-1/+6
| | | | | | | only 8 and 32 bit integers were supported before. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* i965/blorp: Fix the register types on blorp's push constants.Eric Anholt2013-10-091-16/+16
| | | | | | | | | | The UD values were getting set up as floats. This happened to work out because they were used as the second argument where the first was a dword, and gen6+ doesn't do source conversions. But it did trigger fulsim warnings, and it meant if you used the push constant as the first operand you would have been disappointed. Reviewed-by: Paul Berry <[email protected]>
* i965: Fix 3D texture layout by more literally copying from the spec.Eric Anholt2013-10-091-55/+20
| | | | | | | | | Fixes 3 texelFetch tests in piglit all.tests on ivb, and cubemap npot on gm45. v2: Don't forget the gen4 DL=6 cubemap behavior. Cc: "9.1 9.2" <[email protected]> Reviewed-by: Chad Versace <[email protected]> (v1)
* mesa: Fix compiler warnings when ALIGN's alignment is "1 << value".Eric Anholt2013-10-091-1/+1
| | | | | | | | | | | We hadn't run into order of operation warnings before, apparently, since addition is so low on the order. Cc: "9.1 9.2" <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Don't forget the cube map padding on gen5+.Eric Anholt2013-10-091-7/+15
| | | | | | | | | | | We had a fixup for gen4's 3d-layout cubemaps (which, iirc, we'd experimentally found to be necessary!), but while the spec still requires it on gen5, we'd been missing it in the array-layout cubemaps. Cc: "9.1 9.2" <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* egl/main: remove undefined X11_LIBS automake variableGaetan Nadon2013-10-091-1/+1
| | | | | | | | | | | | | | | | The EGL library has some references to x11 but it gets the link flags from the XCB_DRI2_LIBS if and only if HAVE_EGL_PLATFORM_X11 is true. The X11_LIBS variable was probably coming from a PKG_CHECK_MODULES (x11) earlier in history. If it is possible to have HAVE_EGL_DRIVER_GLX without HAVE_EGL_PLATFORM_X11 then the link flags for libX11 should be passed. However, it won't come from X11_LIBS which is undefined. Reported-by: Emil Velikov <[email protected]> Acked-by: Emil Velikov <[email protected]> Signed-off-by: Gaetan Nadon <[email protected]>
* gallium/state_trackers/glx: X11/Xlib.h: No such file or directoryGaetan Nadon2013-10-091-1/+1
| | | | | | | | | | | | | | | | | The compiler cannot find the Xlib.h in the installed system headers. All supplied include directives point to inside the mesa module. The X11_CFLAGS variable is undefined (not defined in config.status). It appears the intent was to use X11_INCLUDES defined in configure.ac. The Xlib.h file is not installed on my workstation. It is supplied in the libx11-dev package. This allows an X developer control over which version of this file is used for X development. Use to test: --enable-gallium-egl --enable-xlib-glx --disable-dri Acked-by: Brian Paul <[email protected]> Signed-off-by: Gaetan Nadon <[email protected]>
* gallium/targets/libgl-xlib: X11/Xlib.h: No such file or directoryGaetan Nadon2013-10-091-1/+1
| | | | | | | | | | | | | | | The compiler cannot find the Xlib.h in the installed system headers. All supplied include directives point to inside the mesa module. The X11_CFLAGS variable is undefined (not defined in config.status). It appears the intent was to use X11_INCLUDES defined in configure.ac. The Xlib.h file is not installed on my workstation. It is supplied in the libx11-dev package. This allows an X developer control over which version of this file is used for X development. Acked-by: Brian Paul <[email protected]> Signed-off-by: Gaetan Nadon <[email protected]>
* gallium/state_trackers/egl: use X11_INCLUDES rather than X11_CFLAGSGaetan Nadon2013-10-091-1/+1
| | | | | | | | | | | | | The X11_CFLAGS variable is undefined (not defined in config.status). It appears the intent was to use X11_INCLUDES defined in configure.ac. It is used for building the code in the x11 subdir. The build does not fail on this one as LIBDRM_CFLAGS happens to have the inludedir value as the one for X11. It will not always be the case. The option --enable-gallium-egl is required durimg configuration. Acked-by: Brian Paul <[email protected]> Signed-off-by: Gaetan Nadon <[email protected]>
* st/vdpau: really block until surface is idleGrigori Goronzy2013-10-091-1/+2
| | | | | | | | | | | | pipe_screen::fence_finish with zero timeout returns quickly and doesn't wait at all. Fix that, and also delete the fence afterwards, so that QuerySurfaceStatus returns the right state later. Addresses: https://trac.videolan.org/vlc/ticket/9281 https://bugs.freedesktop.org/show_bug.cgi?id=68792 Reviewed-by: Christian König <[email protected]>
* st/vdpau: add new formats to OutputSurface renderingGrigori Goronzy2013-10-092-1/+24
| | | | | | | | OutputSurfaces have simple YCbCr rendering functionality built in, but so far only 4:2:0 subsampling worked correctly. This fixes 4:2:2 and 4:4:4 formats. Reviewed-by: Christian König <[email protected]>
* st/vdpau: fix GenerateCSCMatrix with NULL procampGrigori Goronzy2013-10-091-9/+12
| | | | | | | | | | | | As per API specification, it is legal to supply a NULL procamp. In this case, a CSC matrix according to the colorspace should be generated, but no further adjustments are made. Addresses: https://trac.videolan.org/vlc/ticket/9281 https://bugs.freedesktop.org/show_bug.cgi?id=68792 Reviewed-by: Christian König <[email protected]>
* radeon/uvd: disable VC-1 simple/main profileGrigori Goronzy2013-10-091-1/+3
| | | | | | | | It doesn't work (decodes to garbage) with most videos on UVD 3.0. Worse yet, it often results in random memory corruption or GPU hangs. Rumor has it only the newest UVD hardware could do it anyway. Reviewed-by: Christian König <[email protected]>
* radeon/uvd: try to fix VC-1 decodingGrigori Goronzy2013-10-091-33/+38
| | | | | | | | | | | | | The DPB size calculations seem to be off; there is various random corruption happening, even with advanced profile. Always assuming a minimum number of references appears to fix it, similarly to H.264. This might overallocate the DPB. Also clean up the SPS/PPS field setup so that it matches VC-1 specifications better. With these changes, all advanced profile VC-1 files I could get my hand on work fine. Reviewed-by: Christian König <[email protected]>
* radeon/uvd: fix video format reportingGrigori Goronzy2013-10-091-2/+5
| | | | | | | | | | UVD can only support NV12 in the case of hardware decoding, but we can still use all other formats for software decoding. Use the UNKNOWN profile to signal that we're not interesting in hardware decoding. v2: use profile instead of entrypoint Reviewed-by: Christian König <[email protected]>
* gallium/dri targets: use DRI_DRIVER_LDFLAGSMarek Olšák2013-10-099-9/+9
| | | | | | | which contains -Wl,-Bsymbolic. If I understand it correctly, it prevents symbols from clashing if multiple drivers are loaded at the same time. Tested-by: Emil Velikov <[email protected]>
* radeonsi: fix occlusion queries for CIKMarek Olšák2013-10-091-3/+12
| | | | Reviewed-by: Michel Dänzer <[email protected]>
* radeonsi: draw register fixes for CIKMarek Olšák2013-10-092-9/+27
| | | | | | This doesn't fix any known issue. I'm just following the docs. Reviewed-by: Michel Dänzer <[email protected]>
* i965: keep SecHalf flag after register coalescingChia-I Wu2013-10-091-0/+1
| | | | | | | Copy sechalf to the new register, otherwise we would read wrong HW registers. Signed-off-by: Chia-I Wu <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: allow SIMD8 sampler messages in SIMD16 modeChia-I Wu2013-10-091-1/+2
| | | | | | | | When the instruction to send the sampler message is forced uncompressed or sechalf, send SIMD8 one even in SIMD16 mode. Signed-off-by: Chia-I Wu <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: make BRW_COMPRESSION_2NDHALF valid for brw_SAMPLEChia-I Wu2013-10-091-1/+16
| | | | | | | | | | | SIMD8 sampler messages are allowed in SIMD16 mode, and they could not work without BRW_COMPRESSION_2NDHALF. Later PRMs (gen5 and later) do not explicitly state whether BRW_COMPRESSION_2NDHALF is allowed, but they do have examples using send with SecHalf. It should be safe to assume SecHalf is valid. Signed-off-by: Chia-I Wu <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Initialize brw_blorp_const_color_program::prog_data.Vinson Lee2013-10-081-0/+2
| | | | | | | Fixes "Uninitialized scalar field" defect reported by Coverity. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Fix a compiler warning about conservative depth enums.Eric Anholt2013-10-081-0/+2
| | | | Reviewed-by: Chris Forbes <[email protected]>
* i965/gs: Fixup gl_PointSize on entry to geometry shaders.Paul Berry2013-10-081-0/+17
| | | | | | | | | | | | | | | | gl_PointSize is stored in the w component of VARYING_SLOT_PSIZ, but the geometry shader infrastructure assumes that it should look for all geometry shader inputs of type float in the x component. So when compiling a geomtery shader that uses a gl_PointSize input, fix it up during the shader prolog by moving the w component to the x component. This is similar to how we emit fixups and workarounds for vertex shader attributes. Fixes piglit test spec/glsl-1.50/execution/geometry/core-inputs. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* glsl/gs: handle gl_ClipDistance geometry input in lower_clip_distance.Bryan Cain2013-10-081-60/+193
| | | | | | | | | | | | | | | | | | | | | This corresponds to the lowering of gl_ClipDistance to gl_ClipDistanceMESA for vertex and geometry shader outputs. Since this lowering pass occurs after lower_named_interface blocks, it deals with 2D arrays (gl_ClipDistance[vertex][clip_plane]) rather than 1D arrays in an interface block (gl_in[vertex].gl_ClipDistance[clip_plane]). v2 (Paul Berry <[email protected]>): Fix indexing order for gl_ClipDistance input lowering. Properly lower bulk assignment of gl_ClipDistance inputs. Rework for GLSL 1.50 style geometry shaders. Reviewed-by: Jordan Justen <[email protected]> v3 (Paul Berry <[email protected]>): Add comments and assertions to clarify that the 2D version of clip distance is only used for geometry shader inputs. Reviewed-by: Ian Romanick <[email protected]>
* glsl/gs: add gl_in support to builtin_variables.cpp.Paul Berry2013-10-081-2/+31
| | | | | | | | | | | | | | | | | | | | | | | Previously, builtin_variables.cpp was written assuming that we supported ARB_geometry_shader4 style geometry shader inputs, meaning that each built-in varying input to a geometry was supplied via an array variable whose name ended in "In", e.g. gl_PositionIn or gl_PointSizeIn. However, in GLSL 1.50 style geometry shaders, things work differently--built-in inputs are supplied to geometry shaders via a built-in interface block called gl_in, which contains all the built-in inputs using their usual names (e.g. the gl_Position input is supplied to the geometry shader as gl_in[i].gl_Position). This patch adds the necessary logic to builtin_variables.cpp to create the gl_in interface block and populate it accordingly for geometry shader inputs. The old ARB_geometry_shader4 style varyings are removed, though they can easily be added back in the future if we decide to support ARB_geometry_shader4. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* glsl: Keep track of location for interface block fields.Paul Berry2013-10-085-37/+50
| | | | | | | | | | | | | This patch adds a "location" element to struct glsl_struct_field, so that we can keep track of the gl_varying_slot associated with each built-in geometry shader input. In lower_named_interface_blocks, we use this value to populate the "location" field in the ir_variable that stores each geometry shader input. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* glx: Generate fewer errors in MakeContextCurrentAdam Jackson2013-10-081-10/+0
| | | | | | | | | | | | | | | | | | For a few reasons. 1: In the (current) common case, these conditionals are never true. All we're doing by checking them is slowing down MakeCurrent. The server does these checks already anyway. 2: GLX >= 3.0 contexts may legally be made current without a bound framebuffer. This does not fix piglit/glx-create-context-current-no-framebuffer, but is a prerequisite for fixing it. Cc: "9.1 9.2" <[email protected]> Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Adam Jackson <[email protected]>
* glx: Propagate failures from SendMakeCurrentRequest where possibleAdam Jackson2013-10-081-3/+4
| | | | | Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Adam Jackson <[email protected]>
* glx: Hide xGLXMakeCurrentReply inside SendMakeCurrentRequestAdam Jackson2013-10-081-7/+9
| | | | | Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Adam Jackson <[email protected]>
* st/dri: don't export any private symbolsMarek Olšák2013-10-082-1/+3
| | | | Reviewed-by: Tom Stellard <[email protected]>
* gallium/swrast: don't export any private symbolsMarek Olšák2013-10-084-4/+8
| | | | Reviewed-by: Tom Stellard <[email protected]>
* gallium/radeon: don't export any private symbolsMarek Olšák2013-10-0814-16/+32
| | | | Reviewed-by: Tom Stellard <[email protected]>
* configure.ac: report an error if LLVM shared libs are disabled and CL is enabledMarek Olšák2013-10-081-2/+3
| | | | Reviewed-by: Tom Stellard <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-21 08:24:24 +0000