summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* mesa: Fix unpack for MESA_FORMAT_INTENSITY_FLOAT16.Eric Anholt2011-11-221-1/+1
| | | | | | Fixes failures in i965 on fbo-blending-formats when the format is enabled. Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Fall back to float16 if float32 isn't supported in ChooseTexFormat.Eric Anholt2011-11-221-0/+11
| | | | | | | Until GL 3.0, there isn't any requirement on the actual sizes of channels chosen. By falling back to 16 here, we can correctly support ARB_texture_float on original i965 hardware, which can't correctly filter 32-bit floats.
* mesa: Add fallback from RGB_FLOAT16 to RGBA_FLOAT16 before RGBA_FLOAT32.Eric Anholt2011-11-221-0/+1
| | | | | | | Not all i965 hardware can do RGB float16, and this will at least save half the memory and have expected behavior in terms of precision. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Reorganize MESA_FORMAT -> BRW_SURFACEFORMAT table.Eric Anholt2011-11-221-48/+146
| | | | | | | | | | | | This should be a no-op change. The initializers are reordered to match the ordering of the enum, since there isn't a clearly sensible ordering, but "the order they were added to the driver, sort of" is definitely not one. Also, the unsupported formats are explicitly initialized to 0, so it's more obvious what we aren't claiming to support. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Mark texture formats as supported using the surface formats table.Eric Anholt2011-11-221-1/+12
| | | | | | | | This is currently duplicated with intel_context.c's setup of the formats table, and sets true for exactly the same set of formats on gen6. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Improve debug output for begin/finish render texture.Eric Anholt2011-11-221-4/+4
| | | | | | | I've never seen a use for the thread ID value, but knowing the format being rendered is kind of a big deal. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Remove duplicate test for texture attachment completeness.Eric Anholt2011-11-221-8/+0
| | | | | | | | | | | We are already testing this if appropriate in intel_validate_framebuffer (FBO completeness), so no need to avoid attaching the texture to the renderbuffer here. This causes MESA_FORMAT_R11_G11_B10_FLOAT to now be renderable as a texture attachment on i965. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Don't require spans (swrast) support to consider a format FBO complete.Eric Anholt2011-11-221-3/+10
| | | | | | | | | | | We don't want to go writing GetRow/PutRow for every format required by GL 3.0, when it's very hard to get those functions called, and in every case we want to make swrast do direct mapping through MapRenderbuffer anyway. This causes MESA_FORMAT_R11_G11_B10_FLOAT to be considered complete on gen6. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Use the surface format table to determine render target supportedness.Eric Anholt2011-11-224-60/+95
| | | | | | | | | | | | | This moves any chipset-dependent logic we want for render target format choices to init time as well. There is still logic left at state update for SRGB handling, where format choices change based on GL state. The brw_render_target_supported() function should now return correct results, instead of relying on the limited results from intel_span_supports_format() to avoid lying about FBO completeness. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Add the context to the render_target_supported() vtbl method.Eric Anholt2011-11-227-8/+10
| | | | | | | We're going to want to provide different answers per chipset generation. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add a table of the surface format information from the PRM.Eric Anholt2011-11-221-0/+204
| | | | | | | | | This will be used to drive chosing formats and determining framebuffer completeness, instead of the bunch of ad-hoc checks we have had until now. Reviewed-by: Kenneth Graunke <[email protected]> Acked-by: Ian Romanick <[email protected]>
* mesa: Make formats.c "datatype" values match glGetTexLevelParameter return.Eric Anholt2011-11-223-9/+14
| | | | | | | | | | | | | | | | | The formats.c code's "datatype" value is "what does this value mean", i.e. unorm or snorm or float, and is the return value from the GL_TEXTURE_RED_TYPE class of queries. The depth formats were marked as GL_UNSIGNED_INT, which is what we use for integer, and not what we should be returning from the glGetTexLevelParameter. In texstore, we were inappropriately using it as an argument to _mesa_unpack_depth_span() that was expecting a value like GL_UNSIGNED_INT or GL_UNSIGNED_SHORT. Just hardcode _mesa_unpack_depth_span()'s arguments for now, though it looks like the consumers of that interface would be happier with using MESA_FORMAT. Reviewed-by: Brian Paul <[email protected]>
* mesa: Don't report types for 0-sized components of textures.Eric Anholt2011-11-221-50/+69
| | | | | | | | | | | | | | | | | | | | The GL_TEXTURE_WHATEVER_SIZE entrypoints were checking if the specified base type of the texture allowed that channel to be present before reporting the size of the channel, so that GL_RGB didn't end up with an alpha size if the hardware driver had to store it that way. The GL_TEXTURE_WHATEVER_TYPE entrypoints weren't checking it, so you would end up with strange responses from the GL involving 0-bit floating-point alpha components in GL_RGB32F, even though it says GL_NONE as expected for other 0-sized channels. Make _TYPE check _BaseFormat the same as _SIZE, which results in fixing most of the GL_RGB* testcases of gl-3.0-required-sized-formats pass on i965. v2: Add a default case with a warning (suggestion by Brian Paul) Reviewed-by: Brian Paul <[email protected]> (v1)
* gallium: separate out floating-point CAPs into its own enumMarek Olšák2011-11-221-6/+11
| | | | | | | | | | | | | | | The motivation behind this is to add some self-documentation in the code about how each CAP can be used. The idea is: - enum pipe_cap is only valid in get_param - enum pipe_capf is only valid in get_paramf Which CAPs are floating-point have been determined based on how everybody except svga implemented the functions. svga have been modified to match all the other drivers. Besides that, the floating-point CAPs are now prefixed with PIPE_CAPF_.
* gallium: remove PIPE_CAP_GLSL and enable GLSL unconditionallyMarek Olšák2011-11-221-17/+12
| | | | | Only i965g does not enable GLSL, but that driver has been unmaintained and bitrotting for quite a while anyway.
* mesa: rename the AMD_conservative_depth extension flag to ARBMarek Olšák2011-11-222-3/+3
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* st/mesa: quick fix of CopyPixels with GL_DEPTH_STENCILMarek Olšák2011-11-221-0/+7
| | | | | | | | This fixes: - depthstencil-default_fb-copypixels - fbo-depthstencil-GL_DEPTH24_STENCIL8-copypixels Reviewed-by: Brian Paul <[email protected]>
* Merge branch 'hiz' of ssh://people.freedesktop.org/~chadversary/mesaChad Versace2011-11-2242-792/+2130
|\
| * i965/gen6: Enable HiZ by defaultChad Versace2011-11-221-6/+2
| | | | | | | | | | | | | | | | | | | | Regresses one Piglit test: bugs/fdo10370. I'm not enabling HiZ for gen7 yet because it causes a mysterious performance regression. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Use separate stencil whenever possibleChad Versace2011-11-222-2/+2
| | | | | | | | | | | | | | | | | | For depthstencil renderbuffers, we were using separate stencil only if the hardware required it. Since the performance gains from HiZ is so high, we should always use separate stencil if the hardware supports it. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * i965: Implement the actual tables for texture alignment units [v2]Kenneth Graunke2011-11-223-13/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I implemented functions for horizontal/vertical alignment units separately because I find it easier to read that way...especially with all the corner-cases. [chad] Corrected the vertical alignment calculation by checking for depthstencil formats. v2: - Fix typos in intel_horizontal_texture_alignment_unit(): s/height/width/ and s/VALIGN/HALIGN. - Remove special case for compressed formats in intel_get_texture_alignment unit(). Compressed formats are already handled in the halign and valign functions. - Replace check ``_mesa_is_depth_format(...) || _mesa_is_depthstencil_format(...)`` with explcitit checks against GL_DEPTH_COMPONENT and GL_DEPTH_STENCIL. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * i965/gen6: Set vertical alignment in SURFACE_STATE batchChad Versace2011-11-222-6/+11
| | | | | | | | | | Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Store miptree alignment units in the miptreeChad Versace2011-11-224-32/+26
| | | | | | | | | | | | | | | | | | This allows us to replace all the calls to intel_get_texture_alignment_unit() with a single call at miptree creation. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Enable HiZ for texture renderbuffersChad Versace2011-11-221-0/+7
| | | | | | | | | | | | | | | | When a depth texture is first attached to framebuffer, allocate a HiZ miptree for it. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Resolve buffers in intel_map_renderbuffer()Chad Versace2011-11-221-0/+5
| | | | | | | | | | Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Resolve buffers in intel_map_texture_image()Chad Versace2011-11-221-0/+5
| | | | | | | | | | Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Mark needed resolves when first enabling HiZ on a miptreeChad Versace2011-11-221-1/+20
| | | | | | | | | | Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * i965: Mark that depth buffer needs depth resolve after drawingChad Versace2011-11-221-0/+23
| | | | | | | | | | | | | | | | | | After brw_try_draw_prims() emits a batch, mark that the depth buffer needs a depth resolve if the buffer was written to and if it has an accompanying HiZ buffer. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Resolve buffers in intelSpanRenderStartChad Versace2011-11-221-1/+39
| | | | | | | | | | | | | | | | | | Resolve all buffers that will be mapped by intelSpanRenderStart. This comprises resolving the depth buffer of each enabled texture and of the read and draw buffers. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Refactor intelSpanRenderStartChad Versace2011-11-221-16/+25
| | | | | | | | | | | | | | | | | | Factor the mapping loops from intelSpanRenderStart() into intel_span_map_buffers(). This in preparation for the next commit, which resolves the buffers before mapping. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * i965: Resolve buffers before drawing [v2]Chad Versace2011-11-221-0/+73
| | | | | | | | | | | | | | | | | | | | | | | | Before emitting primitives in brw_try_draw_prims(), resolve the depth buffer's HiZ buffer and resolve the depth buffer of each enabled depth texture. v2: [anholt] The driver no longer validates drm bo's, so update a comment to reflect that. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * i965: Prevent recursive calls to FLUSH_VERTICES [v2]Chad Versace2011-11-221-0/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | To do so, we must resolve all buffers on entering a glBegin/glEnd block. For the detailed explanation, see the Doxygen comments in this patch. v2: - Fix typo: s/enusure/ensure/. - In brwPrepareExecBegin(), do the same resolves as done by brw_predraw_resolve_buffers(). Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * i965/gen6: Manipulate state batches for HiZ meta-ops [v4]Chad Versace2011-11-228-9/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A lot of the state manipulation is handled by the meta-op state setup. However, some batches need manual intervention. v2: Do not special-case the 3DSTATE_DEPTH_STENCIL.Depth_Test_Enable bit for HiZ in gen6_upload_depth_stencil(). The HiZ meta-op sets ctx->Depth.Test, just read the value from that. v3: Add a new dirty flag, BRW_STATE_HIZ, for brw_tracked_state. Flag it immediately before and after executing the HiZ operation in gen6_resolve_slice(). Add the flag to the the dirty bits for the following state packets: gen6_clip_state gen6_depth_stencil_state gen6_sf_state gen6_wm_state v4: - Add BRW_NEW_STATE_HIZ to the dirty bit table in brw_state_upload.c. This is needed for INTEL_DEBUG=state. - Align brw dirty bit for gen6_depth_stencil_state. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * i965/gen6: Complete stubs for HiZ buffer resolvesChad Versace2011-11-221-2/+298
| | | | | | | | | | | | | | | | Some state batches also need to be manipulated. That's done in the next commit. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * i965: Add HiZ operation state to brw_contextChad Versace2011-11-221-0/+35
| | | | | | | | | | | | | | | | brw_context::hiz contains state needed to perform HiZ meta-ops and indicates if a HiZ operation is currently in progress. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Add resolve functions for renderbuffersChad Versace2011-11-222-0/+94
| | | | | | | | | | | | | | | | | | Add the following functions: intel_renderbuffer_resolve_hiz intel_renderbuffer_resolve_depth Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Add resolve functions for miptreesChad Versace2011-11-222-1/+174
| | | | | | | | | | | | | | | | | | | | Add functions that - set a miptree slice as needing a resolve - resolve a single slice of a miptree - resolve all slices of a miptree Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Add field intel_mipmap_tree::hiz_mapChad Versace2011-11-221-0/+13
| | | | | | | | | | | | | | This is a map of miptree slices to needed resolves. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Define struct intel_resolve_map [v2]Chad Versace2011-11-224-0/+196
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a map of miptree slices to needed resolves, implemented as a linked list. A future commit will embed such a list in intel_mipmap_tree. If you think I'm crazy to put a list in a miptree, read the Doxygen in this patch for intel_resolve_map. v2: [anholt] Move Doxygen from functin prototypes to definitions. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Change signature of HiZ resolve functionsChad Versace2011-11-224-19/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | Now that intel_renderbuffer::region has been replaced with a miptree, the HiZ functions region parameter must be replaced with a miptree parameter. Change the return type from bool to void. Rename the 'depth' parameter to 'layer', because it will correspond to irb->mt_layer. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Remove unused HiZ functionsChad Versace2011-11-223-27/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the following functions: i830_hiz_resolve_noop i915_hiz_resolve_noop brw_hiz_resolve_noop My original strategy for how intel->vtbl.resolve_*buffer was used has substantially changed. The above functions are no longer called in the current strategy. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Replace intel_mipmap_tree::hiz_region with a miptree [v2]Chad Versace2011-11-225-30/+50
| | | | | | | | | | | | | | | | | | | | | | | | This is required to correctly implement HiZ for mipmapped and multi-layered textures. v2: Accomodate refcount fixes in intel_process_dri2_buffer_*() that were introduced in v2 of commit intel: Replace intel_renderbuffer::region with a miptree [v2] Reviewed-by: Eric Anholt <eric@anholt> Signed-off-by: Chad Versace <[email protected]>
| * intel: Replace intel_texture_image::stencil_irb with ↵Chad Versace2011-11-226-236/+252
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | intel_mipmap_tree::stencil_mt [v3] For depthstencil textures using separate stencil, we embedded a stencil buffer in intel_texture_image. The intention was that the embedded stencil buffer would be the golden copy of the texture's stencil bits. When necessary, we scattered/gathered the stencil bits between the texture miptree and the embedded stencil buffer. This approach had a serious deficiency for mipmapped or multi-layer textures. Any given moment the embedded stencil buffer was consistent with exactly one miptree slice, the most recent one to be scattered. This permitted tests of type A to pass, but broke tests of type B. Test A: 1. Create a depthstencil texture. 2. Upload data into (level=x1,layer=y1). 3. Read and test stencil data at (level=x1, layer=y1). 4. Upload data into (level=x2,layer=y2). 5. Read and test stencil data at (level=x2, layer=y2). Test B: 1. Create a depthstencil texture. 2. Upload data into (level=x1,layer=y1). 3. Upload data into (level=x2,layer=y2). 4. Read and test stencil data at (level=x1, layer=y1). 5. Read and test stencil data at (level=x2, layer=y2). v2: Only allocate stencil miptree if intel->must_use_separate_stencil, because we don't make the conversion from must_use_separate_stencil to has_separate_stencil until commit intel: Use separate stencil whenever possible v3: Don't call ChooseNewTexture in intel_renderbuffer_wrap_miptree() in order to determine the renderbuffer format. Instead, pass the format as a param to that function. CC: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Refactor intel_render_texture() [v2]Chad Versace2011-11-221-33/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is in preparation for properly implementing glFramebufferTexture*() for mipmapped depthstencil textures. The FIXME comments deleted by this patch give a rough explanation of what was broken. This refactor does the following: - In intel_update_wrapper() and intel_wrap_texture(), change the parameters to prepare to remove functions' dependency on gl_texture_image. - Move the call to intel_renderbuffer_set_draw_offsets() from intel_render_texture() into intel_udpate_wrapper(). Each time I encounter those functions, I dislike their vague names. (Update which wrapper? What is wrapped? What is the wrapper?). So, while I was mucking around, I also renamed the functions. v2: In addition to the ``GLenum internal_format`` parameter to intel_wrap_miptree(), add a ``gl_format format`` parameter. This removes the need to recalculate for the true format from internal_format with ChooseNewTextureFormat, which was just weird. Signed-off-by: Chad Versace <[email protected]>
| * intel: Define intel_miptree_check_level_layer()Chad Versace2011-11-221-0/+13
| | | | | | | | | | | | | | | | | | This is a small helper function that asserts that a given level and layer are valid for a miptree. I will be extensively using it in the future miptree HiZ functions. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Remove unneeded params from intel_renderbuffer_set_draw_offset()Chad Versace2011-11-223-14/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the renderbuffer tracks the miptree level and layer that it wraps, the 'tex_image' and 'zoffset' params are no longer needed to calculate the draw offsets. Not only are they no longer needed, but their presence would prevent calculating the renderbuffer draw offsets in situations where there were no texture image. Such situations will occur during the HiZ meta-op and during scatter/gather of separate stencil textures. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Track the miptree layer wrapped by a renderbuffer [v2]Chad Versace2011-11-222-5/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TODO: Make v2 for kwg. Add two fields to intel_renderbuffer: mt_level mt_layer Multiple renderbuffers may simultaneously wrap a single texture and each provide a different view into that texture. [Consider glFramebufferTextureLayer()]. The new fields indicate which slice of the miptree is wrapped by the renderbuffer. The buffer resolve operations, to be introduced in the future, require these fields in order to resolve the correct slice in the miptree. To add the fields, it was necessary to replace the type of some function parameters from gl_texture_image to gl_renderbuffer_attachment. v2: [kwg] Replace confusing condition `CubeMapFace > 0` with the more sensible `Target == GL_TEXTURE_CUBE_MAP`. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Kill intel_mipmap_level::nr_images [v4]Chad Versace2011-11-226-43/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For all texture targets except GL_TEXTURE_CUBE_MAP, the 'nr_images' and 'depth' fields of intel_mipmap_level were identical. In the exceptional case, nr_images == 6 and depth == 1. It is simple to determine if a texture is a cube or not, so the presence of two fields here was not helpful. Worse, it was confusing. When we eventually implement GL_ARB_texture_cube_map_array, this mess would have become even more confusing. This patch removes 'nr_images' and assigns to 'depth' a consistent meaning: depth is the number of 2D slices at each miplevel. The exact semantics of depth varies according to the texture target: - For GL_TEXTURE_CUBE_MAP, depth is 6. - For GL_TEXTURE_2D_ARRAY, depth is the number of array slices. It is identical for all miplevels in the texture. - For GL_TEXTURE_3D, it is the texture's depth at each miplevel. Its value, like width and height, varies with miplevel. - For other texture types, depth is 1. As a consequence, parameters were removed from the following function signatures: intel_miptree_set_level_info Remove 'nr_images'. i945_miptree_layout brw_miptree_layout_texture brw_miptree_layout_texture_array Remove 'slices'. v2: - Replace "It's" with "Its". - Remove all hunks in intel_fbo.c. The hunks were spurious and sneaked in during a rebase. - Remove unneeded hunk in intel_tex_map_image_for_swrast(). It was a little refactor of the for-loop's upper bound. v4: In intel_miptree_get_image_offset(), document the conditions under which different if-branches are taken. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Refactor intel_miptree_copy_teximage()Chad Versace2011-11-211-56/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extract the body of the inner loop into a new function, intel_miptree_copy_slice(). This is in preparation for adding support for separate stencil and HiZ to intel_miptree_copy_teximage(). When copying a slice of a depthstencil miptree that uses separate stencil, we will also need to copy the corresponding slice of the stencil miptree. The easiest way to do this will be to call intel_miptree_copy_slice() recursively. Analogous reasoning applies to copying a slice of a depth miptree with HiZ. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
| * intel: Refactor intel_mipmap_level offsetsChad Versace2011-11-212-25/+37
| | | | | | | | | | | | | | | | | | | | | | | | Add a new field, intel_mipmap_level::slice, and move the offset fields into it. Also add some much needed documentation for these fields. Before this patch, a separate array was allocated for the intel_mipmap_level::{x,y}_offsets. This was just silly; it incurred an extra call to malloc and diminished memory locality. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-19 08:28:56 +0000