aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/intel
Commit message (Collapse)AuthorAgeFilesLines
* intel: Fix compile warning from 7b6424143d8bf572cadd46adcbaa91d2a5598635Eric Anholt2012-05-141-2/+2
|
* intel: Fix compiler warning from 3cd7bee48f7caf7850ea64d40f43875d4c975507Eric Anholt2012-05-141-2/+0
|
* intel: Work around differences between C and C++ scoping rules.Paul Berry2012-05-102-25/+29
| | | | | | | | | | | | | | In C++, if a struct is defined inside another struct, or its name is first seen inside a struct or function, the struct is nested inside the namespace of the struct or function it appears in. In C, all structs are visible from toplevel. This patch explicitly moves the decalartions of intel_batchbuffer to toplevel, so that it does not get nested inside a namespace when header files are included from C++. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* intel: Add extern "C" declarations to headersPaul Berry2012-05-105-1/+36
| | | | | | | | These declarations are necessary to allow C++ code to call C code without causing unresolved symbols (which would make the driver fail to load). Reviewed-by: Chad Versace <[email protected]>
* i965: Fix mipmap offsets for HiZ and separate stencil buffers.Paul Berry2012-05-074-19/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When rendering to a miplevel other than 0 within a color, depth, stencil, or HiZ buffer, we need to tell the GPU to render to an offset within the buffer, so that the data is written into the correct miplevel. We do this using a coarse offset (in pages), and a fine adjustment (the so-called "tile_x" and "tile_y" values, which are measured in pixels). We have always computed the coarse offset and fine adjustment using intel_renderbuffer_tile_offsets() function. This worked fine for color and combined depth/stencil buffers, but failed to work properly when HiZ and separate stencil were in use. It failed to work because there is only one set of fine adjustment controls shared by the HiZ, depth, and stencil buffers, so we need to choose tile_x and tile_y values that are compatible with the tiling of all three buffers, and then compute separate coarse offsets for each buffer. This patch fixes the HiZ and separate stencil case by replacing the call to intel_renderbuffer_tile_offsets() with calls to two functions: intel_region_get_tile_masks(), which determines how much of the adjustment can be performed using offsets and how much can be performed using tile_x and tile_y, and intel_region_get_aligned_offset(), which computes the coarse offset. intel_region_get_tile_offsets() is still used for color renderbuffers, so to avoid code duplication, I've re-worked it to use intel_region_get_tile_masks() and intel_region_get_aligned_offset(). On i965 Gen6, fixes piglit tests "texturing/depthstencil-render-miplevels 1024 X" where X is one of (depth, depth_and_stencil, depth_stencil_single_binding, depth_x, depth_x_and_stencil, stencil, stencil_and_depth, stencil_and_depth_x). On i965 Gen7, the variants of "texturing/depthstencil-render-miplevels" that contain a stencil buffer still fail, due to another problem: Gen7 seems to ignore the 3 LSB's of the tile_y adjustment (and possibly also tile_x). v2: Removed spurious comments. Added assertions to check preconditions of intel_region_get_aligned_offset(). Reviewed-by: Chad Versace <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* intel: Disable ARB_framebuffer_object in ES contextsChad Versace2012-05-071-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes ARB_framebuffer_object from the GLES1 and GLES2 extension lists in intel_extensions_es.c. Fixes a crash in the Android browser on Ice Cream Sandwich. The Android browser crashed because it did the following, which is legal in GLES2 but not in ARB_framebuffer_object. glGenFramebuffers(1, &fb); glBindFramebuffer(GL_FRAMEBUFFER, fb); // render render render... glDeleteFramebuffers(1, &fb); // go do other stuff... glBindFramebuffer(GL_FRAMEBUFFER, fb); // This bind unexpectedly failed, and the app panics. The semantics of glBindFramebuffer specified by ARB_framebuffer_object (a desktop GL extension) and GLES2 specs are incompatible. The ideal solution to fix this is to create separate API entry points for glBindFramebuffer, one for GL and the other for GLES2. But, until that work is complete, disabling ARB_framebuffer_object in GLES2 contexts safely fixes the problem. Likewise, the semantics of glBindFramebuffer in ARB_framebuffer_object and of glBindFramebufferOES in OES_framebuffer_object (a GLES1 extension) are incompatible. Even though the functions have different names, the semantic difference still results in a bug because both API calls are implemented by a single function, _mesa_BindFramebufferEXT, which handles the semantic difference incorrectly. Again, disabling ARB_framebuffer_object in GLES1 contexts safely fixes this problem. According to the ARB_framebuffer_object spec, the extension is an amalgamation of EXT_framebuffer_object EXT_framebuffer_blit EXT_packed_depth_stencil EXT_framebuffer_multisample By disabling this extension, however, no functionality is removed from GLES1 and GLES2 contexts because 1) the first three extensions are explicitly enabled in Intel's ES extension lists and 2) no functionality of the last extension is exposed in an ES context. Note: This is a candidate for the 8.0 branch. See-also: http://www.mail-archive.com/[email protected]/msg21006.html CC: Charles Johnson <[email protected]> CC: Sean Kelley <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Remove pointless software fallback for glBitmap on Gen6.Kenneth Graunke2012-05-041-4/+0
| | | | | | | | | | We already have a meta path below that works just fine; no apparent regressions in oglconform. NOTE: This is a candidate for the 8.0 branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46834 Reviewed-by: Chad Versace <[email protected]>
* intel: Return success when asked to allocate a 0-width/height renderbuffer.Eric Anholt2012-05-041-0/+3
| | | | | | | | | | | | | It seems silly that GL lets you allocate these given that they're framebuffer attachment incomplete, but the webgl conformance tests actually go looking to see if the getters on 0-width/height depth/stencil renderbuffers return good values. By failing out here, they all got smashed to 0, which turned out to be correct for all the getters they tested except for GL_RENDERBUFFER_INTERNAL_FORMAT. Now, by succeeding but not making a miptree, that one also returns the expected value. Acked-by: Kenneth Graunke <[email protected]>
* i965: Add support for GL_ARB_draw_buffers_blend.Eric Anholt2012-05-041-0/+4
| | | | | | Tested with piglit fbo-draw-buffers-blend and intel oglconform. Reviewed-by: Kenneth Graunke <[email protected]>
* gbm: Add gbm_bo_write entry pointKristian Høgsberg2012-05-032-2/+31
| | | | | | | | | | | | | | | | This new gbm entry point allows writing data into a gbm bo. The bo has to be created with the GBM_BO_USE_WRITE flag, and it's only required to work for GBM_BO_USE_CURSOR_64X64 bos. The gbm API is designed to be the glue layer between EGL and KMS, but there was never a mechanism initialize a buffer suitable for use with KMS hw cursors. The hw cursor bo is typically not compatible with anything EGL can render to, and thus there's no way to get data into such a bo. gbm_bo_write() fills that gap while staying out of the efficient cpu->gpu pixel transfer business. Reviewed-by: Ander Conselvan de Oliveira <[email protected]>
* intel: use _mesa_is_winsys/user_fbo() helpersBrian Paul2012-05-013-6/+8
| | | | Reviewed-by: Eric Anholt <[email protected]>
* i965: Support Android RGBX8888 format for EGL generated imagesSean V Kelley2012-04-301-0/+10
| | | | | | | | | | Enabled MESA_FORMAT_RGBX8888_REV for RGBX. Android software requires RGBX8888 format to be supported for software rendering. That requires EGL to be capable of generating images from this format. Signed-off-by: Sean V Kelley <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: set dri_format field for all imagesAnder Conselvan de Oliveira2012-04-301-0/+18
| | | | | | Only images created with intel_create_image() had the field properly set. Set it also on intel_dup_image(), intel_create_image_from_name() and intel_create_image_from_renderbuffer().
* intel: properly return the image format on intel_query_imageAnder Conselvan de Oliveira2012-04-301-1/+2
|
* i965: When the kernel lacks the LLC check, assume it's present on gen >= 6.Eric Anholt2012-04-111-3/+7
| | | | | The param wasn't added until drm-intel-next for 3.4, so we were missing our various LLC fast-paths.
* intel: Drop backwards compat code for not having libdrm with the LLC check.Eric Anholt2012-04-111-4/+0
|
* i965: Stop lying about cpp and height of a stencil buffer.Paul Berry2012-04-103-39/+45
| | | | | | | | | | | | | | | | | | | | | | | When using a separate stencil buffer, i965 requires that the pitch of the buffer (in the 3DSTATE_STENCIL_BUFFER command) be specified as 2x the actual pitch. Previously this was accomplished by doubling the "cpp" and "pitch" values stored in the intel_region data structure, and halving the height. However, this was confusing, and it led to a subtle (but benign) bug: since a stencil buffer is W-tiled, its true height must be aligned to a multiple of 64; we were accidentally aligning its faux height to a multiple of 64, causing memory to be wasted. Note that for window system stencil buffers, the DDX also doubles the cpp and pitch values. To facilitate fixing this DDX server bug in the future, we fix the cpp and pitch values we receive from the X server only if cpp has the "incorrect" value of 2. Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]> v2: Clarify comments about the DDX.
* i965: Add support for sampling texture buffer objects on gen7+.Eric Anholt2012-04-091-0/+4
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/aub: Dump a final bitmap from DestroyContext.Kenneth Graunke2012-04-023-29/+41
| | | | | | | | | | | | | | | Certain applications don't call SwapBuffers before exiting. Yet, we'd really like to see a bitmap containing the final rendered image even if they choose never to present it. In particular, Piglit tests (at least with -auto -fbo) fall into this category. Many of them failed to dump any images at all. Dumping one final image at context destruction time seems to work. We may wish to pursue a more elegant solution later. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: add PCI IDs for Ivy Bridge GT2 server variantEugeni Dodonov2012-04-012-1/+4
| | | | | | | Those IDs are used by Bromolow. Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Eugeni Dodonov <[email protected]>
* intel: Add some PCI IDs for Haswell.Kenneth Graunke2012-03-302-2/+20
| | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eugeni Dodonov <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Disable HiZ on Haswell for now.Kenneth Graunke2012-03-301-1/+1
| | | | | | | | Getting HiZ working means updating all the state packets for resolves and clears. It's not worth doing until we get the basics working. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Add initial IS_HASWELL() macros.Kenneth Graunke2012-03-303-5/+14
| | | | | | | | | | | For now, these all return 0, as I don't yet want to enable Haswell support. Eventually they will be filled in with proper PCI IDs. Also add an is_haswell field similar to is_g4x to make it easy to distinguish Gen7 and Gen7.5. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: fix un-blanced map_refcount issueYuanhan Liu2012-03-281-4/+4
| | | | | | | | | | | | | | | This is a regression introduced by commit cdcfd5, which forget to increase the map_refcount for successfully-mapped region. Thus caused a wrong non-blanced map_refcount. This would fix the regression found in the two following webglc testcase on Pineview platform: texture-npot.html gl-max-texture-dimensions.html Cc: Anuj Phogat <[email protected]> Signed-off-by: Yuanhan Liu <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* intel: fix TFP at 16-bppDave Airlie2012-03-251-6/+11
| | | | | | | | don't ask why I had to debug this. tested to fix g-s and kwin at 16-bpp on Ironlake. Signed-off-by: Dave Airlie <[email protected]>
* intel: fix null dereference processing HiZ bufferDylan Noblesmith2012-03-221-0/+6
| | | | | | | | | | | Or technically, a near-null dereference. https://bugs.freedesktop.org/show_bug.cgi?id=46303 https://bugs.freedesktop.org/show_bug.cgi?id=46739 NOTE: This is a candidate for the 8.0 branch. Reviewed-by: Chad Versace <[email protected]>
* intel: Make use of the new GPU-unsynchronized map functionality in libdrm.Eric Anholt2012-03-211-1/+3
| | | | | | | | Improves Unigine Tropics performance at 1024x768 by 2.06236% +/- 0.50272% (n=11). Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Drop the tracking of bo_map vs bo_map_gtt for unmapping.Eric Anholt2012-03-212-15/+2
| | | | | | drm_intel_bo_unmap() supports both in the current libdrm version. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Avoid flushing the batch for busy BOs for ARB_mbr with INVALIDATE_BUFFER.Eric Anholt2012-03-211-15/+20
| | | | | | | | | Unigine Tropics uses INVALIDATE_BUFFER and not UNSYNCHRONIZED to reset the buffer object when its streaming wraps. Don't penalize it by flushing the batch at the wrap point, just allocate a new BO and get to using it. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Handle devid overrides using libdrm.Eric Anholt2012-03-211-19/+4
| | | | | Reviewed-by: Yuanhan Liu <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Ask libdrm to dump an AUB file if INTEL_DEBUG=aub.Eric Anholt2012-03-213-0/+37
| | | | | | | It also asks for BMPs in the aub file at SwapBuffers time. Reviewed-by: Yuanhan Liu <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Change the hiz-override env var to a driconf option.Eric Anholt2012-03-203-28/+13
| | | | | | | | | | | The force-enable option is dropped, now that the hardware we were concerned about has HiZ on by default. Now, instead of doing INTEL_HIZ=0 to test disabling hiz, you can set hiz=false. v2: Disable separate stencil on gen6 when HIZ is turned off. (previously, this had to be done manually in addition). Reviewed-by: Kenneth Graunke <[email protected]> (v1)
* intel: Drop the INTEL_NO_BLIT debug environment variable.Eric Anholt2012-03-201-5/+3
| | | | | | | This was added in the i915/i965 merge from the i915 driver, but I don't recall it ever being used since then. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Drop the INTEL_STRICT_CONFORMANCE environment variable.Eric Anholt2012-03-202-33/+5
| | | | | | | | | If you want to test the graphics driver, you want to test it under the conditions that users will see, not some set of additional fallbacks. If you want to test swrast, run the swrast driver (or no_rast=true) instead. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Fix a case when mapping large texture failsAnuj Phogat2012-03-202-10/+23
| | | | | | | | | | | | | This patch handles a case when mapping a large texture fails in drm_intel_gem_bo_map_gtt(). These changes avoid assertion failure later in the driver as reported in following bugs: https://bugs.freedesktop.org/show_bug.cgi?id=44970 https://bugs.freedesktop.org/show_bug.cgi?id=46303 Testing: No regressions in piglit quick.tests Signed-off-by: Anuj Phogat <[email protected]>
* mesa: rework texture completeness testingBrian Paul2012-03-201-1/+1
| | | | | | | | | | | | | | | | | | | Instead of gl_texture_object::_Complete there are now two fields: _BaseComplete and _MipmapComplete. The former indicates whether the base texture level is valid. The later indicates whether the whole mipmap is valid. With sampler objects, a single texture can appear to be both complete and incomplete at the same time. See the GL_ARB_sampler_objects spec for more details. To implement this we now check if the texture is complete with respect to a sampler state. Another benefit of this is we no longer need to invalidate a texture's completeness state when we change the minification/magnification filters with glTexParameter(). Reviewed-by: José Fonseca <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: fixup W-tile offset computation to take swizzling into accountDaniel Vetter2012-03-057-22/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's even a comment in the code containing the right swizzling computations! Previously this has not been noticed because we need to manually enabled swizzling on snb/ivb (kernel 3.4 will do that) and we don't use the separate stencil on ilk (where the bios enables swizzling). This fixes piglit ./bin/fbo-stencil readpixels GL_DEPTH32F_STENCIL8 -auto on recent drm-intel-next kernels. Also remove the comment about ivb, it's stale now. Swizzling detection is done by allocating a temporary x-tiled buffer object. Unfortunately kernels before v3.2 lie on snb/ivb because they claim that swizzling is enable, but it isn't. The kernel commit that fixes this for backport to pre-v3.2 is commit acc83eb5a1e0ae7dbbf89ca2a1a943ade224bb84 Author: Daniel Vetter <[email protected]> Date: Mon Sep 12 20:49:16 2011 +0200 drm/i915: fix swizzling on gen6+ But if the kernel doesn't lie, this now works on swizzling and not swizzling machines. NOTE: This is a candidate for the 8.0 branch. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Don't enable GL_ARB_draw_instanced pre-gen4.Eric Anholt2012-03-021-1/+1
| | | | swtnl doesn't handle this extension.
* i965: Enable the GL_ARB_draw_instanced extension.Kenneth Graunke2012-02-291-0/+1
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: remove MAX_WIDTH usage in intelInitContext()Brian Paul2012-02-241-4/+2
|
* i915: Initialize swrast_texture_image structure fields.Paul Berry2012-02-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 980f6f1 (mesa: move gl_texture_image::Width/Height/DepthScale fields to swrast) moved the initialization of the Width, Height, and DepthScale fields to _swrast_alloc_texture_image_buffer(). However, i915 doesn't call this function because it performs its own buffer allocation. As a result, the Width, Height, and DepthScale fields weren't getting initialized properly, and some operations requiring swrast would fail. This patch ensures that Width, Height, and DepthScale are properly initialized by separating the code that sets them into a new function, _swrast_init_texture_image(), which is called by intel_alloc_texture_image_buffer() as well as _swrast_alloc_texture_image_buffer(). It also moves the initialization of _IsPowerOfTwo into this function. Fixes piglit test fbo/fbo-cubemap on i915. Partially fixes https://bugs.freedesktop.org/show_bug.cgi?id=41216 This is a candidate for the 8.0 branch. Reviewed-and-tested-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: bump DRI_IMAGE extension version to 3Jesse Barnes2012-02-221-1/+1
| | | | | | | To indicate support for the format query. Reviewed-by: Kristian Høgsberg <[email protected]> Signed-off-by: Jesse Barnes <[email protected]>
* gbm: track buffer format through DRI driversJesse Barnes2012-02-222-0/+5
| | | | | | | | | | | | GBM needs the buffer format in order to communicate with DRM and clients for things like scanout. So track the DRI format requested in the various back ends and use it to return the DRI format back to GBM when requested. GBM will then map this into the GBM surface type (which is in turn based on the DRM fb format list). Signed-off-by: Jesse Barnes <[email protected]>
* intel: Silence valgrind warning for getparam ioctl argument.Eric Anholt2012-02-211-0/+1
| | | | It was concerned that the 4 pad bytes on LP64 were uninitialized.
* intel: Fix rendering from textures after RenderTexture().Eric Anholt2012-02-174-60/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's a serious trap for drivers: RenderTexture() does not indicate that the texture is currently bound to the draw buffer, despite FinishRenderTexture() signaling that the texture is just now being unbound from the draw buffer. We were acting as if RenderTexture() *was* the start of rendering and that we could make texturing incoherent with the current contents of the renderbuffer. This caused intel oglconform sRGB Mipmap.1D_textures to fail, because we got a call to TexImage() and thus RenderTexture() on a texture bound to a framebuffer that wasn't the draw buffer, so we skipped validating the new image into the texture object used for rendering. We can't (easily) make RenderTexture() indicate the start of drawing, because both our driver and gallium are using it as the moment to set up the renderbuffer wrapper used for things like MapRenderbuffer(). Instead, postpone the setup of the workaround render target miptree until update_renderbuffer time, so that we no longer need to skip validation of miptrees used as render targets. As a bonus, this should make GL_NV_texture_barrier possible. (This also fixes a regression in the gen4 small-mipmap rendering since 3b38b33c1648b07e75dc4d8340758171e109c598, which switched set_draw_offset from image->mt to irb->mt but didn't move the irb->mt replacement up before set_draw_offset). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44961 NOTE: This is a candidate for the 8.0 branch.
* intel: Improve the fallback debug for framebuffer status checks.Eric Anholt2012-02-171-2/+17
|
* i965: Emit Ivybridge VS workaround flushes.Kenneth Graunke2012-02-152-2/+25
| | | | | | | | | | | | | I recently discovered this text in the BSpec. It seems wise to comply, though I haven't observed it to fix anything yet. Fixes a regression in glean/fbo since 28cfa1fa213fe. NOTE: This is a candidate for stable release branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45221 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: Avoid divide by zero for very small linear blitsIan Romanick2012-02-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | If size is small (such as 1), pitch = ROUND_DOWN_TO(MIN2(size, (1 << 15) - 1), 4); makes pitch = 0. Then height = size / pitch; causes a division-by-zero exception. If pitch is zero, set height to 1 and avoid the division. This fixes piglit's bin/getteximage-formats test and glean's bufferObject test. NOTE: This is a candidate for the 8.0 release branch. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44971
* intel: Remove num_mapped_regions assertion from _intel_batchbuffer_flushIan Romanick2012-02-071-7/+0
| | | | | | | | | | | | | | There are cases where a buffer can be mapped while another buffer is flushed. This can happen in the CopyPixels meta-op path for piglit's fbo-mipmap-copypix. After some discussion with Eric, it seems this assertion is no longer necessary, and it has always been too strict. NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43328 Cc: Eric Anholt <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* intel: check for LLC support when reading mapsEugeni Dodonov2012-02-041-1/+1
| | | | | | | | This checks for advertised LLC support by the GPU instead of relying on the GPU generation for detection. Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Eugeni Dodonov <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-07 19:24:12 +0000