aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/intel
Commit message (Collapse)AuthorAgeFilesLines
* intel: Make the length for PIPE_CONTROL explicit.Kenneth Graunke2012-08-082-9/+9
| | | | | | | | | | | | | | | | PIPE_CONTROL has variable length, depending upon generation and whether we want to do 32-bit or 64-bit data writes. Make it explicit, rather than hiding a length of 4 in the #define for _3DSTATE_PIPE_CONTROL. Generated by s/3DSTATE_PIPE_CONTROL/3DSTATE_PIPE_CONTROL | (4 - 2)/g. This is equivalent since the #define used to have | 2 in it. A grep through the sources shows that all instances have been converted, so it's safe to remove the | 2 from the #define. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Enable uniform buffer objects on gen6+.Eric Anholt2012-08-071-0/+1
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add an offset argument to constant buffer setup.Eric Anholt2012-08-071-0/+1
| | | | | | We'll use this for UBO surfaces. Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Replace VersionMajor/VersionMinor with a Version field.Eric Anholt2012-08-071-3/+1
| | | | | | | | | | | As we get into supporting GL 3.x core, we come across more and more features of the API that depend on the version number as opposed to just the extension list. This will let us more sanely do version checks than "(VersionMajor == 3 && VersionMinor >= 2) || VersionMajor >= 4". v2: Fix a bad <= 30 check. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Fix compiler warnings from winsys msaa.Eric Anholt2012-08-071-1/+1
|
* intel: Advertise multisample DRI2 configs on gen >= 6Chad Versace2012-08-071-3/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This turns on window system MSAA. This patch changes the id of many GLX visuals and configs, but that couldn't be prevented. I attempted to preserve the id's of extant configs by appending the multisample configs to the end of the extant ones. But somewhere, perhaps in the X server, the configs are reordered with multisample configs interspersed among the singlesample ones. Test results: Tested with xonotic and `glxgears -samples 1` on Ivybridge. No piglit regressions on Ivybridge. On Sandybridge, passes 68/70 of oglconform's winsys multisample tests. The two failing tests are: multisample(advanced.pixelmap.depth) multisample(advanced.pixelmap.depthCopyPixels) These tests hang the gpu (on kernel 3.4.6) due to a glDrawPixels/glReadPixels pair on an MSAA depth buffer. I don't expect realworld apps to do that, so I'm not too concerned about the hang. On Ivybridge, passes 69/70. The failing case is multisample(advanced.line.changeWidth). Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Clarify intel_screen_make_configsChad Versace2012-08-071-20/+16
| | | | | | | | | | | | | | This function felt sloppy, so this patch cleans it up a little bit. - Rename `color` to `i`. It is not a color value, only an iterator int. - Move `depth_bits[0] = 0` into the non-accum loop because that is where it used. The accum loop later overwrites depth_bits[0]. - Rename `depth_factor` to `num_depth_stencil_bits`. - Redefine `msaa_samples_array` as static const because it is never modified. Rename to `singlesample_samples`. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* dri: Simplify use of driConcatConfigsChad Versace2012-08-071-8/+2
| | | | | | | | | | | | If either argument to driConcatConfigs(a, b) is null or the empty list, then simply return the other argument as the resultant list. All callers were accomplishing that same behavior anyway. And each caller accopmplished it with the same pattern. So this patch moves that external pattern into the function. Reviewed-by: <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Refactor creation of DRI2 configsChad Versace2012-08-071-91/+98
| | | | | | | | | | DRI2 configs were constructed in intelInitScreen2. That function already does too much, so move verbatim the code for creating configs to a new function, intel_screen_make_configs. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Downsample on DRI2 flushChad Versace2012-08-071-0/+31
| | | | | | Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Support mapping multisample miptreesChad Versace2012-08-072-6/+126
| | | | | | | | | Add two new functions: intel_miptree_{map,unmap}_multisample, to which intel_miptree_{map,unmap} dispatch. Only mapping flat, renderbuffer-like miptrees are supported. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Refactor use of intel_miptree_mapChad Versace2012-08-071-15/+50
| | | | | | | | | | Move the opencoded construction and destruction of intel_miptree_map into new functions, intel_miptree_attach_map and intel_miptree_release_map. This patch prevents code duplication in a future commit that adds support for mapping multisample miptrees. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Refactor intel_miptree_map/unmapChad Versace2012-08-071-17/+50
| | | | | | | | | | | Move the body of intel_miptree_map into a new function, intel_miptree_map_singlesample. Now intel_miptree_map dispatches to the new function. A future commit adds a multisample variant. Ditto for intel_miptree_unmap. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* i965: Mark needed downsamples for msaa winsys buffersChad Versace2012-08-072-0/+13
| | | | | | | | | | | | | Add function intel_renderbuffer_set_needs_downsample. It is a no-op except on multisample winsys buffers shared with DRI2. Mark the needed downsamples with the new function at two locations: - Immediately after drawing is complete. - After blitting. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Define functions for up/downsampling on miptreesChad Versace2012-08-071-2/+72
| | | | | | | Flesh out the stub functions intel_miptree_{up,down}sample. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Allocate miptree for multisample DRI2 buffersChad Versace2012-08-073-8/+162
| | | | | | | | | | | | | | | | | | | | Immediately after obtaining, with DRI2GetBuffersWithFormat, the DRM buffer handle for a DRI2 buffer, we wrap that DRM buffer handle with a region and a miptree. This patch additionally allocates an accompanying multisample miptree if the DRI2 buffer is multisampled. Since we do not yet advertise multisample GL configs, the code for allocating the multisample miptree is currently inactive. This patch adds the following fields to intel_mipmap_tree: singlesample_mt needs_downsample and the following function stubs: intel_miptree_downsample intel_miptree_upsample Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Refactor creation of hiz and mcs miptreesChad Versace2012-08-072-16/+19
| | | | | | | | | | | | | | Move the logic for creating the ancillary hiz and mcs miptress for winsys and non-texture renderbuffers from intel_alloc_renderbuffer_storage to intel_miptree_create_for_renderbuffer. Let's try to isolate complex miptree logic to intel_mipmap_tree.c. Without this refactor, code duplication would be required along the intel_process_dri2_buffer codepath in order to create the mcs miptree. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Set num samples for winsys renderbuffersChad Versace2012-08-073-11/+21
| | | | | | | | | | | | | | Add a new param, num_samples, to intel_create_renderbuffer and intel_create_private_renderbuffer. No multisample GL config is yet advertised, so the value of num_samples is currently 0. For server-owned winsys buffers, gl_renderbuffer::NumSamples is not yet used. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]> (v1) Signed-off-by: Chad Versace <[email protected]>
* intel: Refactor quantize_num_samplesChad Versace2012-08-072-3/+7
| | | | | | | | | | | Rename quantize_num_samples to intel_quantize_num_samples and change the first param from struct intel_context* to struct intel_screen*. The function will later be used by intelCreateBuffer, which is not bound to any context but is bound to a screen. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]> (v1) Signed-off-by: Chad Versace <[email protected]>
* intel: Update stale comment for intel_miptree_slice::mapChad Versace2012-08-071-2/+2
| | | | | | | The comment referred to intel_tex_image_map/unmap, but should more accurately refer to intel_miptree_map/unmap. Signed-off-by: Chad Versace <[email protected]>
* i965: add more Haswell PCI IDsPaulo Zanoni2012-08-072-4/+98
| | | | | | Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Make ARB_sampler_objects mandatoryPauli Nieminen2012-08-011-1/+0
| | | | | | | | | | | To allow meta acceleration operations to use sampler objects the ARB_sampler_objects extension needs to be mandatory for all drivers. Because the extension doesn't have any hardware dependencies it is trivial to implement. Signed-off-by: Pauli Nieminen <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/msaa: Allow GL_SAMPLES to be set to 1 prior to Gen6.Paul Berry2012-08-011-1/+9
| | | | | | | | | | | | This patch allows GL_SAMPLES to be set to either 0 or 1 on i965 platforms that don't support MSAA (those prior to Gen6). Setting GL_SAMPLES=1 has the same effect as setting it to 0 on these platforms (because MSAA is unsupported), but is distinguishable via the GL API. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50165 Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/msaa: Treat GL_SAMPLES=1 as equivalent to GL_SAMPLES=0.Paul Berry2012-08-011-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EXT_framebuffer_multisample is a required subpart of ARB_framebuffer_object, which means that we must support it even on platforms that don't support MSAA. Fortunately EXT_framebuffer_multisample allows for this by allowing GL_MAX_SAMPLES to be set to 1. This leads to a tricky quirk in the GL spec: since GlRenderbufferStorageMultisamples() accepts any value for its "samples" parameter up to and including GL_MAX_SAMPLES, that means that on platforms that don't support MSAA, GL_SAMPLES is allowed to be set to either 0 or 1. On platforms that do support MSAA, GL_SAMPLES=1 is not used; 0 means no MSAA, and 2 or higher means MSAA. In other words, GL_SAMPLES needs to be interpreted as follows: =0 no MSAA (possible on all platforms) =1 no MSAA (only possible on platforms where MSAA unsupported) >1 MSAA (only possible on platforms where MSAA supported) This patch modifies all MSAA-related code to choose between multisampling and single-sampling based on the condition (GL_SAMPLES > 1) instead of (GL_SAMPLES > 0) so that GL_SAMPLES=1 will be treated as "no MSAA". Note that since GL_SAMPLES=1 implies GL_SAMPLE_BUFFERS=1, we can no longer use GL_SAMPLE_BUFFERS to distinguish between MSAA and non-MSAA rendering. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* intel: Use consistent pattern in intelCreateBufferChad Versace2012-08-011-4/+2
| | | | | | | The 16-bit depth case did not follow the function's prevalent pattern. Reviewed-by: Paul Berry <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Decrease nesting level in intelCreateBufferChad Versace2012-08-011-66/+63
| | | | | | | | | | Nearly the whole function body was contained in the 'else' branch. The 'if' branch did one thing: return early with an error. Clean things up by moving all the code out of the 'else' branch. Decreases max nesting level from 4 to 3. Reviewed-by: Paul Berry <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Remove dead code in intelAllocateBufferChad Versace2012-08-011-85/+7
| | | | | | | | | | | After commit "intel: Convert to using private depth/stencil buffers", we request from DRI2GetBuffersWithFormat only the front left and back left buffers. We no longer request depth and stencil buffers. Assert that in intelAllocateBuffer and remove the related dead code. Reviewed-by: Paul Berry <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: add support for using API_OPENGL_COREJordan Justen2012-07-301-1/+1
| | | | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/msaa: Use MESA_FORMAT_R8 for MCS buffer.Paul Berry2012-07-271-1/+1
| | | | | | | | | | | | No functional change. This patch modifies intel_miptree_alloc_mcs to allocate the 4x MCS buffer using MESA_FORMAT_R8 instead of MESA_FORMAT_A8. In principle it doesn't matter, since we only access the buffer using MCS-specific hardware mechanisms, so all that's important is to use a format with the correct size. However, MESA_FORMAT_A8 has enough unusual behaviours that it seems prudent to avoid it. Acked-by: Kenneth Graunke <[email protected]>
* intel: Make more consistent use of _mesa_is_{user,winsys}_fbo()Paul Berry2012-07-266-8/+12
| | | | | | | | | | A lot of code was still differentiating between between winsys and user fbos by testing the fbo's name against zero. This converts everything in the i915 and 965 drivers over to use _mesa_is_user_fbo() and _mesa_is_winsys_fbo(). Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/msaa: Switch on 8x MSAA for Gen7.Paul Berry2012-07-241-2/+4
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/msaa: Adjust MCS buffer allocation for 8x MSAA.Paul Berry2012-07-241-2/+25
| | | | | | | | MCS buffers use 32 bits per pixel in 8x MSAA, and 8 bits per pixel in 4x MSAA. This patch adjusts the format we use to allocate the buffer so that enough memory is set aside for 8x MSAA. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: move error on create context to proper pathJordan Justen2012-07-241-1/+1
| | | | | | | | | The error was being set on the non-error path, rather than the error path. NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: move some format helper functions to glformats.cBrian Paul2012-07-241-1/+1
|
* i965: Add a driconf option to disable GL_ARB_blend_func_extended.Kenneth Graunke2012-07-192-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unigine Heaven (at least) has a bug where it incorrectly uses the GL_ARB_blend_func_extended extension. Dual source blending allows two color outputs per render target; individual shader outputs can be assigned to be either the first or second blending input by setting the 'index' via one of two methods: - An API call: glBindFragDataLocationIndexed() - The GLSL 'layout' qualifier provided by GL_ARB_explicit_attrib_location Both of these only work on user defined fragment shader outputs; it's an error to use either on built-in outputs like gl_FragData. Unigine uses gl_FragData and gl_FragColor exclusively, and doesn't even attempt to use either method to set index == 1. However, it does set the blending function to SRC1 enums, which requires a fragment shader output with index == 1 or else rendering is undefined. In other words, enabling ARB_blend_func_extended causes Unigine to render incorrectly, resulting in an apparent regression, even though our driver code (as far as I can tell) is perfectly fine. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50291 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: Add a comment explaining why we early return on matching BO names.Eric Anholt2012-07-171-0/+4
| | | | | Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Drop other checks for old loader version.Eric Anholt2012-07-171-38/+26
| | | | | Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Replace the non-getBuffersWithFormat compat path with an error message.Eric Anholt2012-07-172-21/+8
| | | | | | | | | | It's been broken (using NULL getBuffersWithFormat() instead of getBuffers()) due to a copy and paste error for a year now. GetBuffersWithFormat has been around since 2009, so I don't feel any guilt in not supporting it. Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Remove dead intel_framebuffer_has_hiz().Eric Anholt2012-07-172-13/+0
| | | | | Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Convert to using private depth/stencil buffers (v2)Eric Anholt2012-07-173-652/+39
| | | | | | | | | | | | | | | | | This means that GLX buffer sharing of these no longer works. On the other hand, just *look* at this code reduction. v2: - [chad] Fix intelCreateBuffer for gen < 6. When the branch for !screen->hw_has_separate_stencil was taken, intel_create_private_renderbuffer was incorrectly not used. - [chad] Remove all code in intel_process_dri2_buffer for processing depth, stencil, and hiz buffers. That code is now dead. CC: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Add a function for creating a private window system buffer.Eric Anholt2012-07-172-2/+20
| | | | | Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Fix build broken by ETC1 patchChad Versace2012-07-161-0/+12
| | | | | | | I suck at resolving merge conflicts and broke the build in a5a34b1. This patch adds the missing field intel_mipmap_tree::wraps_etc1. Signed-off-by: Chad Versace <[email protected]>
* intel: Enable GL_OES_compressed_ETC1_RGB8_textureChad Versace2012-07-163-1/+73
| | | | | | | | | | | | | | | Enable it for all hardware. No current hardware supports ETC1, so this patch implements it by translating the ETC1 data to RGBX data during the call to glCompressedTexImage2D(). For details, see the doxygen for intel_mipmap_tree::wraps_etc1. Passes the Piglit test spec/OES_compressed_ETC1_RGB8_texture/miptree and the ETC1 test in the GLES2 conformance suite. Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* gbm: Add new gbm_bo_import entry pointKristian Høgsberg2012-07-161-1/+7
| | | | | This generalizes and replaces gbm_bo_create_for_egl_image. gbm_bo_import will create a gbm_bo from either an EGLImage or a struct wl_buffer.
* intel: Don't call _mesa_get_format_bytes for MESA_FORMAT_NONEKristian Høgsberg2012-07-161-1/+4
| | | | | | | | | | When we don't intend to texture from or render to a __DRIimage we use __DRI_IMAGE_FORMAT_NONE. In that case, we just create the __DRIimage to reference the underlying buffer, and will create usable __DRIimages from it using createSubImage later. If we try to use _mesa_get_format_bytes() on MESA_FORMAT_NONE in a debug build, we hit an assertion, so let's not do that.
* i965: Use the blitter in intel_bufferobj_subdata for busy BOs on Gen6+.Kenneth Graunke2012-07-121-16/+10
| | | | | | | | | | Previously we only did this pre-Gen6, and used pwrite on Gen6+. In one workload, this cuts significant amount of overhead. v2: Simplify the function based on Eric's suggestions. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* i965/msaa: Enable CMS layout on Gen7 for the formats that support it.Paul Berry2012-07-111-1/+18
| | | | Reviewed-by: Chad Versace <[email protected]>
* i965/msaa: Allocate MCS buffer when CMS MSAA is in use.Paul Berry2012-07-113-0/+69
| | | | | | | | | | | To implement Gen7's CMS MSAA layout, we need an extra buffer, the MCS (Multisample Control Surface) buffer. This patch introduces code for allocating and deallocating the buffer, and storing a pointer to it in the intel_mipmap_tree struct. No functional change, since the CMS layout is not enabled yet. Reviewed-by: Chad Versace <[email protected]>
* i965/msaa: Add an enum to describe MSAA layout.Paul Berry2012-07-114-42/+78
| | | | | | | | | | | | | | | | | | | | | | | | From the Ivy Bridge PRM, Vol 1 Part 1, p112: There are three types of multisampled surface layouts designated as follows: - IMS Interleaved Multisampled Surface - CMS Compressed Mulitsampled Surface - UMS Uncompressed Multisampled Surface Previously, the i965 driver only used IMS and UMS formats, and distinguished beetween them using the boolean intel_mipmap_tree::msaa_is_interleaved. To facilitate adding support for the CMS format, this patch replaces that boolean (and other booleans derived from it) with an enum INTEL_MSAA_LAYOUT_{IMS,CMS,UMS}. It also updates the terminology used in comments throughout the driver to match the IMS/CMS/UMS terminology used in the PRM. CMS layout is not yet used. The enum has a fourth possible value, INTEL_MSAA_LAYOUT_NONE, which is used for non-multisampled surfaces. Reviewed-by: Chad Versace <[email protected]>
* intel: Implement __DRIimage::createSubImage and bump supported version to 5Kristian Høgsberg2012-07-113-3/+50
| | | | | | | We use the new miptree offset to pick out the sub-image when we bind the EGLImage to a texture. Signed-off-by: Kristian Høgsberg <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-16 16:04:31 +0000