Re: [Mesa-dev] [PATCH 5/5] i965 gen7: use SURFACE_STATE fields to select render level/layer
Jordan Justen writes:
> On Fri, May 24, 2013 at 2:17 PM, Paul Berry wrote:
>> On 22 May 2013 20:00, Jordan Justen wrote:
>>> On Wed, May 22, 2013 at 3:56 PM, Eric Anholt wrote:
>>> > Jordan Justen writes:
>>> >> - surf[0] = BRW_SURFACE_2D << BRW_SURFACE_TYPE_SHIFT |
>>> >> + switch (gl_target) {
>>> >> + case GL_TEXTURE_CUBE_MAP_ARRAY:
>>> >> + case GL_TEXTURE_CUBE_MAP:
>>> >> + surftype = BRW_SURFACE_2D;
>>> >> + is_array = true;
>>> >> + depth *= 6;
>>> >> + break;
>>> >> + default:
>>> >> + surftype = translate_tex_target(gl_target);
>>> >> + is_array = _mesa_tex_target_is_array(gl_target);
>>> >> + break;
>>> >> + }
>>> >
>>> > Why the conversion of cubes to arrays? It looks from mentions in the
>>> > "render target write" message section's mention of RTAI that cubes are
>>> > supported.
>>>
>>> Hmm. Good catch.
>>>
>>> I think I started implementing this in brw_wm_surface_state.c, so I
>>> was looking at what would be needed for the older gens. It looks like
>>> pre-gen6, that cube-arrays were not supported in the surface_state.
>>> I'm not sure right now why I extended that to include converting
>>> non-array cubes to 2d-arrays as well.
>>>
>>> Anyway, I'll investigate cleaning this up for gen7, since that is what
>>> we are starting with.
>>
>> When Jordan was first working on this feature, he asked me to help debug it,
>> and I found by reading simulator source code that SURFACE_STATE's "minimum
>> array element" field is ignored for cube surfaces (in direct contradiction
>> to the hw docs). Fortunately, treating the surface as an array is an
>> effective workaround, since for render targets there is effectively no
>> difference between a cube map and an ordinary array with a 6x higher depth.
>
> I guess I forgot this discussion of ours. I spent some time trying to
> get BRW_SURFACE_CUBE working (again, I suppose), with no luck.
>
> Anyway...
>
> Either of you good for an r-b on this second version of patch 5 in
> this series then?
Yeah, gets my r-b.
pgpmRXr4Elo5_.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeonsi needs libLLVMipo.
---
configure.ac | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure.ac b/configure.ac
index eef4327..486a4e9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1786,6 +1786,7 @@ if test "x$with_gallium_drivers" != x; then
gallium_require_drm_loader
GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS radeonsi"
radeon_llvm_check
+LLVM_COMPONENTS="${LLVM_COMPONENTS} ipo"
gallium_check_st "radeon/drm" "dri-radeonsi" "xorg-radeonsi" "" ""
"vdpau-radeonsi" ""
;;
xnouveau)
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Compile fix for radeonsi
Looks like the radeonsi build setup relies on other parts to pull in some dependencies. I seem to have a configuration where some of them aren't compiled. Mesa compiles without this patch, but radeonsi_dri.so will fail to load at runtime with missing symbol LLVMPassManagerBuilderCreate. My mesa config line is: ./configure --prefix=/opt/xorg --with-egl-platforms=x11,drm --enable-gbm --enable-shared-glapi --enable-gles1 --enable-gles2 --enable-glx-tls -disable-xvmc --with-gallium-drivers=r300,r600,svga,swrast,radeonsi PKG_CONFIG_PATH=/opt/xorg/lib/pkgconfig This fix is probably not good enough for all possible configurations. Is it even necessary to pick and choose LLVM parts, when it seems very uncommon to disable parts of it? Unnecessary libs are usually discarded at link time, so that the dynamic linker won't needlessly search for symbols in them at runtime. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Add missing break statement in _mesa_choose_tex_format.
Fixes "Missing break in switch" defect reported by Coverity. Signed-off-by: Vinson Lee --- src/mesa/main/texformat.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c index fda5d74..0ae79ea 100644 --- a/src/mesa/main/texformat.c +++ b/src/mesa/main/texformat.c @@ -218,6 +218,7 @@ _mesa_choose_tex_format(struct gl_context *ctx, GLenum target, RETURN_IF_SUPPORTED(MESA_FORMAT_Z16); RETURN_IF_SUPPORTED(MESA_FORMAT_X8_Z24); RETURN_IF_SUPPORTED(MESA_FORMAT_S8_Z24); + break; case GL_COMPRESSED_ALPHA_ARB: RETURN_IF_SUPPORTED(MESA_FORMAT_A8); -- 1.8.2.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/13] gallium: Introduce 32-bit bytewise format names
On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote: > > I agree that with non-array formats, like B5G6R5 and R5G6B5, replacing > them with endian-variant BGR565 and RGB565 makes a lot of sense (as > the swapped version will probably never be needed). > > But I'm not sure about RGBA8 variants... > > - On one hand, it is often more efficient to read/write them as 32bit > integers than as an array of bytes. > > - On the other hand it is easier to think of then as an array of > bytes than an integer quantity. > > One thing is clear -- a given format can't be both -- either it is > endianess-variant packed color or a endianness-invariant array color. Actually, I think it should be possible to make the RGBA8 variants usable as either an array of bytes or a packed integer, given the right setup of definitions and aliases (which would differ between little and big endian hosts). But I'm not sure offhand what would be the best way to achieve that for the util_format stuff. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] radeonsi/compute: Upload work group, work item size in input buffer
Am Freitag, 24. Mai 2013, 14:07:29 schrieb Tom Stellard:
> From: Tom Stellard
>
> ---
> src/gallium/drivers/radeonsi/radeonsi_compute.c | 38
> ++--- 1 file changed, 27 insertions(+), 11 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/radeonsi_compute.c
> b/src/gallium/drivers/radeonsi/radeonsi_compute.c index 035076d..3abf50b
> 100644
> --- a/src/gallium/drivers/radeonsi/radeonsi_compute.c
> +++ b/src/gallium/drivers/radeonsi/radeonsi_compute.c
> @@ -91,9 +91,12 @@ static void radeonsi_launch_grid(
> struct r600_context *rctx = (struct r600_context*)ctx;
> struct si_pipe_compute *program = rctx->cs_shader_state.program;
> struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
> - struct si_resource *input_buffer;
> - uint32_t input_offset = 0;
> - uint64_t input_va;
> + struct si_resource *kernel_args_buffer;
You should initialize this pointer to 0.
> + unsigned kernel_args_size;
> + unsigned num_work_size_bytes = 36;
> + uint32_t kernel_args_offset = 0;
> + uint32_t *kernel_args;
> + uint64_t kernel_args_va;
> uint64_t shader_va;
> unsigned arg_user_sgpr_count = 2;
> unsigned i;
> @@ -112,16 +115,29 @@ static void radeonsi_launch_grid(
> si_pm4_inval_shader_cache(pm4);
> si_cmd_surface_sync(pm4, pm4->cp_coher_cntl);
>
> - /* Upload the input data */
> - r600_upload_const_buffer(rctx, &input_buffer, input,
> - program->input_size, &input_offset);
> - input_va = r600_resource_va(ctx->screen, (struct
> pipe_resource*)input_buffer); - input_va += input_offset;
> + /* Upload the kernel arguments */
>
> - si_pm4_add_bo(pm4, input_buffer, RADEON_USAGE_READ);
> + /* The extra num_work_size_bytes are for work group / work item size
> information */ + kernel_args_size = program->input_size +
> num_work_size_bytes;
> + kernel_args = MALLOC(kernel_args_size);
> + for (i = 0; i < 3; i++) {
> + kernel_args[i] = grid_layout[i];
> + kernel_args[i + 3] = grid_layout[i] * block_layout[i];
> + kernel_args[i + 6] = block_layout[i];
> + }
> +
> + memcpy(kernel_args + (num_work_size_bytes / 4), input,
> program->input_size); +
> + r600_upload_const_buffer(rctx, &kernel_args_buffer, kernel_args,
> + kernel_args_size, &kernel_args_offset);
> + kernel_args_va = r600_resource_va(ctx->screen,
> + (struct pipe_resource*)kernel_args_buffer);
> + kernel_args_va += kernel_args_offset;
> +
> + si_pm4_add_bo(pm4, kernel_args_buffer, RADEON_USAGE_READ);
>
> - si_pm4_set_reg(pm4, R_00B900_COMPUTE_USER_DATA_0, input_va);
> - si_pm4_set_reg(pm4, R_00B900_COMPUTE_USER_DATA_0 + 4,
> S_008F04_BASE_ADDRESS_HI (input_va >> 32) | S_008F04_STRIDE(0));
> + si_pm4_set_reg(pm4, R_00B900_COMPUTE_USER_DATA_0, kernel_args_va);
> + si_pm4_set_reg(pm4, R_00B900_COMPUTE_USER_DATA_0 + 4,
> S_008F04_BASE_ADDRESS_HI (kernel_args_va >> 32) | S_008F04_STRIDE(0));
>
> si_pm4_set_reg(pm4, R_00B810_COMPUTE_START_X, 0);
> si_pm4_set_reg(pm4, R_00B814_COMPUTE_START_Y, 0);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] EGL_BAD_CONTEXT error when creating shared context
Hi, Does anyone know if mesa supports creation of shared context using egl? When I create a shared context with a call to eglCreateContext where the third argument is a valid context, I get EGL_BAD_CONTEXT error. Thanks & Regards, Divick ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
