aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/intel/intel_fbo.c
Commit message (Collapse)AuthorAgeFilesLines
* intel: make intel_texture_image a subclass of swrast_texture_imageBrian Paul2011-09-171-10/+10
| | | | | We need to subclass swrast_texture_image because if we use swrast for fallback rendering, we'll need to have swrast_texture_image objects.
* intel: Silence "warning: unused parameter ‘target’"Ian Romanick2011-09-091-3/+1
| | | | | | | | | The GLenum target parameter was not used in intel_copy_texsubimage, so remove it. Also remove the GLenum internalFormat parameter. Each caller just copied this out of the intel_texture_image that is already passed to intel_copy_texsubimage. Reviewed-by: Eric Anholt <[email protected]>
* intel: Silence "warning: unused parameter ‘fb’"Ian Romanick2011-09-091-3/+3
| | | | | | The gl_framebuffer was not used in intel_draw_buffer, so remove it. Reviewed-by: Eric Anholt <[email protected]>
* intel: add support for __DRI_IMAGE_FORMAT_ABGR8888Chia-I Wu2011-09-091-0/+11
| | | | | | | | | | | It maps to MESA_FORMAT_RGBA8888_REV. Surfaces of the format can only be sampled from but not render to. Only i915 is tested. Reviewed-by: Eric Anholt <[email protected]> [olv: add a check in intel_image_target_renderbuffer_storage]
* intel: use new gl_texture_image:Face, Level fieldsBrian Paul2011-08-241-6/+6
| | | | Reviewed-by: Ian Romanick <[email protected]>
* intel: Fix unused variable warning.Eric Anholt2011-08-021-1/+0
|
* i965: Remove the now unused intel_renderbuffer::draw_offset field.Kenneth Graunke2011-07-281-1/+0
| | | | | | | The previous commit removed the last use of this field. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Check actual tile offsets in Gen4 miptree workaround.Kenneth Graunke2011-07-281-2/+17
| | | | | | | | | | | | | | | | | | | | | | | The purpose of the (irb->draw_offset & 4095) != 0 check was to ensure that we don't have XYy offsets into a tile, since Gen4 hardware doesn't support that. However, it's insufficient: there are cases where draw_offset & 4095 is 0 but we still have a Y-offset. This leads to an assertion failure in brw_update_renderbuffer_surface with tile_y != 0. Instead, simply call intel_renderbuffer_tile_offsets to compute the actual X/Y offsets and check if either are non-zero. This makes both the workaround and the assertion check the same things. Fixes piglit test fbo-generatemipmap-formats, and should also fix bugs #34009 and #39487. NOTE: This is a candidate for stable release branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34009 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39487 Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Chad Versace <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* intel: Fix stencil buffer to be W tiledChad Versace2011-07-191-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, the stencil buffer was allocated as a Y tiled buffer, because in several locations the PRM states that it is. However, it is actually W tiled. From the PRM, 2011 Sandy Bridge, Volume 1, Part 2, Section 4.5.2.1 W-Major Format: W-Major Tile Format is used for separate stencil. The GTT is incapable of W fencing, so we allocate the stencil buffer with I915_TILING_NONE and decode the tile's layout in software. This fix touches the following portions of code: - In intel_allocate_renderbuffer_storage(), allocate the stencil buffer with I915_TILING_NONE. - In intel_verify_dri2_has_hiz(), verify that the stencil buffer is not tiled. - In the stencil buffer's span functions, the tile's layout must be decoded in software. This commit mutually depends on the xf86-video-intel commit dri: Do not tile stencil buffer Author: Chad Versace <[email protected]> Date: Mon Jul 18 00:38:00 2011 -0700 On Gen6 with separate stencil enabled, fixes the following Piglit tests: bugs/fdo23670-drawpix_stencil general/stencil-drawpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-copypixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-drawpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-readpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-copypixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-drawpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-readpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-copypixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-drawpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-readpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-copypixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-drawpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-readpixels spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-copypixels spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-readpixels spec/EXT_packed_depth_stencil/readpixels-24_8 Note: This is a candidate for the 7.11 branch. Signed-off-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* intel: Clarify the depthRb == stencilRb logic.Eric Anholt2011-07-181-16/+15
| | | | Reviewed-by: Chad Versace <[email protected]>
* intel: Remove gratuitous context checks in intel_delete_renderbuffer().Eric Anholt2011-07-071-14/+5
| | | | | | | | | Even if we don't have a current context, if we're freeing the rb we should free its region (and BO). The renderbuffer unreference checks appear to be just cargo-cult from the region unreference code. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30217 Reviewed-by: Chad Versace <[email protected]>
* intel: Remove now trivial intel_renderbuffer_set_{hiz_,}region().Eric Anholt2011-07-071-19/+0
| | | | | | | | | As a result of this cleanup, a bug in intel_process_dri2_buffer_no_separate_stencil() became quite apparent. We were associating the NULL pointer after an unreference with the STENCIL attachment -- clarify the logic and attach the right region. Reviewed-by: Chad Versace <[email protected]>
* intel: Rely on intel_region_reference()'s support of *dst != NULL.Eric Anholt2011-07-071-13/+0
| | | | Reviewed-by: Chad Versace <[email protected]>
* intel: Change framebuffer validation criteriaChad Versace2011-06-241-10/+3
| | | | | | | | Since all infrastructure is now in place to support packed depth/stencil renderbuffers when using separate stencil, there is no need for special cases when separate stencil is enabled. Signed-off-by: Chad Versace <[email protected]>
* intel: In intel_update_wrapper, support s8z24 textures when using separate ↵Chad Versace2011-06-241-6/+35
| | | | | | | | | | stencil Also, in order to coerce intel_update_tex_wrapper_regions() to allocate the hiz region, alter intel_update_tex_wrapper_regions() to examine the renderbuffer format instead of the texture image format. Signed-off-by: Chad Versace <[email protected]>
* intel: Factor region updates out of intel_update_wrapperChad Versace2011-06-241-0/+18
| | | | | | | | | | | ... and into new function intel_update_tex_wrapper_regions. This prevents code duplication in the next commit. Also add a note explaining that the hiz region is broken for mipmapped depth textures. Signed-off-by: Chad Versace <[email protected]>
* intel: Declare some functions in intel_fbo.c as non-staticChad Versace2011-06-241-2/+2
| | | | | | | | | | ... because they will be needed by intel_tex_image_s8z24_create_renderbuffers. Redeclared functions are: intel_alloc_renderbuffer_storage intel_renderbuffer_set_draw_offsets Signed-off-by: Chad Versace <[email protected]>
* intel: Change signature of intel_create_wrapped_renderbufferChad Versace2011-06-241-22/+8
| | | | | | | | | | Redeclare as non-static because intel_tex_image_s8z24_create_renderbuffers will use it. Remove the 'wrapper' parameter, because there is no wrapper for intel_texture_image.depth_rb and stencil_rb. Signed-off-by: Chad Versace <[email protected]>
* intel: Allocate s8_z24 non-texture renderbuffers when using separate stencilChad Versace2011-06-211-3/+81
| | | | | | | | Now all infrastructure is in place to support s8_z24 non-texture renderbuffers for gen7. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Unobfuscate intel_alloc_renderbuffer_storageChad Versace2011-06-211-17/+17
| | | | | | | | | | | Hiz buffer allocation can only occur if the 'else' branch has been taken, so move the hiz buffer allocation into the 'else' branch. Having the hiz buffer allocation dangling outside of the if-tree was just damn confusing. Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Add fields to intel_renderbuffer for unwrapping packed depth/stencil ↵Chad Versace2011-06-211-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | buffers Add the following fields: intel_renderbuffer.wrapped_depth; intel_renderbuffer.wrapped_stencil If the intel_context is using separate stencil and the renderbuffer has a packed depth/stencil format, then wrapped_depth and wrapped_stencil are the real renderbuffers. Alter the following functions to accomodate the wrapped buffers: intel_delete_renderbuffer intel_draw_buffer intel_get_renderbuffer intel_renderbuffer_map intel_renderbuffer_unmap Subsequent commits allocate renderbuffer storage for wrapped_depth and wrapped_stencil. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Drop the cpp argument to intel_miptree_create().Eric Anholt2011-06-141-4/+1
|
* intel: Calculate compress_byte in intel_miptree_create.Eric Anholt2011-06-141-5/+2
| | | | One less argument and thing to get wrong.
* intel: Use the gl_format to get the base_format for miptree create.Eric Anholt2011-06-141-1/+0
| | | | One less argument to this insanely long function call.
* intel: Drop the internal_format field of the mipmap tree.Eric Anholt2011-06-141-1/+0
| | | | This has been replaced with the gl_format now.
* intel: Add the MESA_FORMAT as a field of the miptree.Eric Anholt2011-06-141-0/+1
| | | | | We only had internal_format before, which is way more irritating to work with.
* intel: Clean up intel_render_texture with a rename and a helper function.Eric Anholt2011-06-131-10/+6
| | | | | | | | | | The "newImage" isn't particularly new -- it might be the same texture that was attached to the same attachment point before. This function also gets called when just rebinding back to an FBO with a texture attachment. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* intel: Move the draw_x/draw_y to the renderbuffer where it belongs.Eric Anholt2011-06-131-8/+45
| | | | | | | | | | | | | | | | It was originally located in the region because the tracking of depth/color buffers was on the regions, and getting back to the irb would have been tricky. Now, we're keying off of the renderbuffer in more places, which means we can move these fields where they belong. This could fix potential rendering failure with a single texture having multiple images attached to different renderbuffers across shareCtx (as far as I can tell, this was the only failure we could cause, since anything else should trigger intel_render_texture in between, for example a BindFramebuffer). Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* dri: include swrast.h, not s_texrender.hBrian Paul2011-06-131-1/+1
|
* mesa: move texrender.c to swrastBrian Paul2011-06-131-4/+4
| | | | | | | This stuff is really for software rendering, it's not core Mesa. A small step toward pushing the FetchTexel() stuff down into swrast. Reviewed-by: Eric Anholt <[email protected]>
* intel: Add function intel_renderbuffer_set_hiz_region()Chad Versace2011-06-081-0/+12
| | | | | | | | | | | It's the analog of intel_renderbuffer_set_region(), but for the hiz region of course. CC: Ian Romanick <[email protected]> CC: Kristian Høgsberg <[email protected]> Acked-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Change FBO validation criteria to accomodate hiz and seprate stencilChad Versace2011-05-251-15/+27
| | | | | Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Add hiz_region to intel_mipmap_treeChad Versace2011-05-251-0/+21
| | | | | | | | | | When a texture is attached to multiple FBO's, a separate renderbuffer wrapper is created for each attachment. This necessitates storing the hiz region for these renderbuffers in the texture itself instead of the renderbuffer wrapper. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Refactor the wrapping of textures with renderbuffersChad Versace2011-05-251-7/+8
| | | | | | | | | | | | | Before this commit, the renderbuffer's region was updated in intel_renderbuffer_texture(). This commit moves the update into intel_update_wrapper(), which is a more logical location for updates. This is in preparation for the next commit, which allocates and updates the texture's hiz region in intel_update_wrapper(). Having the two region updates located in the same function makes good form. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Add hiz_region to intel_renderbufferChad Versace2011-05-251-0/+19
| | | | | | | | | | | | | | | | | | | | | | A hiz surface must be supplied to the hardware when rendering to a depth buffer with hiz. There are three potential places to store that surface: 1. Allocate a larger intel_region for the depthbuffer, and let the region's tail be the hiz surface. 2. Allocate a separate intel_region for hiz, and store it as brw_context state. 3. Allocate a separate intel_region for hiz, and store it in intel_renderbuffer. We choose method 3. Method 1 has not been chosen due to future complications it might cause when requesting a DRI drawable's depth buffer attachment from X. Method 2 has not been chosen because storing the hiz region apart from the depth region makes lazy hiz/depth resolves difficult to implement. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Allocate region for separate stencil bufferChad Versace2011-05-251-3/+30
| | | | | | | | | ... in intel_alloc_renderbuffer_storage(). The stencil buffer has quirky pitch requirements, so its region allocation is a special case. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Use _mesa_base_tex_format for FBO texture attachments.Eric Anholt2011-04-181-1/+1
| | | | | | | | | | | | The _mesa_base_fbo_format variant doesn't handle some texture internalformats, such as "3". Fixes: fbo-blending-formats. fbo-alphatest-formats EXT_texture_sRGB/fbo-alphatest-formats Reviewed-by: Brian Paul <[email protected]>
* intel: Try using glCopyTexSubImage2D in _mesa_meta_BlitFramebufferNeil Roberts2011-02-241-1/+80
| | | | | | | | | | | | | | | | In the case where glBlitFramebuffer is being used to copy to a texture without scaling it is faster if we can use the hardware to do a blit rather than having to do a texture render. In most of the drivers glCopyTexSubImage2D will use a blit so this patch makes it check for when glBlitFramebuffer is doing a simple copy and then divert to glCopyTexSubImage2D. This was originally proposed as an extension to the common meta-ops. However, it was rejected as using the BLT is only advantageous for Intel hardware. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33934 Signed-off-by: Chris Wilson <[email protected]>
* intel: use pwrite for batchChris Wilson2011-02-211-1/+1
| | | | | | | | | | | It's faster. Not only is the memcpy more efficiently performed in the kernel (making up for the system call overhead), but by not using mmap we remove the greater overhead of tracking the vma of every batch. And it means we can read back from the batch buffer without incurring the cost of a uncached read through the GTT. Signed-off-by: Chris Wilson <[email protected]>
* i915: Fix compiler warning from sw fallback removal change.Eric Anholt2011-01-141-1/+1
|
* i965: Use a new miptree to avoid software fallbacks due to drawing offset.Eric Anholt2011-01-101-12/+66
| | | | | | | | | When attaching a small mipmap level to an FBO, the original gen4 didn't have the bits to support rendering to it. Instead of falling back, just blit it to a new little miptree just for it, and let it get revalidated into the stack later just like any other new teximage. Bug #30365.
* intel: Include mfeatures.h in files that perform feature tests.Vinson Lee2011-01-091-0/+1
|
* intel: Make renderbuffer tiling choice match texture tiling choice.Eric Anholt2011-01-071-4/+9
| | | | | | There really shouldn't be any difference between the two for us. Fixes a bug where Z16 renderbuffers would be untiled on gen6, likely leading to hangs.
* intel: Use the _BaseFormat from MESA_FORMAT_* in renderbuffer setup.Eric Anholt2011-01-071-36/+1
|
* intel: Add a vtbl hook for determining if a format is renderable.Eric Anholt2011-01-071-1/+3
| | | | | | | By relying on just intel_span_supports_format, some formats that aren't supported pre-gen4 were not reporting FBO incomplete. And we also complained in stderr when it happened on i915 because draw_region gets called before framebuffer completeness validation.
* intel: Merge our choosetexformat fallbacks into core.Eric Anholt2011-01-041-2/+2
| | | | | | We now share the type/format -> MESA_FORMAT_* mappings with software mesa, and the core supports most of the fallbacks hardware drivers will want.
* intel: When validating an FBO's combined depth/stencil, use the given FBO.Eric Anholt2011-01-041-4/+4
| | | | | | | We were looking at the current draw buffer instead to see whether the depth/stencil combination matched. So you'd get told your framebuffer was complete, until you bound it and went to draw and we decided that it was incomplete.
* intel: Fix segfaults from trying to use _ColorDrawBuffers in FBO validation.Eric Anholt2011-01-041-4/+16
| | | | | | | | | | | | | | The _ColorDrawBuffers is a piece of computed state that gets for the current draw/read buffers at _mesa_update_state time. However, this function actually gets used for non-current draw/read buffers when checking if an FBO is complete from the driver's perspective. So, instead of trying to just look at the attachment points that are currently referenced by glDrawBuffers, look at all attachment points to see if they're driver-supported formats. This appears to actually be more in line with the intent of the spec, too. Fixes a segfault in my upcoming fbo-clear-formats piglit test, and hopefully bug #30278
* intel: Check for unsupported texture when finishing using as a render targetChris Wilson2010-12-211-1/+2
| | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32541 Signed-off-by: Chris Wilson <[email protected]>
* intel: Just use ChooseTextureFormat for renderbuffer format choice.Eric Anholt2010-12-101-52/+9
| | | | One less place to forget to put your new MESA_FORMAT support in.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-11 09:29:40 +0000