summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* st/mesa: fix temp texture bindings in st_CopyPixels()Chia-I Wu2013-06-141-17/+13
| | | | | | | | The temporary texture should have either PIPE_BIND_RENDER_TARGET or PIPE_BIND_DEPTH_STENCIL set in addition to PIPE_BIND_SAMPLER_VIEW. Signed-off-by: Chia-I Wu <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* gallium/draw: add limits to the clip and cull distancesZack Rusin2013-06-137-14/+41
| | | | | | | | | | | There are strict limits on those registers. Define the maximums and use them instead of magic numbers. Also allows us to add some extra sanity checks. Suggested by Brian. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* draw: cleanup the distance culling code a bitZack Rusin2013-06-131-48/+41
| | | | | | | | | | | We don't need the clamped variable, because we can just return early. We should also do the regular culling after the distance culling passes. All spotted by Brian. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* ilo: mapping a resource may make some states dirtyChia-I Wu2013-06-134-9/+112
| | | | | | | | | When a resource is busy and is mapped with PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE, the underlying bo is replaced. We need to mark states affected by the resource dirty. With this change, we no longer have to emit vertex buffers and index buffer unconditionally.
* ilo: bump up PIPE_CAP_GLSL_FEATURE_LEVEL to 140Chia-I Wu2013-06-131-1/+1
| | | | With UBO and TBO support, we are supposedly good to claim GLSL 1.40.
* ilo: initialize dirty flags in ilo_init_states()Chia-I Wu2013-06-132-2/+2
| | | | | Now that we have a function to initialize states, initialize dirty flags there too.
* ilo: re-emit states that involve resourcesChia-I Wu2013-06-134-21/+23
| | | | | | | Even with hardware contexts, since we do not pin resources, we have to re-emit the states so that the resources are referenced (by cp->bo) and their offsets are updated in case they are moved. This also allows us to elimiate cp flush in is_bo_busy().
* ilo: fix for util_blitter_clear() changesChia-I Wu2013-06-131-4/+1
| | | | It has been broken since 17350ea979b883662573dac136cd9efb49938210.
* mesa: Fix bug in unclamped float to ubyte conversion.Manfred Ernst2013-06-122-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Problem: The IEEE float optimized version of UNCLAMPED_FLOAT_TO_UBYTE in macros.h computed incorrect results for inputs in the range 0x3f7f0000 (=0.99609375) to 0x3f7f7f80 (=0.99803924560546875) inclusive. 0x3f7f7f80 is the IEEE float value that results in 254.5 when multiplied by 255. With rounding mode "round to closest even integer", this is the largest float in the range 0.0-1.0 that is converted to 254 by the generic implementation of UNCLAMPED_FLOAT_TO_UBYTE. The IEEE float optimized version incorrectly defined the cut-off for mapping to 255 as 0x3f7f0000 (=255.0/256.0). The same bug was present in the function float_to_ubyte in u_math.h. Fix: The proposed fix replaces the incorrect cut-off value by 0x3f800000, which is the IEEE float representation of 1.0f. 0x3f7f7f81 (or any value in between) would also work, but 1.0f is probably cleaner. The patch does not regress piglit on llvmpipe and on i965 on sandy bridge. Tested-by Stéphane Marchesin <[email protected]> Reviewed-by Stéphane Marchesin <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* st/dri: if flushing a drawable, don't set reason=SWAPBUFFERSMarek Olšák2013-06-131-1/+1
| | | | | | 0 means SWAPBUFFERS. Reviewed-by: Brian Paul <[email protected]>
* st/dri: resolve the back buffer only in SwapBuffersMarek Olšák2013-06-131-3/+3
| | | | Reviewed-by: Brian Paul <[email protected]>
* st/dri: manually swap MSAA front and back buffers in SwapBuffersMarek Olšák2013-06-131-0/+25
| | | | Reviewed-by: Brian Paul <[email protected]>
* st/dri: always copy new DRI front and back buffers to corresponding MSAA buffersMarek Olšák2013-06-131-0/+27
| | | | | | | | This commit fixes these piglit tests with an MSAA visual forced on: - read-front - glx-copy-sub-buffer Reviewed-by: Brian Paul <[email protected]>
* st/dri: refactor dri_msaa_resolveMarek Olšák2013-06-133-12/+15
| | | | | | The generic blit will be used by the following commit. Reviewed-by: Brian Paul <[email protected]>
* st/dri: reuse depth-stencil and MSAA resources after DRI2 invalidate eventMarek Olšák2013-06-131-26/+78
| | | | | | | | | | Page flipping generates an invalidate event every frame, causing reallocations of all private resources (MSAA and depth-stencil). Reusing the resources may improve performance (especially under memory pressure). Reviewed-by: Brian Paul <[email protected]>
* st/dri: fix MSAA resolving of buffers with height > widthMarek Olšák2013-06-131-2/+2
| | | | Reviewed-by: Brian Paul <[email protected]>
* st/mesa: make generic CopyPixels path work with MSAA visualsMarek Olšák2013-06-131-92/+70
| | | | | | | | | | | | | | We have to use pipe->blit, not resource_copy_region, so that the read buffer is resolved if it's multisampled. I also removed the CPU-based copying, which just did format conversion (obsoleted by the blit). Also, the layer/slice/face of the read buffer is taken into account (this was ignored). Last but not least, the format choosing is improved to take float and integer read buffers into account. Reviewed-by: Brian Paul <[email protected]>
* st/mesa: don't use blit_copy_pixels if an occlusion query is activeMarek Olšák2013-06-131-1/+2
| | | | | | | CopyPixels, just as DrawPixels, should count the samples that passed depth test. Reviewed-by: Brian Paul <[email protected]>
* st/mesa: rework blit_copy_pixels to use pipe->blitMarek Olšák2013-06-131-35/+79
| | | | | | | | | | | | | | | There were 2 issues with it: - resource_copy_region doesn't allow different sample counts of both src and dst, which can occur if we blit between a window and a FBO, and the window has an MSAA colorbuffer and the FBO doesn't. (this was the main motivation for using pipe->blit) - blitting from or to a non-zero layer/slice/face was broken, because rtt_face and rtt_slice were ignored. blit_copy_pixels is now used even if the formats and orientation of framebuffers don't match. Reviewed-by: Brian Paul <[email protected]>
* r600g: upsample and downsample MSAA resources for transfersMarek Olšák2013-06-131-79/+141
| | | | | | | | | | | We did downsample (=resolve) MSAA resources to make ReadPixels work with MSAA GLX visuals, which was enough for read-only color-only transfers. This commit makes write color transfers and depth-stencil transfers work in a similar manner. It does downsampling in transfer_map and upsampling in transfer_unmap. Reviewed-by: Brian Paul <[email protected]>
* gallium/u_format: add a new helper for initializing pipe_blit_info::maskMarek Olšák2013-06-132-25/+29
| | | | Reviewed-by: Brian Paul <[email protected]>
* gallium/u_blitter: make clearing independent of the colorbuffer formatMarek Olšák2013-06-135-49/+7
| | | | | | | There isn't any difference between 32_FLOAT and 32_*INT in vertex fetching. Both of them don't do any format conversion. Reviewed-by: Brian Paul <[email protected]>
* gallium/u_blitter: make clearing independent of the number of bound colorbuffersMarek Olšák2013-06-137-59/+43
| | | | | | We can use the fragment shader TGSI property WRITES_ALL_CBUFS. Reviewed-by: Brian Paul <[email protected]>
* gallium/util: make WRITES_ALL_CBUFS optional in the passthrough fragment shaderMarek Olšák2013-06-137-9/+17
| | | | Reviewed-by: Brian Paul <[email protected]>
* mesa: fix OES_EGL_image_external being partially allowed in the core profileMarek Olšák2013-06-135-13/+15
| | | | Reviewed-by: Chad Versace <[email protected]>
* glsl: Generate smaller values for uniform locationsIan Romanick2013-06-121-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we would generate uniform locations as (slot << 16) + array_index. We do this to handle applications that assume the location of a[2] will be +1 from the location of a[1]. This resulted in every uniform location being at least 0x10000. The OpenGL 4.3 spec was amended to require this behavior, but previous versions did not require locations of array (or structure) members be sequential. We've now encountered two applications that assume uniform values will be "small." As far as we can tell, these applications store the GLint returned by glGetUniformLocation in a int16_t or possibly an int8_t. THIS BEHAVIOR IS NOT GUARANTEED OR IMPLIED BY ANY VERSION OF OpenGL. Other implementations happen to have both these behaviors (sequential array elements and small values) since OpenGL 2.0, so let's just match their behavior. Fixes "3D Bowling" on Android. NOTE: This is a candidate for stable release branches. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-and-tested-by: Chad Versace <[email protected]>
* glsl: Add gl_shader_program::UniformLocationBaseScaleIan Romanick2013-06-124-3/+23
| | | | | | | | | | | | | | | | This is used by _mesa_uniform_merge_location_offset and _mesa_uniform_split_location_offset to determine how the base and offset are packed. Previously, this value was hard coded as (1U<<16) in those functions via the shift and mask contained therein. The value is still (1U<<16), but it can be changed in the future. The next patch dynamically generates this value. NOTE: This is a candidate for stable release branches. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-and-tested-by: Chad Versace <[email protected]>
* glsl: Add a gl_shader_program parameter to ↵Ian Romanick2013-06-124-5/+7
| | | | | | | | | | | | _mesa_uniform_{merge,split}_location_offset This will be used in the next commit. NOTE: This is a candidate for stable release branches. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-and-tested-by: Chad Versace <[email protected]>
* util: new util_fill_box helperRoland Scheidegger2013-06-133-39/+62
| | | | | | | | | Use new util_fill_box helper for util_clear_render_target. (Also fix off-by-one map error.) v2: handle non-zero z correctly in new helper Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: (trivial) remove duplicated code block (including comment)Roland Scheidegger2013-06-131-7/+0
|
* i965/gen7: Enable support for fast color clears.Paul Berry2013-06-121-0/+20
| | | | | | | | | | | This patch adds code to place mcs_state into INTEL_MCS_STATE_RESOLVED for miptrees that are capable of supporting fast color clears. This will have no effect on buffers that don't undergo a fast color clear; however, for buffers that do undergo a fast color clear, an MCS miptree will be allocated (at the time of the first fast clear), and will be used thereafter. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Disable fast color clears on shared regions.Paul Berry2013-06-124-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | 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+: Resolve color buffers when necessary.Paul Berry2013-06-127-3/+37
| | | | | | | | | | | | | | | | Resolve color buffers that have been fast-color cleared: 1. before texturing from the buffer (brw_predraw_resolve_buffers()) 2. before using the buffer as the source in a blorp blit (brw_blorp_blit_miptrees()) 3. before mapping the buffer's miptree (intel_miptree_map_raw(), intel_texsubimage_tiled_memcpy()) 4. before accessing the buffer using the hardware blitter (intel_miptree_blit(), do_blit_bitmap()) 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-123-12/+15
| | | | | | | | | | | | 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/blorp: Write blorp code to do render target resolves.Paul Berry2013-06-126-0/+96
| | | | | | | | | | | | | | | | | | | This patch implements the "render target resolve" blorp operation. This will be needed when a buffer that has experienced a fast color clear is later used for a purpose other than as a render target (texturing, glReadPixels, or swapped to the screen). It resolves any remaining deferred clear operation that was not taken care of during normal rendering. Fortunately not much work is necessary; all we need to do is scale down the size of the rectangle primitive being emitted, run the fragment shader with the "Render Target Resolve Enable" bit set, and ensure that the fragment shader writes to the render target using the "replicated color" message. We already have a fragment shader that does that (the shader that we use for fast color clears), so for simplicity we re-use it. Reviewed-by: Eric Anholt <[email protected]>
* i965/blorp: Expand clear class hierarchy to prepare for RT resolves.Paul Berry2013-06-122-25/+35
| | | | | | | | | | | | | | The fragment shaders that to do color clears will be re-used to perform so-called "render target resolves" (the resolves associated with fast color clears). To prepare for that, this patch expands the class hierarchy for blorp params by adding brw_blorp_const_color_params (which will be used for all blorp operations where the fragment shader outputs a constant color). Some other data structures and functions were also renamed to use "const_color" nomenclature where appropriate. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Implement fast color clear operation in BLORP.Paul Berry2013-06-129-14/+240
| | | | | | | | | | | | | | | | | | Since we defer allocation of the MCS miptree until the time of the fast clear operation, this patch also implements creation of the MCS miptree. In addition, this patch adds the field intel_mipmap_tree::fast_clear_color_value, which holds the most recent fast color clear value, if any. We use it to set the SURFACE_STATE's clear color for render targets. v2: Flag BRW_NEW_SURFACES when allocating the MCS miptree. Generate a perf_debug message if clearing to a color that isn't compatible with fast color clear. Fix "control reaches end of non-void function" build warning. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Create helper functions for single-sample MCS buffers.Paul Berry2013-06-122-0/+128
| | | | Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Set up MCS in SURFACE_STATE whenever MCS is present.Paul Berry2013-06-123-5/+7
| | | | | | | | | | | | | | | On Gen7+, MCS buffers are used both for compressed multisampled color buffers and for "fast clear" of single-sampled color buffers. Previous to this patch series, we didn't support fast clear, so we only used MCS with multisampled bolor buffers. As a first step to implementing fast clears, this patch modifies the code that sets up SURFACE_STATE so that it configures the MCS buffer whenever it is present, regardless of whether we are multisampling or not. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Create an enum for keeping track of fast color clear state.Paul Berry2013-06-126-0/+104
| | | | | | | | | | | | | This patch includes code to update the fast color clear state appropriately when rendering occurs. The state will also need to be updated when a fast clear or a resolve operation is performed; those state updates will be added when the fast clear and resolve operations are added. v2: Create a new function, intel_miptree_used_for_rendering() to handle updating the fast color clear state when rendering occurs. Reviewed-by: Eric Anholt <[email protected]>
* intel: Conditionally compile mcs-related code for i965 only.Paul Berry2013-06-122-1/+9
| | | | | | | | | This patch ifdefs out intel_mipmap_tree::mcs_mt when building the i915 (pre-Gen4) driver (MCS buffers aren't supported until Gen7, so there is no need for this field in the i915 driver). This should make it a bit easier to implement fast color clears without undue risk to i915. Reviewed-by: Eric Anholt <[email protected]>
* intel: Keep region name in intel_miptree_create_for_dri2_buffer().Paul Berry2013-06-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | When processing a buffer received from the X server, intel_process_dri2_buffer() examines intel_region::name to determine whether it's received a brand new buffer, or the same buffer it received from the X server the last time it made a request. However, this didn't work properly, because in the call to intel_miptree_create_for_dri2_buffer(), we create a fresh intel_region object to represent the buffer, and this was causing us to forget the buffer's previous name. This patch fixes things by copying over the region name when creating the fresh intel_region object. At the moment, this is just a minor performance optimization. However, when fast color clears are added, it will be necessary to ensure that the fast color clear state for a buffer doesn't get discarded the next time we receive that buffer from the X server. Reviewed-by: Eric Anholt <[email protected]>
* winsys/intel: make struct intel_bo alias drm_intel_boChia-I Wu2013-06-121-122/+50
| | | | | | | | There is really nothing in struct intel_bo, and having it alias drm_intel_bo makes the winsys impose almost zero overhead. We can make the overhead gone completely by making the functions static inline, if needed.
* winsys/intel: reorganize functionsChia-I Wu2013-06-121-249/+249
| | | | Move functions around to match the order of the declarations in the header.
* ilo: update winsys interfaceChia-I Wu2013-06-123-63/+66
| | | | | | The motivation is to kill tiling and pitch in struct intel_bo. That requires us to make tiling and pitch not queryable, and be passed around as function parameters.
* ilo: get rid of function tables in winsysChia-I Wu2013-06-1220-656/+557
| | | | | We are moving toward making struct intel_bo alias drm_intel_bo. As a first step, we cannot have function tables.
* ilo: access bo size directlyChia-I Wu2013-06-121-2/+2
| | | | buf->bo_size is readily avaiable, no need to go via buf->bo->get_size().
* ilo: remove unnecessary tex_set_bo/buf_set_boChia-I Wu2013-06-121-42/+18
| | | | Merge the bodies to tex_create_bo/buf_create_bo respectively.
* i965: Emit the depth/stencil state pointer directly, not via atoms.Kenneth Graunke2013-06-117-80/+18
| | | | | | | | | | | | | | | | | | | | | See two commits ago for the rationale. This allows us to delete the whole gen7_cc_state.c file. This does move these commands before the depth stall flushes from brw_emit_depthbuffer, which may be a problem. The documentation for 3DSTATE_DEPTH_BUFFER mentions that depth stall flushes are required before changing any depth/stencil buffer state, but explicitly lists 3DSTATE_DEPTH_BUFFER, 3DSTATE_HIER_DEPTH_BUFFER, 3DSTATE_STENCIL_BUFFER, and 3DSTATE_CLEAR_PARAMS. It does not mention this particular packet (_3DSTATE_DEPTH_STENCIL_STATE_POINTERS). No observed Piglit regressions on Sandybridge or Ivybridge. Together with the last two commits, this makes a cairo-gl benchmark faster by 0.324552% +/- 0.258355% on Ivybridge. No statistically significant change on Sandybridge. (Thanks to Eric for the numbers.) Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Emit the CC state pointer directly rather than via atoms.Kenneth Graunke2013-06-115-30/+18
| | | | | | See the previous commit for the rationale. Signed-off-by: Kenneth Graunke <[email protected]>