summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers
Commit message (Collapse)AuthorAgeFilesLines
* i965: Fix disassembly of data port writes on Ivybridge.Kenneth Graunke2012-01-181-1/+12
| | | | | | | | | | msg_type moved by a bit, so the message type was being disassembled incorrectly. In particular, render target writes were showing up as "OWORD block write". NOTE: This is a candidate for stable release branches. Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Fix disassembly of sampler messages on Ivybridge.Kenneth Graunke2012-01-181-1/+7
| | | | | | | | | Compared to sampler_gen5, simd_mode shifted by a bit and msg_type grew by a bit. So we were printing slightly incorrect numbers. NOTE: This is a candidate for stable release branches. Signed-off-by: Kenneth Graunke <[email protected]>
* i965/vs: Take attributes into account when deciding urb_entry_size.Kenneth Graunke2012-01-182-5/+8
| | | | | | | | | | | | | | | | | | | | Both the VF and VS share space in the URB. First, the VF stores attributes (shader inputs) there. The VS then reads the attributes, executes, and reuses the space to store varyings (shader outputs). Thus, we need to calculate the amount of URB space necessary for inputs, outputs, and pick whichever is greater. The old VS backend correctly did this (brw_vs_emit.c:408), but the new VS backend only considered outputs. Fixes vertex scrambling in GLBenchmark PRO on Ivybridge. NOTE: This is a candidate for the 8.0 branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41318 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: Set depth to 6 for cubemapsIan Romanick2012-01-182-5/+5
| | | | | | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41216 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43212 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43250 Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: Jin Yang <[email protected]>
* gbm: Validate usage flags in gbm_bo_create_from_egl_image()Kristian Høgsberg2012-01-182-3/+15
| | | | | The entry point is supposed to validate that the EGLImage is suitable for the passed in usage flags, but that was never implemented.
* i965: Add support for Z16 depth formats.Eric Anholt2012-01-181-0/+1
| | | | | | | | | | | | v2: Don't flag the format as being HiZ ready (there's DRI2 handshake pain to go through). Fixes piglit gl-3.0-required-sized-texture-formats NOTE: This is a candidate for the 8.0 branch. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/gen7: Set up surface horizontal alignment field.Eric Anholt2012-01-181-1/+4
| | | | | | | | | | | | This is required for Z16 support for texturing, which is the first thing to have a horizontal alignment of 8. Renderbuffers don't need it, since they're always set up as the only mip level, but do it for completeness anyway. NOTE: This is a candidate for the 8.0 branch. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/gen7: Remove stale comment.Eric Anholt2012-01-181-1/+0
| | | | | | | | | This field is actually set up above. NOTE: This is a candidate for the 8.0 branch, to avoid conflicts. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Fix leak of the program cache BO on context destroy.Eric Anholt2012-01-181-0/+2
| | | | NOTE: This is a candidate for the 8.0 branch.
* i965/vs: Fix leak of an empty hash_table structure per compile.Eric Anholt2012-01-181-4/+0
| | | | | | | This statement got duplicated above, probably in a rebase resolution, so we never freed the extra one. NOTE: This is a candidate for the 8.0 branch.
* i965: Fix refcount leak of the gl_program structure.Eric Anholt2012-01-181-0/+2
| | | | | | | Fixes a leak of almost 200kb on a minimal shader_runner program (algebraic-add-add-1). NOTE: This is a candidate for the 8.0 branch.
* mesa: Make the register allocator allocation take a ralloc context.Eric Anholt2012-01-182-2/+2
| | | | | | This fixes a memory leak on i965 context destruction. NOTE: This is a candidate for the 8.0 branch.
* i965: Bump Ivybridge's fake MRF range to g112-127 instead of g111-126.Kenneth Graunke2012-01-181-1/+9
| | | | | | | | | | | | | | | | | | | | | When I originally implemented the hack to use GRFs 111+ as fake MRFs, I did so purely to avoid rewriting all the code that dealt with MRFs. However, it turns out that a similar hack is actually required. Newly discovered language in the BSpec indicates that SEND instructions with EOT set "should" use g112-g127 as their source registers. Based on assertions in the simulator, this is actually a requirement on certain platforms. Since we're faking MRFs already, we may as well use the officially sanctioned range. My guess is that we avoided this issue because we seldom use m0: URB writes in the new VS backend start at m1, and RT writes in the new FS backend start at m2. NOTE: This is a candidate for stable release branches. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Remove the INTEL_OLD_VS option.Kenneth Graunke2012-01-183-10/+3
| | | | | | | | | | | | | | | Now that we no longer generate Mesa IR from GLSL IR, it's impossible to use the old vertex shader backend for GLSL programs. There's simply no Mesa IR to codegen from. Any attempt to do so would result in immediate GPU hangs, presumably due to the driver uploading an empty program with no EOT message. NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Eugeni Dodonov <[email protected]>
* i965/gen5: Fix rendering of depth buffers without stencil [v2]Chad Versace2012-01-171-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | Fixes the following OGLConform tests on gen5: depth-stencil(misc.state_on.depth_int) fbo_db_ARBfp(basic.OnlyDepthBuffDrawBufferRender) The problem was that, if the depth buffer's Mesa format was X8_Z24, then we emitted the hardware format D24_UNORM_X8. But, on gen5, D24_UNORM_S8 must be emitted. This bug was introduced by: commit d84a180417d1eabd680554970f1eaaa93abcd41e Author: Eric Anholt <[email protected]> i965: Base HW depth format setup based on MESA_FORMAT, not bpp. v2: Deref 'intel' directly. Move the branch for newer chipset to top. Quote the PRM. As requested by Ken. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43408 Note: This is a candidate for the 8.0 branch. Reported-by: Xunx Fang <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Return if pointer to intel_context is nullAnuj Phogat2012-01-171-7/+7
| | | | | | | It is better to test if(intel == NULL) and simply return in that case. Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Add .gitignore file to exclude automake build artifacts from git.Paul Berry2012-01-171-0/+6
| | | | | | | | | | | | | | | | | | With the conversion to automake in commit e326480e4ebe8687948041c2dc5f5b7595559a2e, several additional build artifacts are created: src/mesa/drivers/dri/i965/.deps/ src/mesa/drivers/dri/i965/.libs/ src/mesa/drivers/dri/i965/Makefile src/mesa/drivers/dri/i965/Makefile.in src/mesa/drivers/dri/i965/i965_dri.la src/mesa/drivers/dri/i965/i965_symbols_test This patch adds all of these files to .gitignore. Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* radeon: share common fog code between radeon and r200Alex Deucher2012-01-1717-259/+227
| | | | Signed-off-by: Alex Deucher <[email protected]>
* radeon: fix fog coordinate emitAlex Deucher2012-01-171-1/+1
| | | | | | | | | Noticed by dungeon on phoronix: http://phoronix.com/forums/showthread.php?65408-Radeon-R100-R200-Mesa-Driver-Sees-Attention&p=247018#post247018 Signed-off-by: Alex Deucher <[email protected]> Note: this is a candidate for the stable branches.
* r200: fix fog coordinate emitAlex Deucher2012-01-171-1/+1
| | | | | | | | | Noticed by dungeon on phoronix: http://phoronix.com/forums/showthread.php?65408-Radeon-R100-R200-Mesa-Driver-Sees-Attention&p=247018#post247018 Signed-off-by: Alex Deucher <[email protected]> Note: this is a candidate for the stable branches.
* i965: Convert the build to using automake.Eric Anholt2012-01-174-34/+88
| | | | | | | | | | | | | | | | | This does introduce a warning by the automake build system, that the missing-symbols test build is non-portable. That's true -- Mac OS X can't take something built as a loadable module and just link it as a library. Of course, we aren't building this on OS X at all, so it would be nice to be able to suppress it, but I haven't found a way. Still, the build is going to be much quieter than we have ever had before, so I think this is a fair tradeoff until we find a way to shut that warning up. v2: Put a link in /lib to avoid transition pains for people. Reviewed-by: Ian Romanick <[email protected]> (v1) Reviewed-by: Matt Turner <[email protected]> (v1)
* intel: Drop the version override code now that we don't have any left.Eric Anholt2012-01-171-8/+0
| | | | | | | | Fixes a compiler warning. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* intel: Fix warnings of undefined ffs().Eric Anholt2012-01-171-0/+1
| | | | | | | | For some reason these started showing up with the automake conversion. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Fix gen6,gen7 when used with a non-HiZ capable DDXChad Versace2012-01-161-4/+13
| | | | | | | | | | | | | | | | | | | | | Nothing works if HiZ is enabled and the DDX is incapable of HiZ (that is, the DDX version is < 2.16). The problem is that the refactoring that eliminated intel_renderbuffer::stencil_rb broke the recovery path in intel_verify_dri2_has_hiz(). Specifically, it broke line intel_context.c:1445, which allocates the region for DRI_BUFFER_DEPTH_STENCIL. That allocation was creating a separate stencil miptree, despite the buffer being a packed depthstencil buffer. Havoc ensued. This patch introduces a bool flag that prevents allocation of that stencil miptree. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44103 Tested-by: Ian Romanick <[email protected]> Note: This is a candidate for the 8.0 branch. Signed-off-by: Chad Versace <[email protected]>
* intel: Fix segfault in glXSwapBuffers with no bound contextAnuj Phogat2012-01-161-5/+7
| | | | | | | | | | | | | | Calling glXSwapBuffers with no bound context causes segmentation fault in function intelDRI2Flush. All the gl calls should be ignored after setting the current context to null. So the contents of framebuffer stay unchanged. But the driver should not seg fault. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44614 Reported-by: Yi Sun <[email protected]> Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Tested-by: Yi Sun <[email protected]>
* r200: remove left-over EGL_SOURCES variableMatt Turner2012-01-151-1/+0
| | | | | | Rest was removed in 2a928899e. Signed-off-by: Matt Turner <[email protected]>
* i965: Comment gen6_hiz_get_framebuffer_enum()Chad Versace2012-01-131-4/+6
| | | | | | | Make the comments precise. Explain why each branch is needed and correct. Document the potential pitfall in the true-branch. Signed-off-by: Chad Versace <[email protected]>
* gen6_hiz: Don't bind GL_DRAW_FRAMEBUFFER on GLESNeil Roberts2012-01-131-5/+29
| | | | | | | | | | | | When using Mesa with a GLES API, calling _mesa_FramebufferRenderbuffer with GL_DRAW_FRAMEBUFFER will report a 'user error' because get_framebuffer_target validates that this enum from the framebuffer blit extension is only used on GL. To work around it this patch makes it use the GL_FRAMEBUFFER enum instead in that case. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43418 Note: This is a candidate for the 8.0 branch. Signed-off-by: Chad Versace <[email protected]>
* osmesa: fix renderbuffer format selectionBrian Paul2012-01-131-46/+42
| | | | | | | | | | | | | | | | | The gl_renderbuffer::Format field wasn't always set properly. This didn't matter much in the past but with the recent swrast/renderbuffer mapping changes, core Mesa will be directly touching OSMesa colorbuffers so using the right MESA_FORMAT_x value is important. Unfortunately, there aren't MESA_FORMATs for all the possible OSmesa format/type combinations, such as GL_FLOAT / OSMESA_ARGB. If anyone runs into these we can add new Mesa formats. v2: add warnings for unsupported formats, fix ARGB_REV mix-up. NOTE: This is a candidate for the 8.0 branch. Reviewed-by: José Fonseca <[email protected]>
* i965: Fix Coverity wrong sizeof argument defect.Vinson Lee2012-01-121-1/+1
| | | | | | | NOTE: This is a candidate for stable release branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42542 Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Set pitch of pull constant buffers to 16.Paul Berry2012-01-122-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | We always access pull constant buffers using the message types "OWord Block Read" or "OWord Dual Block Read". According to the Sandy Bridge PRM, Vol 4 Part 1, pages 214 and 218, when using these messages: "the surface pitch is ignored, the surface is treated as a 1-dimensional surface. An element size (pitch) of 16 bytes is used to determine the size of the buffer for out-of-bounds checking if using the surface state model." Previously we were setting the pitch for pull constant buffers to the size of the whole constant buffer--this made no sense and would have led to incorrect behavior if it were not for the fact that the pitch is ignored. For clarity, this patch sets the pitch for pull constant buffers to 16 bytes, consistent with the hardware's behavior. v2: Clarify the meaning of the ignored values by writing them as (16 - 1). Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965 gen4-6: Fix off-by-one errors brw_create_constant_surface()Paul Berry2012-01-121-3/+3
| | | | | | | | | | | | | | | | | | | | | Commit 9bdc44a52804a64219a0ca1a061b18596863e524 (i965: Replace struct with bit shifting for WM pull constant surfaces) accidentally introduced off-by-one errors into the calculation of the surface width, height, and depth. This patch restores the correct computation. The reason this wasn't noticed by Piglit tests is that the size of our constant surfaces is always less than 2^20, therefore the off-by-one error was causing the "depth" field of the surface to be set to all 1's. The hardware interpreted this as an extremely large surface, so overflow checking was effectively disabled. No Piglit regressions on Sandy Bridge. NOTE: This is a candidate for the 7.11 and 8.0 branches. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* osmesa: fix glReadPixels, etcBrian Paul2012-01-121-1/+57
| | | | | | | | | | | Needed to implement the Map/UnmapRenderbuffer() driver hooks. This fixes glRead/Draw/CopyPixels, etc. See https://bugs.freedesktop.org/show_bug.cgi?id=44723 Note: This is a candidate for the 8.0 branch. Tested-by: Kevin Hobbs <[email protected]>
* intel: move declaration before codeBrian Paul2012-01-121-1/+1
|
* intel: fix mapping of malloc'd renderbuffersBrian Paul2012-01-121-0/+15
| | | | | | | | | | | This fixes accum buffer operations. The accumulation buffer is the only malloc-based renderbuffer for the intel drivers. v2: apply x/y offset to returned pointer NOTE: This is a candidate for the 8.0 branch. Reviewed-by: Eric Anholt <[email protected]>
* meta: Add GL_RED/GL_RG support to meta CopyTexImage.Eric Anholt2012-01-121-1/+4
| | | | | | | Fixes some _mesa_problem()s in oglconform. Reviewed-by: Brian Paul <[email protected]> NOTE: This is a candidate for the 8.0 branch.
* i965/gen7: Fix depth buffer rendering to tile offsets.Eric Anholt2012-01-122-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, we were saying that everything from the starting tile to region width+height was part of the limits of our depthbuffer, even if the tile was near the bottom of the depthbuffer. This mean that our range was not clipping to buffer buonds if the start tile was anything but the start of the buffer. In bebc91f0f3a1f2d19d36a7f1a4f7c992ace064e9, this was changed to saying that we're just rendering to a region of the size of the renderbuffer. This is great -- we get a range that should actually match what we want. However, the hardware's range checking occurs after the X/Y offset addition, so we were clipping out rendering to small depth mip levels when an X/Y offset was present. Just add tile_x/y to the width in that case -- the WM won't produce negative x/y values pre-offset, so we just need to get the left/bottom sides of the region to cover our buffer. Fixes the following Piglit regressions on gen7: spec/ARB_depth_buffer_float/fbo-clear-formats spec/ARB_depth_texture/fbo-clear-formats spec/EXT_packed_depth_stencil/fbo-clear-formats NOTE: This is a candidate for the 8.0 branch.
* meta: fix incorrect argument order in setup_texture_coords() callBrian Paul2012-01-121-1/+1
| | | | | | | | And pass integer width, height values. NOTE: This is a candidate for the 8.0 branch. Reviewed-by: José Fonseca <[email protected]>
* mesa: remove _mesa_ffs(), implement ffs() for non-GNU platformsBrian Paul2012-01-124-10/+10
| | | | | | | | | | | Call ffs() and ffsll() everywhere. Define our own ffs(), ffsll() functions when the platform doesn't have them. v2: remove #ifdef _WIN32, __IBMC__, __IBMCPP_ tests inside ffs() implementation. The #else clause was recursive. Reviewed-by: Kenneth Graunke <[email protected]> Tested-by: Alexander von Gluck <[email protected]>
* vbo: introduce vbo_get_minmax_indices functionYuanhan Liu2012-01-122-2/+3
| | | | | | | | | | | | | | | | | | | | | | | Introduce vbo_get_minmax_indices() function to handle the min/max index computation for nr_prims(>= 1). The old code just compute the first prim's min/max index; this would results an error rendering if user called functions like glMultiDrawElements(). This patch servers as fixing this issue. As when nr_prims = 1, we can pass 1 to paramter nr_prims, thus I made vbo_get_minmax_index() static. v2: per Roland's suggestion, put the indices address compuation into vbo_get_minmax_index() instead. Also do comination if possible to reduce map/unmap count v3: per Brian's suggestion, use a pointer for start_prim to avoid structure copy per loop. Signed-off-by: Yuanhan Liu <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* Enable is_front_buffer_rendering variable in case of GL_FRONT_AND_BACKAnuj Phogat2012-01-111-1/+1
| | | | | | | | | | glDrawBuffer(GL_FRONT_AND_BACK) results in to segmentation fault if intel->is_front_buffer_rendering is not enabled with GL_FRONT_AND_BACK. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44153 Reported-by: Yi Sun <[email protected]> Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Don't use _mesa_ir_link_shader to do our dirty workIan Romanick2012-01-111-7/+85
| | | | | | | | | | | | | | | | | | | | | Instead, do the uniform setting and input / output mapping directly in brw_link_shader. Hurray for not generating Mesa IR! However, once the i965 driver stops calling _mesa_ir_link_shader, UsesClipDistance and UsesKill are no longer set. Ideally gen6_upload_vs_push_constants should use the gl_shader_program, but I don't see a way to propagate the information there. The other alternative, since this is the only usage, is to move gl_vertex_program::UsesClipDistance to brw_vertex_program. The compile (and precompile) stages use UsesKill to determine the cache key for the shader. This is then used to determine whether or not to compile the shader. Calculating this data during compilation is too late. Signed-off-by: Ian Romanick <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Acked-by: Eric Anholt <[email protected]>
* i965: Don't calculate masks of used FS inputsIan Romanick2012-01-111-0/+15
| | | | | | | | | | | | | This previously enabled some optimizations in the fragment shader (interpolation, etc.) if some input components were always 0.0 or 1.0. However, this data was generated by analyzing Mesa IR. The next patch in this series removes generation of Mesa IR for GLSL paths. When we detect that case, just set the used mask to ~0 and circumvent the optimizations. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Track fixed-function fragment shader as a shaderIan Romanick2012-01-114-5/+9
| | | | | | | | | | | | Previously the fixed-function fragment shader was tracked as a gl_program. This means that it shows up in the driver as a Mesa IR program instead of as a GLSL IR program. If a driver doesn't generate Mesa IR from the GLSL IR, that program is empty. If the program is empty there is either no rendering or a GPU hang. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* i965: Don't reallocate push constant URB space on new VS programs.Kenneth Graunke2012-01-113-10/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The gen7_urb atom depends on CACHE_NEW_VS_PROG and CACHE_NEW_GS_PROG, causing gen7_upload_urb() to be called when switching to a new VS program. In addition to partitioning the URB space between the VS and GS, gen7_upload_urb() also allocated space for VS and PS push constants. Unfortunately, this meant that whenever CACHE_NEW_VS was flagged, we'd reallocate the space for the PS push constants. According to the BSpec, after sending 3DSTATE_PUSH_CONSTANT_ALLOC_PS, we must reprogram 3DSTATE_CONSTANT_PS prior to the next 3DPRIMITIVE. Since our URB allocation for push constants is entirely static, it makes sense to split it out into its own atom that only subscribes to BRW_NEW_CONTEXT. This avoids reallocating the space and trashing constants. Fixes a rendering artifact in Extreme Tuxracer, where instead of a snow trail, you'd get a bright red streak (affectionately known as the "bloody penguin bug"). This also explains why adding VS-related dirty bits to gen7_ps_state made the problem disappear: it made 3DSTATE_CONSTANT_PS be emitted after every 3DSTATE_PUSH_CONSTANT_ALLOC_PS packet. NOTE: This is a candidate for the 7.11 branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38868 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Fix compiler warning from uninitialized "success" value.Eric Anholt2012-01-111-1/+1
| | | | | This shouldn't happen, because the DDX should only load this driver if IS_965. But better to do something defined in that case.
* i965/gen7: Fix segfault in transform feedback to DYNAMIC_DRAW buffers.Eric Anholt2012-01-111-2/+3
| | | | Fixes piglit EXT_transform_feedback/buffer-usage.
* i965/vs: Try to emit more components of constant vectors at once.Eric Anholt2012-01-111-2/+27
| | | | | | | | | | | | | | We were naively emitting each component at a time, even if we were emitting the same value to multiple channels. Improves on a codegen regression from the old VS to the new VS on some unigine shaders (because we emit constant vecs/matrices as immediates instead of loading them as push constants, so we had over 4x the instructions for using them). shader-db results: Total instructions: 58594 -> 58540 11/870 programs affected (1.3%) 765 -> 711 instructions in affected programs (7.1% reduction)
* xlib: stop calling XShmQueryVersion()Brian Paul2012-01-111-8/+8
| | | | | | | | | | It caused an X protocol error in some (rare) situations. This is a follow-on to the previous commits which fixes a bug reported by Wayne E. Robertz. NOTE: This is a candidate for the 7.11 branch. Reviewed-by: Adam Jackson <[email protected]>
* xlib: call register_with_display() in Fake_glXChooseFBConfig()Brian Paul2012-01-111-0/+3
| | | | | | | | | | | | as we do in Fake_glXChooseVisual(). This registers the MesaGLX extension on the display so we can clean up buffers, etc. when the display connection is closed. Fixes a bug reported by Wayne E. Robertz. NOTE: This is a candidate for the 7.11 branch. Reviewed-by: Adam Jackson <[email protected]>