aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/intel/intel_screen.c
Commit message (Collapse)AuthorAgeFilesLines
* i965: Move the remaining intel code to the i965 directory.Eric Anholt2013-06-261-1409/+0
| | | | | | | | | Now that i915's forked off, they don't need to live in a shared directory. Acked-by: Kenneth Graunke <[email protected]> Acked-by: Chad Versace <[email protected]> Acked-by: Adam Jackson <[email protected]> (and I hear second hand that idr is OK with it, too)
* i965/gen7+: Disable fast color clears on shared regions.Paul Berry2013-06-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | In certain circumstances the memory region underlying a miptree is shared with other miptrees, or with other code outside Mesa's control. This happens, for instance, when an extension like GL_OES_EGL_image or GLX_EXT_texture_from_pixmap extension is used to associate a miptree with an image existing outside of Mesa. When this happens, we need to disable fast color clears on the miptree in question, since there's no good synchronization mechanism to ensure that deferred clear writes get performed by the time the buffer is examined from the other miptree, or from outside of Mesa. Fortunately, this should not be a performance hit for most applications, since most applications that use these extensions use them for importing textures into Mesa, rather than for exporting rendered images out of Mesa. So most of the time the miptrees involved will never experience a clear. v2: Rework based on the fact that we have decided not to use an accessor function to protect access to the region. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Ensure that front/back buffers are fast-clear resolved.Paul Berry2013-06-121-1/+1
| | | | | | | | | | | | We already had code in intel_downsample_for_dri2_flush() for downsampling front and back buffers when multisampling was in use. This patch extends that function to perform fast color clear resolves when necessary. To account for the additional functionality, the function is renamed to simply intel_resolve_for_dri2_flush(). Reviewed-by: Eric Anholt <[email protected]>
* i965: Require hardware contexts (and thus Kernel 3.6) on Gen6+.Kenneth Graunke2013-05-201-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Hardware contexts are necessary to reasonably support OpenGL 3.2. In particular, we currently maintain software counters for transform feedback buffer offsets and counters, which relies on knowing the number of primitives generated. Geometry shaders violate that assumption. At the time of writing, Debian has moved to Kernel 3.8, which means most people probably have a newer kernel by now. It's also worth noting that this patch won't land until Mesa 10 which is currently targeted for September. By that point, even more people will have a newer kernel. Also, don't bother trying to allocate contexts on pre-Gen6, as it currently will always fail, and if this changes in the future, we'll need to reevaluate our hw_ctx/gen checks. This patch leaves the code for flagging BRW_NEW_CONTEXT on new batchbuffers if hw_ctx == NULL since that still occurs pre-Gen6. Also remove the Gen7+ check for kernel 3.3, since it's now redundant. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Bump kernel requirement to 3.3 on Ivybridge.Kenneth Graunke2013-05-201-15/+11
| | | | | | | | | | Kernel 3.3 introduced the SOL reset execbuf parameter, needed for GL 3.0 on Ivybridge. Bumping the requirement will give an obvious error message rather than simply reporting GL 2.1. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* mesa: Make gl_renderbuffers backed by EGL images use FinishRenderTexture.Eric Anholt2013-05-171-0/+1
| | | | | | | | | | | | | This is the opportunity that radeon and intel drivers rely on for flushing render targets that may get reused as textures. Before EGL, that only happened for GL_TEXTURE attachments. Fixes piglits: KHR_gl_renderbuffer_image/renderbuffer-texture OES_EGL_image/renderbuffer-texture NOTE: This is a candidate for the 9.1 branch. Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Always enable GL 2.0 support.Eric Anholt2013-04-291-24/+3
| | | | There's no point in shipping a non-GL2 driver today.
* mesa: Use quotes on bool driconf options to prevent stdbool.h breakage.Eric Anholt2013-04-191-14/+14
| | | | | | | | | | | | | Since stdbool.h's "true" and "false" are #defines, they got expanded when used as macro arguments, and that expanded value was stored in the XML string, producing XML that driconf would then fail to parse. Currently no drivers included stdbool along with driconf, but I keep accidentally doing so on intel as we move towards using normal C. v2: rebase on master. Reviewed-by: Kenneth Graunke <[email protected]> (v1)
* mesa: remove #include "mfeatures.h" from numerous source filesBrian Paul2013-04-171-1/+0
| | | | | | None of the remaining FEATURE_x symbols in mfeatures.h are used anymore. Reviewed-by: Jordan Justen <[email protected]>
* intel: Add a null pointer check before dereferencing the pointerAnuj Phogat2013-04-171-0/+9
| | | | | Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel: Remove the texture_tiling driconf option.Kenneth Graunke2013-04-081-5/+1
| | | | | | | | | | | | This option can force textures to be untiled. However, on Gen6+, depth buffers must be Y-tiled. MSAA buffers also must be Y-tiled. So setting this option on even a trivial application like glxgears causes assertion failures in a debug build, and likely GPU hangs in a release build. It's just giving users a license to shoot themselves in the foot. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: Remove check for kernel 2.6.29.Kenneth Graunke2013-04-081-7/+0
| | | | | | | | | | | | | Now that we require 2.6.39, there's no need to also check for 2.6.29. Calling drm_intel_bufmgr_gem_enable_fenced_relocs() without checking should be safe, as it simply sets a flag. This does remove the check for zero fences available, but that doesn't seem worth checking. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: Require kernel 2.6.39 for relaxed relocation support.Kenneth Graunke2013-04-081-3/+4
| | | | | | | | | | Chris Wilson's relaxed relocation patch landed in March 2011. Anyone running pre-3.0 kernels probably isn't going to get the latest Mesa anyway. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Add a driconf option to disable flush throttling.Paul Berry2013-03-211-1/+2
| | | | | | | | | | | | | | | Normally when submitting the first batch buffer after a flush, we check whether the GPU has completed processing of the first batch buffer of the previous frame. If it hasn't, we wait for it to finish before submitting any more batches. This prevents GPU-heavy and CPU-light applications from racing too far ahead of the current frame, but at the expense of possibly lower frame rates. Sometimes when benchmarking we want to disable this mechanism. This patch adds the driconf option "disable_throttling" to disable the throttling mechanism. Reviewed-by: Eric Anholt <[email protected]>
* Add dri image entry point for creating image from fdKristian Høgsberg2013-03-181-4/+55
| | | | Reviewed-by: Ander Conselvan de Oliveira <[email protected]>
* intel: Remove the struct intel_region reuse hash table.Eric Anholt2013-03-051-14/+0
| | | | | | | | | | | | I don't see any reason for it -- it was introduced with the DRI2 invalidate work by krh in 2010 with no explanation. I suspect it was something about wanting the same drm_intel_bo struct underneath multiple openings of the BO within one process, but that's covered by libdrm at this point. As far as the struct region goes, it is not threadsafe, so multiple contexts sharing a region could have mixed up the map_count and assertion failed or worse. Reviewed-by: Chad Versace <[email protected]>
* i965: Make sRGB-capable framebuffers by default.Eric Anholt2013-03-011-2/+9
| | | | | | | | | | | | | The GLX extension lets you expose visuals that explicitly guarantee you that the GL_FRAMEBUFFER_SRGB_CAPABLE flag will be set, but we can set the flag even while the visual doesn't provide the guarantee. This appears to be consistent with other implementations, as we've seen several apps now that don't require an srgb visual and assume sRGB will work without checking the GL_FRAMEBUFFER_SRGB_CAPABLE flag. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55783 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60633 Reviewed-and-tested-by: Ian Romanick <[email protected]>
* intel: Enable __DRI_API_OPENGL_CORE api with dri2 contextsJordan Justen2013-02-281-0/+2
| | | | | | | | | | | | | Without this set, dri_util.c:dri2CreateContextAttribs will reject requests to create a context with __DRI_API_OPENGL_CORE. This prevents a 3.2 core profile context from being created even when MESA_GL_OVERRIDE_VERSION=3.2 is used. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: update max versions based on MESA_GL_VERSION_OVERRIDEJordan Justen2013-02-281-0/+10
| | | | | | | | | If the override is version is >= 3.1, then update the max_gl_core_version. Otherwise, update max_gl_compat_version. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Enable OpenGL ES 3.0 on Sandy BridgeIan Romanick2013-02-221-1/+1
| | | | | | | | | | Regardless of what we put in the screen structure, all of the extensions that compute_version_es2 checks are present and 3.0 will be exposed anyway. NOTE: This is a candidate for the 9.1 branch. Signed-off-by: Ian Romanick <[email protected]>
* intel: Fix regression in intel_create_image_from_name stride handlingTapani Pälli2013-02-041-1/+1
| | | | | | | | | Strangely, the DRIimage interface we have passes the pitch in pixels instead of bytes, which anholt missed in the change to using bytes for region pitch. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: make sure to setup image dimension in image_from_planar setupAbdiel Janulgue2013-02-041-0/+1
| | | | | | | | Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=60212 Tested-by: Scott Moreau <[email protected]> Tested-by: Tiago Vignatti <[email protected]> Reviewed-by: Chad Versace <[email protected]> Signed-off-by: Abdiel Janulgue <[email protected]>
* intel: implement create image from textureAbdiel Janulgue2013-02-011-21/+138
| | | | | | | | | | | | | | | | | Save miptree level info to DRIImage: - Appropriately-aligned base offset pointing to the image - Additional x/y adjustment offsets from above. v8: -Bump intelImageExtension version v9: -Don't use internal _eglError but implement error reporting in new DRI inteface instead. This fixes Android build problems based on feedback from Adrian M Negreanu and Chad Versace. -Move the non-tile-aligned check and error-reporting to intel_set_texture_image_region v10: -Don't #include "egl/main/eglcurrent.h". [chadv] Reviewed-by: Eric Anholt <[email protected]> (v6) Acked-by: Chad Versace <[email protected]> (v10) Signed-off-by: Abdiel Janulgue <[email protected]>
* i965: Bump maximum supported ES2 context version to 3.0Chad Versace2013-01-251-1/+1
| | | | | | | | | | Since patch "i965: Validate requested GLES context version in brwCreateContext", we have been able to create ES 3.0 contexts due to the max version check. So...bump the max version. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Don't expose XRGB8888 visuals any moreIan Romanick2013-01-211-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | There really isn't any point. There is no resource savings, and we have to do gymnastics in the driver to make it work. There are also bad interactions with multisampling and OpenGL ES 3.0. In ES3, a multisample-to-singlesample blit must have identical source and destination format. This means a multisample RGBA8 to singlesample RGB8 (window) blit will generate an error. Also in ES3, RGB8 is not a renderable format. This means that the application CANNOT make an RGB8 multisample renderbuffer. As a result, if an application gets an RGB8 window and wants to do multisample FBO rendering, it will probably break. "Fixes" gles3conform framebuffer_blit_functionality_multisampled_to_singlesampled_blit test on RGB8 visuals. v2: Fix 'formats' array size. Suggested by Ken. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Acked-by: Eric Anholt <[email protected]>
* i965: Enable floating-point textures alwaysIan Romanick2013-01-211-18/+5
| | | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Acked-by: Eric Anholt <[email protected]>
* intel: Make intel_region's pitch be bytes instead of pixels.Eric Anholt2013-01-181-10/+7
| | | | | | | | | | | | We almost never want a stride in pixels -- if you're doing anything with a stride, you're specifying an offset or incrementing a pointer, and in both cases you had to multiply by cpp to get the bytes value you wanted. But worse, on the way to creating a region from a new tiled BO, we divided by cpp to get pitch in pixels, and for an RGB32 buffer (an upcoming change) the pitch wouldn't divide exactly, and we'd end up with a wrong stride in our region. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Expose support for DRI_API_GLES3Chad Versace2013-01-151-0/+2
| | | | | | | | | If the hardware/driver combo supports GLES3, then set the GLES3 bit in intel_screen's bitmask of supported DRI API's. Neither the EGL nor GLX layer uses the bit yet. Signed-off-by: Chad Versace <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* intel: Move validation of context version into intelInitContextChad Versace2013-01-151-22/+9
| | | | | | | | | | | | | | | | | | | | | Each driver (i830, i915, i965) used independent but similar code to validate the requested context version. With the rececnt arrival of GLES3, that logic has needed an update. Rather than apply identical updates to each drivers validation code, let's just move the validation into the shared routine intelInitContext. This refactor required some incidental changes to functions i830CreateContext and intelInitContext. For each function, this patch: - Adds context version parameters to the signature. - Adds a DRI_CTX_ERROR out param to the signature. - Sets the DRI_CTX_ERROR at each early return. Tested against gen6 with piglit egl-create-context-verify-gl-flavor. Verified that this patch does not change the set of exposed EGL context flavors. Signed-off-by: Chad Versace <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* intel: Set screen's api mask according to hw capabilities (v3)Chad Versace2013-01-151-11/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, intelInitScreen2 set DRIScreen::api_mask with the hacky heuristic below: if (gen >= 3) api_mask = GL | GLES1 | GLES2; else api_mask = 0; This hack was likely broken on gen2 (i830), but I don't care enough to properly investigate. It appears that every EGLConfig on i830 has EGL_RENDERABLE_TYPE=0, and thus eglCreateContext will never succeed. Anyway, moving on to living drivers... With the arrival of EGL_OPENGL_ES3_BIT_KHR, this heuristic is now insufficient. We must enable the GLES3 bit if and only if the driver is capable of creating a GLES3 context. This requires us to determine the maximum supported context version supported by the hardware/driver for each api *during initialization of intel_screen*. Therefore, this patch adds four new fields to intel_screen which indicate the maximum supported context version for each api: max_gl_core_version max_gl_compat_version max_gl_es1_version max_gl_es2_version The api mask is now correctly set as: api_mask = GL; if (max_gl_es1_version > 0) api_mask |= GLES1; if (max_gl_es2_version > 0) api_mask |= GLES2; Tested against gen6 with piglit egl-create-context-verify-gl-flavor. Verified that this patch does not change the set of exposed EGL context flavors. v2: - Replace the if-tree on gen with a switch, for Ian. - Unconditionally enable the DRI_API_OPENGL bit, for Ian. v3: - Drop max gl version to 1.4 on gen3 if !has_occlusion_query, because occlusion queries entered core in 1.5. For Ian. v4: - Drop ES2 version back to 2.0 due to rebase (Ian). Signed-off-by: Chad Versace <[email protected]> Reviewed-by: Ian Romanick <ian.d.romanick.intel.com>
* driconf: Add a new option: disable_glsl_line_continuationsCarl Worth2013-01-111-1/+2
| | | | | | | | | This is to enable a quirk for Savage2 which includes a shader with a stray '\' at the end of a comment line. Interpreting that backslash as a line continuation will break the compilation of the shader, so we need a way to disable this. Reviewed-by: Kenneth Graunke <[email protected]>
* glx/dri2: add and use new driver hook flush_with_flagsMarek Olšák2012-12-021-1/+1
|
* mesa: Rename API_OPENGL to API_OPENGL_COMPAT.Paul Berry2012-11-291-1/+1
| | | | | | | | | | This should help avoid confusion now that we're using the gl_api enum to distinguishing between core and compatibility API's. The corresponding enum value for core API's is API_OPENGL_CORE. Acked-by: Eric Anholt <[email protected]> Acked-by: Matt Turner <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* intel: Use designated initializers for DRI extension structsChad Versace2012-11-191-16/+20
| | | | | | | | | | | | | | | All Intel code is compiled with -std=c99. There is no excuse to not use designated initializers. As a nice benefit, the code is now more friendly to grep. Without designated initializers, psychic prowess is required to find the initialization of DRI extension function pointers with grep. I have observed several people, when they first encounter the DRI code, fail at statically chasing the DRI function pointers due to this problem. Reviewed-by: Matt Turner <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: support for 16 bit config with 24 depth and 8 stencilTapani Pälli2012-10-291-2/+7
| | | | | | | | | Patch adds additional singlesample config with 565 color buffer, 24 bit depth and 8 bit stencil buffer. This makes Quadrant benchmark work on Android. Tested with Sandybridge and Ivybridge machines. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* intel: If the visual is sRGB, use an sRGB internal formatIan Romanick2012-10-291-0/+2
| | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* dri: Convert driCreateConfigs to use a gl_format enumIan Romanick2012-10-291-20/+15
| | | | | | | | | | | This is instead of the pair of GLenums for format and type that were previously used. This is necessary for the Intel drivers to expose sRGB framebuffer formats. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* intel: Add missing #include <time.h>Quentin Glidic2012-10-091-0/+1
| | | | | | | | Commit 006c1a3c652803e2ff8d5f7ea55c9cb5d8353279 introduced a call to clock_gettime, but failed to include <time.h>, breaking the build in some cases. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Don't call intelDestroyContext if there is no context to destroyIan Romanick2012-09-281-1/+3
| | | | | | | | | | | | Some error paths in the device-specific context creation functions can exit before the deintel_context structure is allocated. NOTE: This is a candidate for the 9.0 branch. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53618 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54301
* intel: Don't advertise GLX_SWAP_COPY_OMLChad Versace2012-09-271-6/+6
| | | | | | | | This patch removes all gl_config's with swapMethod=GLX_SWAP_COPY_OML. When page flipping, we are unable to comply with swap-copy semantics. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Mark some file-local code as static.Eric Anholt2012-09-271-1/+1
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Add map_stencil_as_y_tiled to intel_region_get_tile_masks.Paul Berry2012-09-121-1/+1
| | | | | | | | | | | When the blorp engine is performing a blit from one stencil buffer to another, it sets up the surface state for these buffers as Y-tiled, so it needs to be able to force intel_region_get_tile_masks() to return the appropriate masks for a Y-tiled region. NOTE: This is a candidate for stable release branches. Acked-by: Eric Anholt <[email protected]>
* intel: avoid undefined variable warnings in intel_screen.cPaul Berry2012-09-061-2/+3
| | | | Reviewed-by: Matt Turner <[email protected]>
* mesa: s/FREE/free/Brian Paul2012-09-011-8/+8
| | | | | | | v2: replace instances in dri/common/ dirs Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: s/CALLOC/calloc/Brian Paul2012-09-011-5/+5
| | | | | | | v2: replace instances in dri/common/ dirs Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* dri: Rework planar image interfaceJakob Bornecrantz2012-08-311-8/+127
| | | | | | | | | | | | | | | | | | | | | | As discussed with Kristian on #wayland. Pushes the decision of components into the dri driver giving it greater freedom to allow t to implement YUV samplers in hardware, and which mode to use. This interface will also allow drivers like SVGA to implement YUV surfaces without the need to sub-allocate and instead send 3 seperate buffers for each channel, currently not implemented. I have tested these changes on Gallium Svga. Scott tested them on both intel and Gallium Radeon. Kristan and Pekka tested them on intel. v2: Fix typo in dri2_from_planar. v3: Merge in intel changes. Tested-by: Scott Moreau <[email protected]> Tested-by: Pekka Paalanen <[email protected]> Tested-by: Kristian Høgsberg <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Signed-off-by: Jakob Bornecrantz <[email protected]>
* intel: Clean up bits of cruft in intelCreateContextIan Romanick2012-08-291-40/+11
| | | | | | This and the previous three commits should probably be squashed together... Signed-off-by: Ian Romanick <[email protected]>
* i965: Set context flagsIan Romanick2012-08-291-2/+3
| | | | Signed-off-by: Ian Romanick <[email protected]>
* i965: Reenable the fragment shader precompile.Kenneth Graunke2012-08-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | Precompiling the shader at link time often allows us to avoid compiling it at the first use. This moves the expensive compilation and optimization process to game or level load time, rather than at draw time, where we really can't avoid any cycles and don't want to risk stalling the GPU. The downside is that we have to guess the non-orthagonal state the program will have set when it draws with the shader. Previously, we guessed wrong for nearly every shader, so it wasn't useful. With the recent SamplerUnits rework and this series, we've either eliminated state or made smarter guesses, and usually get it right now. In the L4D2 time demo, I now have 39 fragment shader recompiles and no vertex shader recompiles. Before this series and the SamplerUnits rework, I had 206 fragment shader recompiles and 192 vertex shader recompiles. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* dri: Remove image write functionJakob Bornecrantz2012-08-261-28/+0
| | | | | | | | Since its not used by anything anymore and no release has gone out where it was being used. Tested-by: Scott Moreau <[email protected]> Signed-off-by: Jakob Bornecrantz <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-11 22:36:16 +0000