http://permalink.gmane.org/gmane.comp.video.mesa3d.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58211 <pre> All the entities that produce instances of 'struct __DRIimageRec' make certain that 'regions' contain as many valid pointers as there are planes. Hence the controlling counter is 'planar_format.nplanes'. I originally thought adding a counter along with 'regions', say 'nregions', but then decided against as it would be duplicating 'planar_format.nplanes' - they would always agree anyway. If 'planar_format' itself is missing (zero pointer) the image is implicitly always packed having only one region. In this patch I have simply extended the number of pointers, but no logic is yet trying to access elements of 'regions' beyond the first. The following patches introduce planar cases where other elements are accessed the 'planar_format' controlling how many. In addition, patch number six takes advantage of the fact that all the unused region pointers in the array are fixed to zero (for now all instances of 'struct __DRIimageRec' are allocated from the heap and all members are initialised to zero). It is also t</pre> Pohjolainen, Topi 2013-05-22T06:17:00 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58210 <pre> ----- Original Message ----- This is still slightly different than what I expected: gallium was using the convention the components started with least significant bit appear first in name (same as D3D10). That is, RGBA8888 is a 32-bit int with R in the _low_ 8 bits and A in the _high_ 8 bits. I understand that Mesa formats follow the opposite convention, but between consistency with Mesa vs consistency within gallium I believe that it is better for gallium formats to be consistent among themselves: it is much easier to remember that _all_ gallium formats go from least-&gt;most significant bit/byte/word, than to remember which formats are supposed to go from the low-&gt;high vs high-&gt;low, which would end up forcing developers to either guess wrongly or waste time look up the format implementation. Otherwise looks good. I went through the implementation in more detail and it looks AFAICT. As Adam mentioned on the cover email, the series must be squashed when commited, such way that each commit builds and wor</pre> Jose Fonseca 2013-05-22T06:15:51 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58209 <pre>Sounds definitely an improvement. Long term I think the cache is probably not worth to keep any texture cache at all. Jose ----- Original Message ----- </pre> Jose Fonseca 2013-05-22T05:38:30 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58208 <pre> [snip] In case (1), does image-&gt;regions contain a single image, or does it contain 3 pointers to the same image? More importantly, I don't understand a key point here. By examining a given instance of __DRIimageRec, how can I determine if the image falls under case (1) or case (2)? Here is a concrete instance of the problem I don't know how to solve. Suppose that I have an instance of __DRIimageRec and that I've determined so far that its contents are as below, where image-&gt;planar_format was obtained by a lookup in the intel_screen.c:intel_image_formats table. image = { // ... .planar_format = { .fourcc = __DRI_IMAGE_FOURCC_YUV422, .components = __DRI_IMAGE_COMPONENTS_Y_U_V, .nplanes = 3, . planes = { [0] = { .buffer_index = 0, .dri_format = __DRI_IMAGE_FORMAT_R8, // ... }, [1] = { .buffer_index = 1, .dri_format = __DRI_IMAGE_FORMAT_R8, // ... </pre> Chad Versace 2013-05-22T05:11:17 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58207 <pre>Rather than pointing the surface_state directly at a single sub-image of the texture for rendering, we now point the surface_state at the top level of the texture, and configure the surface_state as needed based on this. Signed-off-by: Jordan Justen &lt;jordan.l.justen&lt; at &gt;intel.com&gt; --- src/mesa/drivers/dri/i965/brw_defines.h | 2 + src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 62 +++++++++++++++------ 2 files changed, 46 insertions(+), 18 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_defines.h b/src/mesa/drivers/dri/i965/brw_defines.h index fedd78c..d61151f 100644 --- a/src/mesa/drivers/dri/i965/brw_defines.h +++ b/src/mesa/drivers/dri/i965/brw_defines.h &lt; at &gt;&lt; at &gt; -539,6 +539,8 &lt; at &gt;&lt; at &gt; #define GEN7_SURFACE_MULTISAMPLECOUNT_8 (3 &lt;&lt; 3) #define GEN7_SURFACE_MSFMT_MSS (0 &lt;&lt; 6) #define GEN7_SURFACE_MSFMT_DEPTH_STENCIL (1 &lt;&lt; 6) +#define GEN7_SURFACE_MIN_ARRAY_ELEMENT_SHIFT18 +#define GEN7_SURFACE_RENDER_TARGET_VIEW_EXTENT_SHIFT7 /* Surface state DW5 */ #de</pre> Jordan Justen 2013-05-22T04:53:52 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58206 <pre>OK, I'll add the spec quote and fixup the two piglits which are asserting the old behavior, and push it all tonight. </pre> Chris Forbes 2013-05-22T02:27:16 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58205 <pre>From: Roland Scheidegger &lt;sroland&lt; at &gt;vmware.com&gt; Initially we had NUM_TEX_TILE_ENTRIES of 50, however this was using too much memory (mostly because the tile cache is operating on fixed max current sampler views which could be fixed but that's another topic). So it was decreased to 4. However this is a ridiculously low number which can't actually really work (the number of tiles needed for as little as a single quad with linear_mipmap_linear is 2 to 8 for a 2d texture, and 4 to 16 for a 3d texture), as it just about guarantees there will be cache thrashing sometimes (just about always for 3d textures in fact, since while there are 4 entries the cache is direct mapped). So increase that number to 16 (which is still on the low side for direct mapped cache though I guess using something like 4-way associativity would be more effective than increasing this further) which has at least some good chance to avoid thrashing. Since we don't want to increase memory requirements however in turn decrease the tile size acco</pre> sroland< at >vmware.com 2013-05-22T01:15:11 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58204 <pre>From: Roland Scheidegger &lt;sroland&lt; at &gt;vmware.com&gt; These can be different (just like NUM_TEX_TILE_ENTRIES / NUM_ENTRIES), though currently they aren't. --- src/gallium/drivers/softpipe/sp_tex_sample.c | 28 +++++++++++----------- src/gallium/drivers/softpipe/sp_tex_tile_cache.c | 28 +++++++++++----------- src/gallium/drivers/softpipe/sp_tex_tile_cache.h | 20 ++++++++-------- 3 files changed, 38 insertions(+), 38 deletions(-) diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c b/src/gallium/drivers/softpipe/sp_tex_sample.c index 1550199..2c7f17f 100644 --- a/src/gallium/drivers/softpipe/sp_tex_sample.c +++ b/src/gallium/drivers/softpipe/sp_tex_sample.c &lt; at &gt;&lt; at &gt; -580,10 +580,10 &lt; at &gt;&lt; at &gt; get_texel_2d_no_border(const struct sp_sampler_view *sp_sview, union tex_tile_address addr, int x, int y) { const struct softpipe_tex_cached_tile *tile; - addr.bits.x = x / TILE_SIZE; - addr.bits.y = y / TILE_SIZE; - y %= TILE_SIZE; - x %= TILE_SIZE; + addr.bits.x = x / TEX_TILE_SIZE; </pre> sroland< at >vmware.com 2013-05-22T01:15:10 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58203 <pre>We were expanding the live range too far, breaking register_coalesce_2() and compute_to_mrf() on 16-wide shaders. Turning it back on improves GLB2.7 performance by 0.239355% +/- 0.0850649% (n=398), though some 16-wide shaders are lost. shader-db stats are: total instructions in shared programs: 1627211 -&gt; 1609262 (-1.10%) instructions in affected programs: 450351 -&gt; 432402 (-3.99%) While 33 new 16-wide shaders are gained, 70 are lost. --- src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp b/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp index 3daf8fa..f5daab2 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp &lt; at &gt;&lt; at &gt; -216,7 +216,7 &lt; at &gt;&lt; at &gt; fs_visitor::calculate_live_intervals() * pixel_x/pixel_y, which are registers of 16-bit values and thus * would get stomped by the first decode as well</pre> Eric Anholt 2013-05-22T01:11:32 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58202 <pre>The scheduler didn't know about uniform-type accesses, and if a uniform access was last in a 16-wide, we'd walk off the end of the array. This never happened, because we'd never coalesce out all the GRFs, due to a bug to be fixed in the next commit. --- src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp index 6a52754..ccedee3 100644 --- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp +++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp &lt; at &gt;&lt; at &gt; -579,7 +579,10 &lt; at &gt;&lt; at &gt; fs_instruction_scheduler::calculate_deps() (inst-&gt;src[i].fixed_hw_reg.file == BRW_GENERAL_REGISTER_FILE)) { if (post_reg_alloc) { - for (int r = 0; r &lt; reg_width; r++) + int size = reg_width; + if (inst-&gt;src[i].fixed_hw_reg.vstride == BRW_VERTICAL_STRIDE_0) + siz</pre> Eric Anholt 2013-05-22T01:11:31 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58201 <pre>--- src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp index b7bbaab..36d9cf0 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp &lt; at &gt;&lt; at &gt; -493,6 +493,14 &lt; at &gt;&lt; at &gt; fs_visitor::visit(ir_expression *ir) assert(!"not reached: should be handled by lower_quadop_vector"); break; + case ir_binop_vector_extract: + assert(!"not reached: should be handled by lower_vec_index_to_cond_assign()"); + break; + + case ir_triop_vector_insert: + assert(!"not reached: should be handled by lower_vector_insert()"); + break; + case ir_unop_sqrt: emit_math(SHADER_OPCODE_SQRT, this-&gt;result, op[0]); break; </pre> Eric Anholt 2013-05-22T01:11:28 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58200 <pre>i965 and radeon use ra_set_node_reg() to force payload registers to specific registers while exposing those registers to the allocator still. We were treating those register nodes as unsuccessfully allocated in the ra_simplify() step, leading to walking the registers again to do optimistic coloring even if there was nothing left ot do. --- src/mesa/program/register_allocate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/program/register_allocate.c b/src/mesa/program/register_allocate.c index b8472a2..16739fd 100644 --- a/src/mesa/program/register_allocate.c +++ b/src/mesa/program/register_allocate.c &lt; at &gt;&lt; at &gt; -437,7 +437,7 &lt; at &gt;&lt; at &gt; ra_simplify(struct ra_graph *g) } for (i = 0; i &lt; g-&gt;count; i++) { - if (!g-&gt;nodes[i].in_stack) + if (!g-&gt;nodes[i].in_stack &amp;&amp; g-&gt;nodes[i].reg == -1) return GL_FALSE; } </pre> Eric Anholt 2013-05-22T01:11:30 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58199 <pre>Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59440 --- src/mesa/drivers/dri/intel/intel_pixel_bitmap.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c index 954dfc5..c538a29 100644 --- a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c +++ b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c &lt; at &gt;&lt; at &gt; -259,14 +259,15 &lt; at &gt;&lt; at &gt; do_blit_bitmap( struct gl_context *ctx, * Have to translate destination coordinates back into source * coordinates. */ - if (get_bitmap_rect(bitmap_width, bitmap_height, unpack, - bitmap, - -orig_dstx + (dstx + px), - -orig_dsty + y_flip(fb, dsty + py, h), - w, h, - (GLubyte *)stipple, - 8, - _mesa_is_winsys_fbo(fb)) == 0) + int count = get_bitmap_rect(bitmap_width, bitmap_height, unpack, + bitmap, + -orig_dstx + (d</pre> Eric Anholt 2013-05-22T01:11:29 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58198 <pre> Forgot to mention: this series is avaiable on branch "fast-color-clear-2" of git://github.com/stereotype441/mesa.git. _______________________________________________ mesa-dev mailing list mesa-dev&lt; at &gt;lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev </pre> Paul Berry 2013-05-21T23:54:07 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58197 <pre>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. --- src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/mesa/dri</pre> Paul Berry 2013-05-21T23:52:15 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58196 <pre>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. --- src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c index 7a3c135..5b9771f 100644 --- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c +++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c &lt; at &gt;&lt; at &gt; -602,6 +602,16 &lt; at &gt;&lt; at &gt; intel_miptree_create(struct intel_context *intel, return NULL; } +#ifndef I915 + /* If this miptree is capable of supporting fast color clears, set + * mcs_state appropriately to ensure that fast clears will occur. + * Allocation of the MCS miptree will b</pre> Paul Berry 2013-05-21T23:52:16 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58195 <pre>Resolve color buffers that have been fast-color cleared: 1. before texturing from the buffer 2. before using the buffer as the source in a blorp blit 3. before mapping the buffer's miptree 4. before accessing the buffer using the hardware blitter Cases 1 and 2 happen in the functions brw_predraw_resolve_buffers() and brw_blorp_blit_miptrees(), respectively. Cases 3 and 4 are handled by the intel_miptree_get_region() function. In order to make sure that intel_miptree_get_region() doesn't try to resolve a buffer during emission of state commands, this patch also adds a new boolean, brw-&gt;state_emission_in_progress, which is set to true during brw_upload_state() and brw_blorp_exec(). --- src/mesa/drivers/dri/i965/brw_blorp.cpp | 3 +++ src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 7 +++++++ src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 8 ++++++++ src/mesa/drivers/dri/i965/brw_context.h | 2 ++ src/mesa/drivers/dri/i965/brw_draw.c | 6 +++++- src/mesa/drivers/dr</pre> Paul Berry 2013-05-21T23:52:14 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58194 <pre>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(). --- src/mesa/drivers/dri/intel/intel_context.c | 21 ++++++++++++--------- src/mesa/drivers/dri/intel/intel_context.h | 4 ++-- src/mesa/drivers/dri/intel/intel_screen.c | 2 +- 3 files changed, 15 insertions(+), 12 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index fab99c1..eaaf4ec 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c &lt; at &gt;&lt; at &gt; -249,12 +249,12 &lt; at &gt;&lt; at &gt; intelGetString(struct gl_context * ctx, GLenum name) } void -intel_downsample_for_dri2_flush(struct intel_context *intel, - __DRIdrawable *drawable) +intel_resolve_for_dri2_flus</pre> Paul Berry 2013-05-21T23:52:13 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58193 <pre>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. --- src/mesa/drivers/dri/i965/brw_blorp.h | 5 +++ src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 60 ++++++++++++++++++++++++++ src/mesa/drivers/dri/i965/brw_defines.h | 1 + src/mesa/drivers/dri/i965/gen7_blorp.cpp </pre> Paul Berry 2013-05-21T23:52:12 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58192 <pre>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. --- src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 58 ++++++++++++++++----------- src/mesa/drivers/dri/i965/brw_context.h | 2 +- 2 files changed, 35 insertions(+), 25 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp index 675289b..4ced318 100644 --- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp +++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp &lt; at &gt;&lt; at &gt; -37,13 +37,28 &lt; at &gt;&lt; at &gt; extern "C" { #include "brw_eu.h" #include "brw_state.h" -struct brw_blorp_clear_p</pre> Paul Berry 2013-05-21T23:52:11 http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/58191 <pre>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. --- src/mesa/drivers/dri/i965/brw_blorp.cpp | 1 + src/mesa/drivers/dri/i965/brw_blorp.h | 11 +- src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 143 +++++++++++++++++++++- src/mesa/drivers/dri/i965/brw_clear.c | 2 +- src/mesa/drivers/dri/i965/brw_defines.h | 2 + src/mesa/drivers/dri/i965/gen7_blorp.cpp | 18 ++- src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 10 +- src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 47 +++++++ src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 13 ++ 9 files changed, 233 insertions(+), 14 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_b</pre> Paul Berry 2013-05-21T23:52:10 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.video.mesa3d.devel