Add the following functions:
intel_renderbuffer_resolve_hiz
intel_renderbuffer_resolve_depth
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
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 <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
This is a map of miptree slices to needed resolves.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
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 <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
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 <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
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 <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
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 <chad.versace@linux.intel.com>
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 <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
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 <chad.versace@linux.intel.com>
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 <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
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 <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
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 <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
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 <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
They're not supported by hw directly, but it's easy to emulate
them with a shader swizzling fixup.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
[danvet: The important thing is to write a 1 to the unused alpha
channel, the ddx is relying on this for render accel.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the gallium driver doesn't support PIPE_FORMAT_R16G16B16A16_SNORM
the call to st_choose_renderbuffer_format() would fail and we'd generate
an GL_OUT_OF_MEMORY error. We'd never get to the subsequent code that
handles software/malloc-based renderbuffers.
Add a special-case check for PIPE_FORMAT_R16G16B16A16_SNORM which is used
for software-based accum buffers. This could be fixed in other ways but
it would be a much larger patch. st_renderbuffer_alloc_storage() could
be reorganized in the future.
This fixes accum buffer allocation for the svga driver.
Note: This is a candidate for the 7.11 branch.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
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 <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
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 <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Essentially, this patch just globally substitutes `irb->region` with
`irb->mt->region` and then does some minor cleanups to avoid segfaults
and other problems.
This is in preparation for
1. Fixing scatter/gather for mipmapped separate stencil textures.
2. Supporting HiZ for mipmapped depth textures.
As a nice benefit, this lays down some preliminary groundwork for easily
texturing from any renderbuffer, even those of the window system.
A future commit will replace intel_mipmap_tree::hiz_region with a miptree.
v2:
- Return early in intel_process_dri2_buffer_*() if region allocation
fails.
- Fix double semicolon.
- Fix miptree reference leaks in the following functions:
intel_process_dri2_buffer_with_separate_stencil()
intel_image_target_renderbuffer_storage()
v3:
- [anholt] Fix check for hiz allocation failure. Replace
``if (!irb->mt)` with ``if(!irb->mt->hiz_region)``.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
This function creates a miptree that is suitable as storage for
a non-texture renderbuffer.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Move the following inline functions:
intel_get_rb_region
intel_framebuffer_has_hiz
A future commit will replace the renderbuffer's region with a miptree.
This small refactor will eliminate the need for intel_fbo.h to include
intel_mipmap_tree.h on that commit. I'd like to avoid the situation where
each header transitively includes every other header.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
The only user of intel_framebuffer_get_hiz_region() was
intel_framebuffer_has_hiz(). So I folded the body of the former into the
latter.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
A great refactor thrashing begins after this commit for HiZ and separate
stencil. Removing code for texture HiZ will make that refactoring easier,
because then we don't have to maintain that code during the refactor.
To disable HiZ for textures, I've removed the hook in
intel_update_wrapper() that allocates a HiZ buffer when attaching a depth
texture to a framebuffer.
HiZ was broken for textures anyway, so there's no regression here.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
The function gathered the stencil buffer into the depth buffer only when
the map mode contained the read bit. But we must do the gather even if the
map mode is write-only. If we do not, then, when the depth buffer's stencil
bits are scattered into the stencil buffer by intel_unmap_renderbuffer(),
some of the scattered stencil bits would be invalid.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
1. Don't map the depthstencil buffer twice
Place a guard in intel_renderbuffer_map() to prevent a renderbuffer
from being mapped twice. This happened if a single buffer was attached to
the framebuffer's depth and stencil attachment points. (Interestingly,
because intel_map_renderbuffer_gtt() is idempotent, the double mapping did
not cause bugs for depthstencil buffers *without* separate stencil).
2. Stop overriding gl_framebuffer::_DepthBuffer,_StencilBuffer
Normally, if a depthstencil buffer is attached to the framebuffer's
depth attachment point, then _mesa_update_framebuffer() installs
a wrapper depth renderbuffer at gl_framebuffer::_DepthBuffer. Ditto for
the stencil attachment point and gl_framebuffer::_StencilBuffer
A depthstencil intel_renderbuffer with separate stencil contains hidden
depth and stencil renderbuffers, which are the *real* renderbuffers. In
order to force swrast to work, we were installing, in
brw_update_draw_buffer(), the hidden renderbuffers at
gl_framebuffer::_DepthBuffer and _StencilBuffer, thus overriding the
behavior of _mesa_update_framebuffer(). However, now that
intel_renderbuffer_map() is implemented with MapRenderbuffer(),
overriding _mesa_update_framebuffer's introduces bugs. This patch
removes the override code.
Fixes several Piglit tests on gen7.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
The special stencil span accessors, as set by intel_span_init_funcs.
perform software W detiling. Since intel_renderbuffer_map() now uses
MapRenderbuffer, rb->Data points to an *untiled* stencil buffer.
Fixes several Piglit tests on gen7.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
It's intended to indicate whether the driver/hardware supports reading
of the values written into shader outputs.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
texture_combine converts the result rgba to CHAN_TYPE from FLOAT. At the
same time, make sure the span->array->ChanType is changed, too.
v2: pick a nicer comment from Brian
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Parameter n and rgbaChan are both from structure span, thus using span
as paramter to simplify the prototype. Function texture_combine is only
used by _swrast_texture_span, so I guess it's safe to do so.
This patch is mainly for the next patch.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
And update r300g.
This is different from util_draw_max_index in how it obtains vertex elements
and that it doesn't have to call util_format_description due to additional
precomputed data in vertex elements.
This forks vbo_get_minmax_index. We need to know the index range when
translating non-native vertices into native ones. There is no other way
around it.
Previously we were mapping/unmapping the index buffer each time we
found the restart index in the buffer. This is bad when the restart
index is frequently used. Now just map the index buffer once, scan
it to produce a list of sub-primitives, unmap the buffer, then draw
the sub-primitives.
Also, clean up the logic of testing for indexed primitives and calling
handle_fallback_primitive_restart(). Don't call it for non-indexed
primitives.
v2: per Jose, only map the relevant part of the index buffer with
pipe_buffer_map_range()
Reviewed-by: José Fonseca <jfonseca@vmware.com>
