Re: [Mesa-dev] [PATCH V5 1/2] i965/blorp: Add bilinear filtering of samples for multisample scaled blits
Anuj, Yeah -- multisample textures on Gen7 are currently UMS for color. If you wanted to enable support for CMS, it should be reasonably straightforward, but requires some tweaks in the shader backend. This looks like a really nice quality improvement -- for the series: Acked-by: Chris Forbes ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66346] New: shader_query.cpp:49: error: invalid conversion from 'void*' to 'GLuint'
https://bugs.freedesktop.org/show_bug.cgi?id=66346 Priority: medium Bug ID: 66346 Keywords: regression CC: bri...@vmware.com Assignee: mesa-dev@lists.freedesktop.org Summary: shader_query.cpp:49: error: invalid conversion from 'void*' to 'GLuint' Severity: blocker Classification: Unclassified OS: Mac OS X (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa mesa: 5a925cc5504575c22dbb7d29842d7fc5babcb5c7 (master) $ make [...] CXX shader_query.lo ../../src/mesa/main/shader_query.cpp: In function 'void _mesa_BindAttribLocation(void*, GLuint, const GLcharARB*)': ../../src/mesa/main/shader_query.cpp:49: error: invalid conversion from 'void*' to 'GLuint' ../../src/mesa/main/shader_query.cpp:49: error: initializing argument 2 of 'gl_shader_program* _mesa_lookup_shader_program_err$../../src/mesa/main/shader_query.cpp: In function 'void _mesa_GetActiveAttrib(void*, GLuint, GLsizei, GLsizei*, GLint*, GLenum*,$../../src/mesa/main/shader_query.cpp:87: error: invalid conversion from 'void*' to 'GLuint' ../../src/mesa/main/shader_query.cpp:87: error: initializing argument 2 of 'gl_shader_program* _mesa_lookup_shader_program_err$../../src/mesa/main/shader_query.cpp: In function 'GLint _mesa_GetAttribLocation(void*, const GLcharARB*)': ../../src/mesa/main/shader_query.cpp:139: error: invalid conversion from 'void*' to 'GLuint' ../../src/mesa/main/shader_query.cpp:139: error: initializing argument 2 of 'gl_shader_program* _mesa_lookup_shader_program_er$make[4]: *** [shader_query.lo] Error 1 $ gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. include/GL/glext.h 3468 #ifndef GL_ARB_shader_objects 3469 #define GL_ARB_shader_objects 1 3470 #ifdef __APPLE__ 3471 typedef void *GLhandleARB; 3472 #else 3473 typedef unsigned int GLhandleARB; 3474 #endif -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] clover: Fix build with LLVM 3.4
On Fri, Jun 28, 2013 at 09:41:45AM -0500, Aaron Watry wrote:
> PathV1.h has been removed. In theory this can go back before llvm 3.4, but I
> haven't done the research to find out how far back.
>
> Signed-off-by: Aaron Watry
I pushed a similar commit yesterday:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=0e990736f34c43f553d4516bc6ffb8fe521e3806
Is the build still broken even with this commit?
-Tom
> ---
> src/gallium/state_trackers/clover/llvm/invocation.cpp | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 362f02f..ee0249d 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -43,7 +43,12 @@
> #include
> #include
> #include
> +#if HAVE_LLVM < 0x0304
> #include
> +#else
> +#include
> +#include
> +#endif
> #include
> #include
>
> @@ -222,9 +227,16 @@ namespace {
>
>llvm::PassManager PM;
>llvm::PassManagerBuilder Builder;
> +#if HAVE_LLVM < 0x0304
>llvm::sys::Path libclc_path =
> llvm::sys::Path(LIBCLC_LIBEXECDIR + processor +
> "-" + triple + ".bc");
> +#else
> + llvm::SmallString<1> libclc_path;
> + libclc_path = LIBCLC_LIBEXECDIR;
> + std::string file_name = processor + "-" + triple + ".bc";
> + llvm::sys::path::append(libclc_path, file_name);
> +#endif
>
>// Link the kernel with libclc
> #if HAVE_LLVM < 0x0303
> --
> 1.8.1.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH V5 1/2] i965/blorp: Add bilinear filtering of samples for multisample scaled blits
Current implementation of ext_framebuffer_multisample_blit_scaled in
i965/blorp uses nearest filtering for multisample scaled blits. Using
nearest filtering produces blocky artifacts and negates the benefits
of MSAA. That is the reason why extension was not enabled on i965.
This patch implements the bilinear filtering of samples in blorp engine.
Images generated with this patch are free from blocky artifacts and show
big improvement in visual quality.
Observed no piglit and gles3 regressions.
V3:
- Algorithm used for filtering assumes a rectangular grid of samples
roughly corresponding to sample locations.
- Test the boundary conditions on the edges of texture.
V4:
- Clip texcoords and use conditional MOVs.
- Send texture dimensions as push constants.
- Remove the optimization in case of scaled multisample blits.
V5:
- Move mcs_fetch() inside the 'for' loop after computing pixel coordinates.
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dri/i965/brw_blorp.h| 16 ++
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 278 +--
2 files changed, 273 insertions(+), 21 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.h
b/src/mesa/drivers/dri/i965/brw_blorp.h
index ffc27cc..9277d09 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.h
+++ b/src/mesa/drivers/dri/i965/brw_blorp.h
@@ -178,8 +178,15 @@ struct brw_blorp_wm_push_constants
uint32_t dst_x1;
uint32_t dst_y0;
uint32_t dst_y1;
+ /* Top right coordinates of the rectangular sample grid used for
+* multisample scaled blitting.
+*/
+ float sample_grid_x1;
+ float sample_grid_y1;
brw_blorp_coord_transform_params x_transform;
brw_blorp_coord_transform_params y_transform;
+ /* Pad out to an integral number of registers */
+ uint32_t pad[6];
};
/* Every 32 bytes of push constant data constitutes one GEN register. */
@@ -319,6 +326,15 @@ struct brw_blorp_blit_prog_key
* than one sample per pixel.
*/
bool persample_msaa_dispatch;
+
+ /* True for scaled blitting. */
+ bool blit_scaled;
+
+ /* Scale factors between the pixel grid and the grid of samples. We're
+* using grid of samples for bilinear filetring in multisample scaled blits.
+*/
+ float x_scale;
+ float y_scale;
};
class brw_blorp_blit_params : public brw_blorp_params
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 8694128..d39bae1 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -622,7 +622,8 @@ private:
void kill_if_outside_dst_rect();
void translate_dst_to_src();
void single_to_blend();
- void manual_blend(unsigned num_samples);
+ void manual_blend_average(unsigned num_samples);
+ void manual_blend_bilinear(unsigned num_samples);
void sample(struct brw_reg dst);
void texel_fetch(struct brw_reg dst);
void mcs_fetch();
@@ -651,6 +652,11 @@ private:
struct brw_reg dst_x1;
struct brw_reg dst_y0;
struct brw_reg dst_y1;
+ /* Top right coordinates of the rectangular sample grid used for
+* multisample scaled blitting.
+*/
+ struct brw_reg sample_grid_x1;
+ struct brw_reg sample_grid_y1;
struct {
struct brw_reg multiplier;
struct brw_reg offset;
@@ -676,6 +682,16 @@ private:
*/
struct brw_reg y_coords[2];
+ /* X, Y coordinates of the pixel from which we need to fetch the specific
+* sample. These are used for multisample scaled blitting.
+*/
+ struct brw_reg x_sample_coords;
+ struct brw_reg y_sample_coords;
+
+ /* Fractional parts of the x and y coordinates, used as bilinear
interpolation coefficients */
+ struct brw_reg x_frac;
+ struct brw_reg y_frac;
+
/* Which element of x_coords and y_coords is currently in use.
*/
int xy_coord_index;
@@ -814,15 +830,17 @@ brw_blorp_blit_program::compile(struct brw_context *brw,
* that we want to texture from. Exception: if we are blending, then S is
* irrelevant, because we are going to fetch all samples.
*/
- if (key->blend) {
+ if (key->blend && !key->blit_scaled) {
if (brw->intel.gen == 6) {
/* Gen6 hardware an automatically blend using the SAMPLE message */
single_to_blend();
sample(texture_data[0]);
} else {
/* Gen7+ hardware doesn't automaticaly blend. */
- manual_blend(key->src_samples);
+ manual_blend_average(key->src_samples);
}
+ } else if(key->blend && key->blit_scaled) {
+ manual_blend_bilinear(key->src_samples);
} else {
/* We aren't blending, which means we just want to fetch a single sample
* from the source surface. The address that we want to fetch from is
@@ -872,18 +890,21 @@ void
brw_blorp_blit_program::alloc_push_const_regs(int base_reg)
{
#define CONST_LOC(name) offsetof(brw_blorp_wm_push_constants, name)
-#define ALLOC_REG(name) \
+#define ALLOC_REG(name,
Re: [Mesa-dev] [PATCH V3 1/2] i965/blorp: Add bilinear filtering of samples for multisample scaled blits
>> >>
>> >> +void
>> >> +brw_blorp_blit_program::manual_blend_linear(unsigned num_samples)
>> >> +{
>> >> + if (key->tex_layout == INTEL_MSAA_LAYOUT_CMS)
>> >> + mcs_fetch();
>> >
>> >
>> > This won't work. The MCS value we fetch has to match up with the pixel
>> > that we're sampling from. Since this function samples from different
>> > pixels
>> > in each iteration of the "for" loop below, the call to mcs_fetch() needs to
>> > go inside the loop, and it needs to happen after storing the coordinates in
>> > X and Y.
>> >
>> I think MCS value fetch will not be required anymore as we are anyway
>> getting rid of optimization which compares mcs value to zero.
>
>
> MCS fetch is still needed, since the MCS value needs to be passed into the
> ld2dms message that is used to read the samples from the surface.
Yes, you are right. My piglit test case for scaled blitting uses multisample
framebuffer with texture attachment. Debugging the test case showed that
multisample textures use INTEL_MSAA_LAYOUT_UMS. That's the reason
test case continued passing even after deleting mcs fetch code.
So, I modified the test case to use multisample framebuffer with renderbuffer
attachment as well for testing. Test continued failing without mcs fetch code.
Test passed after moving the mcs_fetch() inside the 'for' loop just after
computing the pixel coordinates. I think this verifies that mcs_fetch() is
now happening correctly. You can find my piglit tests (blit-scaled-glsl.cpp
and negative-blit-scaled.cpp) at:
https://github.com/aphogat/piglit.git, branch: 'blit-3'
As suggested by you, I'll also try developing a more exhaustive test to verify
mcs fetch value. In the mean time, please take a look at my piglit test cases
and suggest if they're good enough to verify the implementation and enable
the extension on intel hardware with my latest patch (V5).
>>
>> >>
>> >> +
>> >> + /* We do this computation by performing the following operations:
>> >> +*
>> >> +* In case of 4x, 8x MSAA:
>> >> +* - Compute the pixel coordinates and sample numbers (a, b, c, d)
>> >> +* which are later used for interpolation
>> >> +* - linearly interpolate samples a and b in X
>> >> +* - linearly interpolate samples c and d in X
>> >> +* - linearly interpolate the results of last two operations in Y
>> >> +*
>> >> +* result = lrp(lrp(a + b) + lrp(c + d))
>> >> +*/
>> >> + struct brw_reg Xp_f = retype(Xp, BRW_REGISTER_TYPE_F);
>> >> + struct brw_reg Yp_f = retype(Yp, BRW_REGISTER_TYPE_F);
>> >> + struct brw_reg t1_f = retype(t1, BRW_REGISTER_TYPE_F);
>> >> + struct brw_reg t2_f = retype(t2, BRW_REGISTER_TYPE_F);
>> >> +
>> >> + for (unsigned i = 0; i < 4; ++i) {
>> >> + assert(i < ARRAY_SIZE(texture_data));
>> >> + s_is_zero = false;
>> >> +
>> >> + /* Compute pixel coordinates */
>> >> + brw_ADD(&func, vec16(x_sample_coords), Xp_f,
>> >> + brw_imm_f((float)(i & 0x1) * 0.5));
>> >> + brw_ADD(&func, vec16(y_sample_coords), Yp_f,
>> >> + brw_imm_f((float)(i & 0x2) * (1.0 / num_samples)));
>> >> + brw_MOV(&func, vec16(X), x_sample_coords);
>> >> + brw_MOV(&func, vec16(Y), y_sample_coords);
>> >> +
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Delete pre-DRI2.3 viewport hacks.
The __DRI_USE_INVALIDATE extension was added in May 11th, 2010 by commit
4258e3a2e1c327. At this point, it's unlikely that anyone's using the
right mix of new and old components to hit this path. Deleting it
removes an untested code path and cleans up the driver a bit.
Cc: Kristian Høgsberg
Cc: Keith Packard
---
src/mesa/drivers/dri/i965/intel_context.c | 21 -
src/mesa/drivers/dri/i965/intel_context.h | 2 --
src/mesa/drivers/dri/i965/intel_tex_image.c | 3 +--
3 files changed, 1 insertion(+), 25 deletions(-)
I'm guessing this would break if you had an early-2010 X server or libGL
and modern i965_dri.so. I'm not sure how to properly require this extension
to be present (and fail loading otherwise?). Any advice?
diff --git a/src/mesa/drivers/dri/i965/intel_context.c
b/src/mesa/drivers/dri/i965/intel_context.c
index 79420a2..491094f 100644
--- a/src/mesa/drivers/dri/i965/intel_context.c
+++ b/src/mesa/drivers/dri/i965/intel_context.c
@@ -292,21 +292,6 @@ intel_prepare_render(struct intel_context *intel)
}
}
-static void
-intel_viewport(struct gl_context *ctx, GLint x, GLint y, GLsizei w, GLsizei h)
-{
-struct intel_context *intel = intel_context(ctx);
-__DRIcontext *driContext = intel->driContext;
-
-if (intel->saved_viewport)
- intel->saved_viewport(ctx, x, y, w, h);
-
-if (_mesa_is_winsys_fbo(ctx->DrawBuffer)) {
- dri2InvalidateDrawable(driContext->driDrawablePriv);
- dri2InvalidateDrawable(driContext->driReadablePriv);
-}
-}
-
static const struct dri_debug_control debug_control[] = {
{ "tex", DEBUG_TEXTURE},
{ "state", DEBUG_STATE},
@@ -476,12 +461,6 @@ intelInitContext(struct intel_context *intel,
dri_ctx_error))
return false;
- /* Can't rely on invalidate events, fall back to glViewport hack */
- if (!driContextPriv->driScreenPriv->dri2.useInvalidate) {
- intel->saved_viewport = functions->Viewport;
- functions->Viewport = intel_viewport;
- }
-
if (mesaVis == NULL) {
memset(&visual, 0, sizeof visual);
mesaVis = &visual;
diff --git a/src/mesa/drivers/dri/i965/intel_context.h
b/src/mesa/drivers/dri/i965/intel_context.h
index 98def93..fff91db 100644
--- a/src/mesa/drivers/dri/i965/intel_context.h
+++ b/src/mesa/drivers/dri/i965/intel_context.h
@@ -252,8 +252,6 @@ struct intel_context
__DRIcontext *driContext;
struct intel_screen *intelScreen;
- void (*saved_viewport)(struct gl_context * ctx,
- GLint x, GLint y, GLsizei width, GLsizei height);
/**
* Configuration cache
diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index 0d0c7f1..5a10a37 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -310,8 +310,7 @@ intelSetTexBuffer2(__DRIcontext *pDRICtx, GLint target,
if (!intelObj)
return;
- if (dPriv->lastStamp != dPriv->dri2.stamp ||
- !pDRICtx->driScreenPriv->dri2.useInvalidate)
+ if (dPriv->lastStamp != dPriv->dri2.stamp)
intel_update_renderbuffers(pDRICtx, dPriv);
rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl/builtins: Fix ARB_texture_cube_map_array built-in availability.
On Sat, Jun 29, 2013 at 7:22 AM, Kenneth Graunke wrote: > This patch adds texture() for isamplerCubeArray and usamplerCubeArray, > which were entirely missing. > > It also makes texture() with a LOD bias fragment shader specific. The > main GLSL specification explicitly says that texturing with LOD bias > should not be allowed for vertex shaders. > > Affects Piglit's ARB_texture_cube_map_array/compiler/tex_bias-01.vert. > which tries to use bias in a vertex shader. Currently, it expects this > to pass (so this patch regresses the test), but I've sent a patch to > reverse the expected behavior (so this patch would fix the updated test): > http://lists.freedesktop.org/archives/piglit/2013-June/006123.html No idea how I missed these. Reviewed-by: Dave Airlie > > NOTE: This is a candidate for stable branches. > > Cc: Paul Berry > Signed-off-by: Kenneth Graunke > --- > src/glsl/builtins/profiles/ARB_texture_cube_map_array.frag | 6 ++ > src/glsl/builtins/profiles/ARB_texture_cube_map_array.glsl | 3 ++- > 2 files changed, 8 insertions(+), 1 deletion(-) > create mode 100644 src/glsl/builtins/profiles/ARB_texture_cube_map_array.frag > > diff --git a/src/glsl/builtins/profiles/ARB_texture_cube_map_array.frag > b/src/glsl/builtins/profiles/ARB_texture_cube_map_array.frag > new file mode 100644 > index 000..0d9f4f6 > --- /dev/null > +++ b/src/glsl/builtins/profiles/ARB_texture_cube_map_array.frag > @@ -0,0 +1,6 @@ > +#version 130 > +#extension GL_ARB_texture_cube_map_array : enable > + > + vec4 texture( samplerCubeArray sampler, vec4 coord, float bias); > +ivec4 texture(isamplerCubeArray sampler, vec4 coord, float bias); > +uvec4 texture(usamplerCubeArray sampler, vec4 coord, float bias); > diff --git a/src/glsl/builtins/profiles/ARB_texture_cube_map_array.glsl > b/src/glsl/builtins/profiles/ARB_texture_cube_map_array.glsl > index 0f53212..73659b3 100644 > --- a/src/glsl/builtins/profiles/ARB_texture_cube_map_array.glsl > +++ b/src/glsl/builtins/profiles/ARB_texture_cube_map_array.glsl > @@ -7,7 +7,8 @@ ivec3 textureSize(usamplerCubeArray sampler, int lod); > ivec3 textureSize(samplerCubeArrayShadow sampler, int lod); > > vec4 texture( samplerCubeArray sampler, vec4 coord); > - vec4 texture( samplerCubeArray sampler, vec4 coord, float bias); > +ivec4 texture(isamplerCubeArray sampler, vec4 coord); > +uvec4 texture(usamplerCubeArray sampler, vec4 coord); > float texture( samplerCubeArrayShadow sampler, vec4 P, float compare); > > vec4 textureGrad( samplerCubeArray sampler, vec4 P, vec3 dPdx, vec3 dPdy); > -- > 1.8.3.1 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/2] radeonsi: Handle TGSI_OPCODE_TXD
On Wed, Jun 19, 2013 at 06:30:49PM +0200, Michel Dänzer wrote:
> From: Michel Dänzer
>
> One more little piglit.
>
> Signed-off-by: Michel Dänzer
For the series:
Reviewed-by: Tom Stellard
> ---
>
> v2: Only use the new functionality as of LLVM 3.4.
>
> src/gallium/drivers/radeonsi/radeonsi_shader.c | 27
> --
> 1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
> b/src/gallium/drivers/radeonsi/radeonsi_shader.c
> index f6fdfae..7f3d38b 100644
> --- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
> +++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
> @@ -875,6 +875,7 @@ static void tex_fetch_args(
> const struct tgsi_full_instruction * inst = emit_data->inst;
> unsigned opcode = inst->Instruction.Opcode;
> unsigned target = inst->Texture.Texture;
> + unsigned sampler_src;
> LLVMValueRef coords[4];
> LLVMValueRef address[16];
> int ref_pos;
> @@ -920,6 +921,15 @@ static void tex_fetch_args(
> address[count++] = lp_build_emit_fetch(bld_base, inst, 1, 0);
> }
>
> + /* Pack user derivatives */
> + if (opcode == TGSI_OPCODE_TXD) {
> + for (chan = 0; chan < 2; chan++) {
> + address[count++] = lp_build_emit_fetch(bld_base, inst,
> 1, chan);
> + if (num_coords > 1)
> + address[count++] =
> lp_build_emit_fetch(bld_base, inst, 2, chan);
> + }
> + }
> +
> /* Pack texture coordinates */
> address[count++] = coords[0];
> if (num_coords > 1)
> @@ -961,8 +971,10 @@ static void tex_fetch_args(
>"");
> }
>
> + sampler_src = emit_data->inst->Instruction.NumSrcRegs - 1;
> +
> /* Resource */
> - emit_data->args[1] =
> si_shader_ctx->resources[emit_data->inst->Src[1].Register.Index];
> + emit_data->args[1] =
> si_shader_ctx->resources[emit_data->inst->Src[sampler_src].Register.Index];
>
> if (opcode == TGSI_OPCODE_TXF) {
> /* add tex offsets */
> @@ -993,7 +1005,7 @@ static void tex_fetch_args(
> emit_data->arg_count = 3;
> } else {
> /* Sampler */
> - emit_data->args[2] =
> si_shader_ctx->samplers[emit_data->inst->Src[1].Register.Index];
> + emit_data->args[2] =
> si_shader_ctx->samplers[emit_data->inst->Src[sampler_src].Register.Index];
>
> emit_data->dst_type = LLVMVectorType(
> LLVMFloatTypeInContext(bld_base->base.gallivm->context),
> @@ -1065,6 +1077,14 @@ static const struct lp_build_tgsi_action txb_action = {
> .intr_name = "llvm.SI.sampleb."
> };
>
> +#if HAVE_LLVM >= 0x0304
> +static const struct lp_build_tgsi_action txd_action = {
> + .fetch_args = tex_fetch_args,
> + .emit = build_tex_intrinsic,
> + .intr_name = "llvm.SI.sampled."
> +};
> +#endif
> +
> static const struct lp_build_tgsi_action txf_action = {
> .fetch_args = tex_fetch_args,
> .emit = build_tex_intrinsic,
> @@ -1321,6 +1341,9 @@ int si_pipe_shader_create(
>
> bld_base->op_actions[TGSI_OPCODE_TEX] = tex_action;
> bld_base->op_actions[TGSI_OPCODE_TXB] = txb_action;
> +#if HAVE_LLVM >= 0x0304
> + bld_base->op_actions[TGSI_OPCODE_TXD] = txd_action;
> +#endif
> bld_base->op_actions[TGSI_OPCODE_TXF] = txf_action;
> bld_base->op_actions[TGSI_OPCODE_TXL] = txl_action;
> bld_base->op_actions[TGSI_OPCODE_TXP] = tex_action;
> --
> 1.8.3.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Avoid flushing the batch for every blorp op.
Eric Anholt writes: > This brings over the batch-wrap-prevention and aperture space checking > code from the normal brw_draw.c path, so that we don't need to flush the > batch every time. > > There's a risk here if the intel_emit_post_sync_nonzero_flush() call isn't > high enough up in the state emit sequences -- before, we implicitly had > one at the batch flush before any state was emitted, so Mesa's workaround > emits didn't really matter. > > Improves cairo-gl performance by 13.7733% +/- 1.74876% (n=30/32) > No statistically significant performance difference on unigine tropics > (n=10) > No statistically significant performance difference on openarena (n=755) > No statistically significant performance difference on Lightsmark (n=15, > though this may be an issue of test power -- looks like a ~.3% > performance hit) > Reduces low-resolution GLB 2.7 performance by 0.604517% +/- 0.140544% > (n=132/133) > --- > I've got the test system running more Lightsmark now -- the bimodal > distribution of its results was killing the stats, and I'd bumped the > power cable and it ran out of battery and died. > > I'm a little mystified by the small GLB and possibly LM regressions. > My theory was the first-post-swap-batch throttling, except > that we've got about 5 batches per frame on GLB. Updated LM results: -2.45051% +/- 0.341284% (n=30/32). At this point I think we do need to figure out these regressions before landing the change. It's on the blorp-flush branch of my tree if someone wants to follow up while I'm gone. pgpNJU3z8Thrt.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] R600/SI: Support for local memory and derivatives
On Wed, Jun 19, 2013 at 06:28:21PM +0200, Michel Dänzer wrote:
>
> These patches implement enough of local memory support to allow radeonsi
> to use that for computing derivatives, as suggested by Tom.
>
> They also almost allow test/CodeGen/R600/local-memory.ll to generate
> code for SI. Right now it still fails because it tries to copy a VGPR to
> an SGPR, which is not possible.
>
>
Can you add some lit tests for these new intrinsics and also add CHECK
lines for SI to the existing local-memory.ll test.
With the tests added, these patches are:
Reviewed-by: Tom Stellard
> --
> Earthling Michel Dänzer | http://www.amd.com
> Libre software enthusiast | Debian, X and DRI developer
> From f4ca359c4536aa53122b654196f2e007d50976f8 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Michel=20D=C3=A4nzer?=
> Date: Thu, 21 Feb 2013 16:12:45 +0100
> Subject: [PATCH 1/6] R600/SI: Add intrinsics for texture sampling with user
> derivatives
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Signed-off-by: Michel Dänzer
> ---
> lib/Target/R600/SIInstructions.td | 7 ++-
> lib/Target/R600/SIIntrinsics.td | 1 +
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/lib/Target/R600/SIInstructions.td
> b/lib/Target/R600/SIInstructions.td
> index 9c96c08..c9eac7d 100644
> --- a/lib/Target/R600/SIInstructions.td
> +++ b/lib/Target/R600/SIInstructions.td
> @@ -535,7 +535,7 @@ def IMAGE_SAMPLE_B : MIMG_Sampler_Helper <0x0025,
> "IMAGE_SAMPLE_B">;
> //def IMAGE_SAMPLE_LZ : MIMG_NoPattern_ <"IMAGE_SAMPLE_LZ", 0x0027>;
> def IMAGE_SAMPLE_C : MIMG_Sampler_Helper <0x0028, "IMAGE_SAMPLE_C">;
> //def IMAGE_SAMPLE_C_CL : MIMG_NoPattern_ <"IMAGE_SAMPLE_C_CL", 0x0029>;
> -//def IMAGE_SAMPLE_C_D : MIMG_NoPattern_ <"IMAGE_SAMPLE_C_D", 0x002a>;
> +def IMAGE_SAMPLE_C_D : MIMG_Sampler_Helper <0x002a, "IMAGE_SAMPLE_C_D">;
> //def IMAGE_SAMPLE_C_D_CL : MIMG_NoPattern_ <"IMAGE_SAMPLE_C_D_CL",
> 0x002b>;
> def IMAGE_SAMPLE_C_L : MIMG_Sampler_Helper <0x002c, "IMAGE_SAMPLE_C_L">;
> def IMAGE_SAMPLE_C_B : MIMG_Sampler_Helper <0x002d, "IMAGE_SAMPLE_C_B">;
> @@ -1296,6 +1296,11 @@ multiclass SamplePatterns {
>def : SampleArrayPattern ;
>def : SampleShadowPattern ;
>def : SampleShadowArrayPattern addr_type>;
> +
> + def : SamplePattern ;
> + def : SampleArrayPattern ;
> + def : SampleShadowPattern ;
> + def : SampleShadowArrayPattern addr_type>;
> }
>
> defm : SamplePatterns;
> diff --git a/lib/Target/R600/SIIntrinsics.td b/lib/Target/R600/SIIntrinsics.td
> index 224cd2f..d2643e0 100644
> --- a/lib/Target/R600/SIIntrinsics.td
> +++ b/lib/Target/R600/SIIntrinsics.td
> @@ -23,6 +23,7 @@ let TargetPrefix = "SI", isTarget = 1 in {
>
>def int_SI_sample : Sample;
>def int_SI_sampleb : Sample;
> + def int_SI_sampled : Sample;
>def int_SI_samplel : Sample;
>
>def int_SI_imageload : Intrinsic <[llvm_v4i32_ty], [llvm_anyvector_ty,
> llvm_v32i8_ty, llvm_i32_ty], [IntrNoMem]>;
> --
> 1.8.3.1
>
> From 7a0048bb2ab1b661831da2b764bf1a52f66bec15 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Michel=20D=C3=A4nzer?=
> Date: Thu, 21 Feb 2013 18:51:38 +0100
> Subject: [PATCH v3 2/6] R600/SI: Initial support for LDS/GDS instructions
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Signed-off-by: Michel Dänzer
> ---
>
> v3: Drop vdst operand from DS_Store_Helper class, and adapt
> SIInsertWaits::getHwCounts() to handle that. Unfortunately, this seems
> to mess up the asm string output somehow, not sure what's going on
> there.
>
> lib/Target/R600/SIInsertWaits.cpp | 2 ++
> lib/Target/R600/SIInstrFormats.td | 24
> lib/Target/R600/SIInstrInfo.td | 23 +++
> lib/Target/R600/SIInstructions.td | 3 +++
> lib/Target/R600/SILowerControlFlow.cpp | 16
> 5 files changed, 68 insertions(+)
>
> diff --git a/lib/Target/R600/SIInsertWaits.cpp
> b/lib/Target/R600/SIInsertWaits.cpp
> index c36e1dc..d31da45 100644
> --- a/lib/Target/R600/SIInsertWaits.cpp
> +++ b/lib/Target/R600/SIInsertWaits.cpp
> @@ -134,6 +134,8 @@ Counters SIInsertWaits::getHwCounts(MachineInstr &MI) {
>if (TSFlags & SIInstrFlags::LGKM_CNT) {
>
> MachineOperand &Op = MI.getOperand(0);
> +if (!Op.isReg())
> + Op = MI.getOperand(1);
> assert(Op.isReg() && "First LGKM operand must be a register!");
>
> unsigned Reg = Op.getReg();
> diff --git a/lib/Target/R600/SIInstrFormats.td
> b/lib/Target/R600/SIInstrFormats.td
> index 51f323d..434aa7e 100644
> --- a/lib/Target/R600/SIInstrFormats.td
> +++ b/lib/Target/R600/SIInstrFormats.td
> @@ -281,6 +281,30 @@ class VINTRP op, dag outs, dag ins, string
> asm, list pattern> :
>
> let Uses = [EXEC] in {
>
> +class DS op, dag outs, dag ins, string asm, list pattern> :
> +Enc64 {
[Mesa-dev] [PATCH] draw/translate: fix instancing
We were incorrectly computing the buffer offset when using the
instances. The buffer offset is always equal to:
start_instance * stride + (instance_num / instance_divisor) *
stride
We were completely ignoring the start instance quite
often producing instances that completely wrong, e.g. if
start instance = 5, instance divisor = 2, then on the first
iteration it should be:
5 * stride, not (5/2) * stride as we'd have currently, and if
start instance = 1, instance divisor = 3, then on the first
iteration it should be:
1 * stride, not 0 as we'd have.
This fixes it and adjusts all the code to the changes.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_llvm.c | 15 ++---
src/gallium/auxiliary/draw/draw_pipe_vbuf.c|2 +-
src/gallium/auxiliary/draw/draw_private.h |1 +
src/gallium/auxiliary/draw/draw_pt.c |1 +
src/gallium/auxiliary/draw/draw_pt_emit.c |2 ++
src/gallium/auxiliary/draw/draw_pt_fetch.c |2 ++
src/gallium/auxiliary/draw/draw_pt_fetch_emit.c|3 ++
src/gallium/auxiliary/draw/draw_pt_so_emit.c | 23 --
src/gallium/auxiliary/draw/draw_vs_variant.c |4 +++
src/gallium/auxiliary/translate/translate.h|4 +++
.../auxiliary/translate/translate_generic.c| 17 ---
src/gallium/auxiliary/translate/translate_sse.c| 32
src/gallium/auxiliary/util/u_vbuf.c|8 ++---
src/gallium/drivers/nv30/nv30_push.c |8 ++---
src/gallium/drivers/nv50/nv50_push.c |8 ++---
src/gallium/drivers/nvc0/nvc0_push.c |8 ++---
src/gallium/drivers/nvc0/nvc0_vbo_translate.c |8 ++---
17 files changed, 106 insertions(+), 40 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index 97b463f..9eb5a93 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -674,6 +674,7 @@ generate_vs(struct draw_llvm_variant *variant,
static void
generate_fetch(struct gallivm_state *gallivm,
+ struct draw_context *draw,
LLVMValueRef vbuffers_ptr,
LLVMValueRef *res,
struct pipe_vertex_element *velem,
@@ -704,10 +705,14 @@ generate_fetch(struct gallivm_state *gallivm,
struct lp_build_if_state if_ctx;
if (velem->instance_divisor) {
- /* array index = instance_id / instance_divisor */
- index = LLVMBuildUDiv(builder, instance_id,
-lp_build_const_int32(gallivm,
velem->instance_divisor),
-"instance_divisor");
+ LLVMValueRef current_instance;
+ /* array index = start_instance + (instance_num / instance_divisor) */
+ index = lp_build_const_int32(gallivm, draw->start_instance);
+ current_instance = LLVMBuildSub(builder, instance_id, index, "");
+ current_instance = LLVMBuildUDiv(builder, current_instance,
+ lp_build_const_int32(gallivm,
velem->instance_divisor),
+ "instance_divisor");
+ index = LLVMBuildAdd(builder, index, current_instance, "instance");
}
stride = lp_build_umul_overflow(gallivm, vb_stride, index, &ofbit);
@@ -1697,7 +1702,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
LLVMValueRef vb_index =
lp_build_const_int32(gallivm, velem->vertex_buffer_index);
LLVMValueRef vb = LLVMBuildGEP(builder, vb_ptr, &vb_index, 1, "");
-generate_fetch(gallivm, vbuffers_ptr,
+generate_fetch(gallivm, draw, vbuffers_ptr,
&aos_attribs[j][i], velem, vb, true_index,
system_values.instance_id);
}
diff --git a/src/gallium/auxiliary/draw/draw_pipe_vbuf.c
b/src/gallium/auxiliary/draw/draw_pipe_vbuf.c
index 578433c..d3b38eb 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_vbuf.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_vbuf.c
@@ -138,7 +138,7 @@ emit_vertex( struct vbuf_stage *vbuf,
/* Note: we really do want data[0] here, not data[pos]:
*/
vbuf->translate->set_buffer(vbuf->translate, 0, vertex->data[0], 0, ~0);
- vbuf->translate->run(vbuf->translate, 0, 1, 0, vbuf->vertex_ptr);
+ vbuf->translate->run(vbuf->translate, 0, 1, 0, 0, vbuf->vertex_ptr);
if (0) draw_dump_emitted_vertex(vbuf->vinfo, (uint8_t
*)vbuf->vertex_ptr);
diff --git a/src/gallium/auxiliary/draw/draw_private.h
b/src/gallium/auxiliary/draw/draw_private.h
index fd52c2d..f42cded 100644
--- a/src/gallium/auxiliary/draw/draw_private.h
+++ b/src/gallium/auxiliary/draw/draw_private.h
@@ -306,6 +306,7 @@ struct draw_context
} extra_shader_outputs;
unsigned instance_id;
+ unsigned start_instance;
#ifdef HAVE_LLVM
struct draw_llvm *llvm;
diff --git a/src/galli
[Mesa-dev] [PATCH] glsl/builtins: Fix ARB_texture_cube_map_array built-in availability.
This patch adds texture() for isamplerCubeArray and usamplerCubeArray, which were entirely missing. It also makes texture() with a LOD bias fragment shader specific. The main GLSL specification explicitly says that texturing with LOD bias should not be allowed for vertex shaders. Affects Piglit's ARB_texture_cube_map_array/compiler/tex_bias-01.vert. which tries to use bias in a vertex shader. Currently, it expects this to pass (so this patch regresses the test), but I've sent a patch to reverse the expected behavior (so this patch would fix the updated test): http://lists.freedesktop.org/archives/piglit/2013-June/006123.html NOTE: This is a candidate for stable branches. Cc: Paul Berry Signed-off-by: Kenneth Graunke --- src/glsl/builtins/profiles/ARB_texture_cube_map_array.frag | 6 ++ src/glsl/builtins/profiles/ARB_texture_cube_map_array.glsl | 3 ++- 2 files changed, 8 insertions(+), 1 deletion(-) create mode 100644 src/glsl/builtins/profiles/ARB_texture_cube_map_array.frag diff --git a/src/glsl/builtins/profiles/ARB_texture_cube_map_array.frag b/src/glsl/builtins/profiles/ARB_texture_cube_map_array.frag new file mode 100644 index 000..0d9f4f6 --- /dev/null +++ b/src/glsl/builtins/profiles/ARB_texture_cube_map_array.frag @@ -0,0 +1,6 @@ +#version 130 +#extension GL_ARB_texture_cube_map_array : enable + + vec4 texture( samplerCubeArray sampler, vec4 coord, float bias); +ivec4 texture(isamplerCubeArray sampler, vec4 coord, float bias); +uvec4 texture(usamplerCubeArray sampler, vec4 coord, float bias); diff --git a/src/glsl/builtins/profiles/ARB_texture_cube_map_array.glsl b/src/glsl/builtins/profiles/ARB_texture_cube_map_array.glsl index 0f53212..73659b3 100644 --- a/src/glsl/builtins/profiles/ARB_texture_cube_map_array.glsl +++ b/src/glsl/builtins/profiles/ARB_texture_cube_map_array.glsl @@ -7,7 +7,8 @@ ivec3 textureSize(usamplerCubeArray sampler, int lod); ivec3 textureSize(samplerCubeArrayShadow sampler, int lod); vec4 texture( samplerCubeArray sampler, vec4 coord); - vec4 texture( samplerCubeArray sampler, vec4 coord, float bias); +ivec4 texture(isamplerCubeArray sampler, vec4 coord); +uvec4 texture(usamplerCubeArray sampler, vec4 coord); float texture( samplerCubeArrayShadow sampler, vec4 P, float compare); vec4 textureGrad( samplerCubeArray sampler, vec4 P, vec3 dPdx, vec3 dPdy); -- 1.8.3.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] r600g: implement fast color clears on evergreen+
Oh, sorry. The patch looks good. I applied it to my local repository, but I haven't got around to testing it yet. i'll push it soon. Marek On Fri, Jun 28, 2013 at 8:46 PM, Grigori Goronzy wrote: > On 12.06.2013 00:04, Grigori Goronzy wrote: >> >> Allows MSAA colorbuffers, which have a CMASK automatically and don't >> need any further special handling, to be fast cleared. Instead >> of clearing the buffer, set the clear color and the CMASK to the >> cleared state. >> >> Fast clear is used only when all bound colorbuffers fulfill certain >> conditions: a CMASK is required, we have to be able to create a clear >> color value for the format and the texture mustn't contain multiple >> images. Technically, it should be possible to support array textures >> and cubemaps if all images are attached to the framebuffer, >> but this does not appear to be common. >> >> v2: fix fast clear check > > > Ping? Can anyone please review this? > > Best regards > Grigori > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] R600/SI: Add processor types for each CIK variant
On Fri, Jun 28, 2013 at 03:05:04PM -0400, alexdeuc...@gmail.com wrote: > From: Alex Deucher > > Signed-off-by: Alex Deucher Committed, thanks! -Tom > --- > lib/Target/R600/Processors.td |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/lib/Target/R600/Processors.td b/lib/Target/R600/Processors.td > index 81f407e..a0735d4 100644 > --- a/lib/Target/R600/Processors.td > +++ b/lib/Target/R600/Processors.td > @@ -48,3 +48,6 @@ def : Proc<"pitcairn", SI_Itin, [FeatureSouthernIslands]>; > def : Proc<"verde", SI_Itin, [FeatureSouthernIslands]>; > def : Proc<"oland", SI_Itin, [FeatureSouthernIslands]>; > def : Proc<"hainan", SI_Itin, [FeatureSouthernIslands]>; > +def : Proc<"bonaire",SI_Itin, [FeatureSouthernIslands]>; > +def : Proc<"kabini", SI_Itin, [FeatureSouthernIslands]>; > +def : Proc<"kaveri", SI_Itin, [FeatureSouthernIslands]>; > \ No newline at end of file > -- > 1.7.7.5 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Eliminating unused built-in varyings
On 06/28/2013 10:55 AM, Marek Olšák wrote: On Fri, Jun 28, 2013 at 5:42 PM, Ian Romanick wrote: On 06/13/2013 05:25 AM, Marek Olšák wrote: Hi everyone, this series adds a new GLSL compiler optimization pass which eliminates unused and set-but-unused built-in varyings and adds a few improvements to the GLSL linker in the process. Before I show you how it works, I wanna say that there are patches which are related to and will most probably conflict with the geometry shader work, but they are necessary because the linkage of varyings is largely suboptimal. Also, the GL_EXT_separate_shader_objects extension must be disabled for this optimization to be enabled. The reason is a program object with both a VS and FS can be bound partially, e.g. by glUseShaderProgramEXT(GL_VERTEX_SHADER, prog), so the extension makes every program object be just a set of "separate shaders". The extension is not important anyway. Could you elaborate on this a bit? The problem already exists that shader can be par-linked (e.g., just a vertex shader) and used with fixed-function. A big part of the reason that I implemented EXT_sso back in the day was to generate infrastructure, etc. for better using shaders with fixed function. The only problem I have with EXT_sso is that you can link two programs, both having a vertex and fragment shader, and still mix-and-match their shaders independently as if all the shaders were separate/unlinked. For example: Oh, I had forgotten all about that. I remember thinking the spec authors must have been drunk when they didn't add language to prevent that usage. That makes perfect sense, then. It sounds like I should get off my butt, land Gergory Hainaut's ARB_sso work, and gut out EXT_sso. /* equivalent to glUseProgram(prog1); */ glUseShaderProgramEXT(GL_VERTEX_SHADER, prog1); glUseShaderProgramEXT(GL_FRAGMENT_SHADER, prog1); /* prog1 has its own fragment shader, but who cares! we don't have to bind it */ /* prog2 also has its own vertex shader */ glUseShaderProgramEXT(GL_VERTEX_SHADER, prog1); glUseShaderProgramEXT(GL_FRAGMENT_SHADER, prog2); /* more fun, we can put a geometry shader in between */ glUseShaderProgramEXT(GL_VERTEX_SHADER, prog1); glUseShaderProgramEXT(GL_GEOMETRY_SHADER, prog3); glUseShaderProgramEXT(GL_FRAGMENT_SHADER, prog1); /* assume prog3 has all 3 shaders, we can unbind the middle one */ glUseProgram(prog3); glUseShaderProgramEXT(GL_GEOMETRY_SHADER, NULL); I have no problem with linking program objects with a single shader and mixing and matching such program objects. However the ability to mix-and-match shaders no matter what program object they are part of is a real show-stopper for this optimization. Thankfully, this doesn't happen with fixed function and ARB_sso also forbids such usage. Now, to illustrate how the optimization works, consider these 2 shader IR dumps: Vertex shader (8 varyings): ... (declare (shader_out ) vec4 gl_FrontColor) (declare (shader_out ) vec4 gl_FrontSecondaryColor) (declare (shader_out ) (array vec4 6) gl_TexCoord) (function main (signature void (parameters ) ( ... (assign (xyzw) (var_ref gl_FrontColor) (var_ref gl_Color) ) (assign (xyzw) (var_ref gl_FrontSecondaryColor) (var_ref gl_SecondaryColor) ) (assign (xyzw) (array_ref (var_ref gl_TexCoord) (constant int (1)) ) (var_ref gl_MultiTexCoord1) ) (assign (xyzw) (array_ref (var_ref gl_TexCoord) (constant int (4)) ) (var_ref gl_MultiTexCoord4) ) (assign (xyzw) (array_ref (var_ref gl_TexCoord) (constant int (5)) ) (var_ref gl_MultiTexCoord5) ) )) ) Fragment shader (6 varyings): ... (declare (shader_in ) vec4 gl_SecondaryColor) (declare (shader_in ) (array vec4 5) gl_TexCoord) (function main (signature void (parameters ) ( (declare () vec4 r) (assign (xyzw) (var_ref r) ... (var_ref gl_SecondaryColor) ) ) (assign (xyzw) (var_ref r) ... (array_ref (var_ref gl_TexCoord) (constant int (1)) ) ) ) ) (assign (xyzw) (var_ref r) ... (array_ref (var_ref gl_TexCoord) (constant int (2)) ) ) ) ) (assign (xyzw) (var_ref r) ... (array_ref (var_ref gl_TexCoord) (constant int (3)) ) ) ) ) (declare (temporary ) vec4 assignment_tmp) (assign (xyzw) (var_ref assignment_tmp) ... (array_ref (var_ref gl_TexCoord) (constant int (4)) ) ) ) ) ... )) ) Note that only gl_TexCoord[1], gl_TexCoord[4], and gl_SecondaryColor are used by both shaders. The optimization replaces all occurences of varyings which are unused by the other stage by temporary variables. It also breaks down the gl_TexCoord array into separate vec4 variables if needed. Here's the result: This sounds similar to the way Paul's varying packing works. Is there synergy there? Also, since variables are renamed, does this interact with transform feedback? The queries of GL_ARB_program_interface_query? I suspect that it won't since this only affec
Re: [Mesa-dev] [PATCH] llvmpipe: fix timer query if there's no bins
Looks good.
- Original Message -
> From: Roland Scheidegger
>
> b04a295a4a0cd2defe352b3193b5fa79ca8fc9fc removed seemingly unnecessary
> code in get_query. Turns out this code could in fact be reached - while
> timestamps are always binned, if there are no bins (which happens if fb
> size is 0) then the rasterization query code filling this in is still
> never executed.
> So fix this up by filling in some timestamp, but do it at EndQuery time
> not GetQuery time which should be more appropriate.
> Makes piglit arb_timer_query-timestamp-get happy again.
> ---
> src/gallium/drivers/llvmpipe/lp_setup.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
> b/src/gallium/drivers/llvmpipe/lp_setup.c
> index 49b61c3..65f61ed 100644
> --- a/src/gallium/drivers/llvmpipe/lp_setup.c
> +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
> @@ -40,6 +40,7 @@
> #include "util/u_memory.h"
> #include "util/u_pack_color.h"
> #include "draw/draw_pipe.h"
> +#include "os/os_time.h"
> #include "lp_context.h"
> #include "lp_memory.h"
> #include "lp_scene.h"
> @@ -1263,6 +1264,15 @@ lp_setup_end_query(struct lp_setup_context *setup,
> struct llvmpipe_query *pq)
>pq->type == PIPE_QUERY_OCCLUSION_PREDICATE ||
>pq->type == PIPE_QUERY_PIPELINE_STATISTICS ||
>pq->type == PIPE_QUERY_TIMESTAMP) {
> + if (pq->type == PIPE_QUERY_TIMESTAMP &&
> + !(setup->scene->tiles_x | setup->scene->tiles_y)) {
> +/*
> + * If there's a zero width/height framebuffer, there's no bins
> and
> + * hence no rast task is ever run. So fill in something here
> instead.
> + */
> +pq->end[0] = os_time_get_nano();
> + }
> +
> if (!lp_scene_bin_everywhere(setup->scene,
>LP_RAST_OP_END_QUERY,
>lp_rast_arg_query(pq))) {
> --
> 1.7.9.5
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] R600/SI: Add processor types for each CIK variant
From: Alex Deucher Signed-off-by: Alex Deucher --- lib/Target/R600/Processors.td |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/lib/Target/R600/Processors.td b/lib/Target/R600/Processors.td index 81f407e..a0735d4 100644 --- a/lib/Target/R600/Processors.td +++ b/lib/Target/R600/Processors.td @@ -48,3 +48,6 @@ def : Proc<"pitcairn", SI_Itin, [FeatureSouthernIslands]>; def : Proc<"verde", SI_Itin, [FeatureSouthernIslands]>; def : Proc<"oland", SI_Itin, [FeatureSouthernIslands]>; def : Proc<"hainan", SI_Itin, [FeatureSouthernIslands]>; +def : Proc<"bonaire",SI_Itin, [FeatureSouthernIslands]>; +def : Proc<"kabini", SI_Itin, [FeatureSouthernIslands]>; +def : Proc<"kaveri", SI_Itin, [FeatureSouthernIslands]>; \ No newline at end of file -- 1.7.7.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] prog_parameter.c ASAN Patch
Friendly ping regarding this patch :-)
--Myles
On Wed, Jun 19, 2013 at 12:47 AM, Myles C. Maxfield <
myles.maxfi...@gmail.com> wrote:
> Any word on this?
>
> Thanks,
> Myles
>
>
> On Mon, Jun 17, 2013 at 12:09 PM, Myles C. Maxfield <
> myles.maxfi...@gmail.com> wrote:
>
>> Sure. I was under the impression that |size| couldn't be both greater
>> than 4 and a non-multiple of 4, but I've reworked the patch to incorporate
>> this and to be a little more straightforward.
>>
>> Is the only way to replace "ASAN" with "Address Sanitizer" to change the
>> subject of this email thread?
>>
>> Anyway, here's a similar but modified patch:
>>
>> From: Myles C. Maxfield
>> Date: Mon, 17 Jun 2013 11:50:05 -0700
>> Subject: [PATCH] Appeasing Address Sanitizer
>>
>> ---
>> src/mesa/program/prog_parameter.c | 13 -
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/program/prog_parameter.c
>> b/src/mesa/program/prog_parameter.c
>> index 95b153e..1d46476 100644
>> --- a/src/mesa/program/prog_parameter.c
>> +++ b/src/mesa/program/prog_parameter.c
>> @@ -155,7 +155,18 @@ _mesa_add_parameter(struct gl_program_parameter_list
>> *paramList,
>> p->Size = size;
>> p->DataType = datatype;
>> if (values) {
>> -COPY_4V(paramList->ParameterValues[oldNum + i], values);
>> +if (size >= (i+1)*4) {
>> +COPY_4V(paramList->ParameterValues[oldNum + i], values);
>> +} else {
>> +/* silence asan */
>> +for (j = 0; j < 4; j++) {
>> +if (i*4+j < size) {
>> +paramList->ParameterValues[oldNum + i][j] =
>> values[i*4+j];
>> +} else {
>> +paramList->ParameterValues[oldNum + i][j].f =
>> 0.0f;
>> +}
>> +}
>> +}
>> values += 4;
>> p->Initialized = GL_TRUE;
>> }
>> --
>> 1.7.12.4 (Apple Git-37)
>>
>>
>> On Mon, Jun 17, 2013 at 8:13 AM, Brian Paul wrote:
>>
>>> On 06/14/2013 05:12 PM, Myles C. Maxfield wrote:
>>>
Sorry for the triple post; I received a bounce email the first time and
got sent to the spam folder the second time, so I'm trying a third time.
Hello, all. I was running Mesa with Address Sanitizer [1] turned on,
and found one place where ASAN pointed out a read-before-initialized
problem. In particular, in _mesa_add_parameter, in prog_parameter.c,
|values| represents an array holding a variable number of values. These
values get copied out of the array 4 at a time with the COPY_4V macro,
however, the array might only contain a single element. In this case, ASAN
reports a read-before-initialize because the last 3 of the 4 elements
haven't been written to yet. I was hoping to contribute a patch that will
silence this problem that ASAN reports. I'm happy to incorporate any
feedback anyone has into this patch.
Thanks,
Myles C. Maxfield
[1]https://code.google.com/p/**address-sanitizer/
Re: [Mesa-dev] [PATCH v2] r600g: implement fast color clears on evergreen+
On 12.06.2013 00:04, Grigori Goronzy wrote: Allows MSAA colorbuffers, which have a CMASK automatically and don't need any further special handling, to be fast cleared. Instead of clearing the buffer, set the clear color and the CMASK to the cleared state. Fast clear is used only when all bound colorbuffers fulfill certain conditions: a CMASK is required, we have to be able to create a clear color value for the format and the texture mustn't contain multiple images. Technically, it should be possible to support array textures and cubemaps if all images are attached to the framebuffer, but this does not appear to be common. v2: fix fast clear check Ping? Can anyone please review this? Best regards Grigori ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Eliminating unused built-in varyings
On Fri, Jun 28, 2013 at 5:42 PM, Ian Romanick wrote: > On 06/13/2013 05:25 AM, Marek Olšák wrote: >> >> Hi everyone, >> >> this series adds a new GLSL compiler optimization pass which eliminates >> unused and set-but-unused built-in varyings and adds a few improvements to >> the GLSL linker in the process. >> >> Before I show you how it works, I wanna say that there are patches which >> are related to and will most probably conflict with the geometry shader >> work, but they are necessary because the linkage of varyings is largely >> suboptimal. >> >> Also, the GL_EXT_separate_shader_objects extension must be disabled >> for this optimization to be enabled. The reason is a program object with >> both a VS and FS can be bound partially, e.g. by >> glUseShaderProgramEXT(GL_VERTEX_SHADER, prog), so the extension makes >> every program object be just a set of "separate shaders". The extension >> is not important anyway. > > > Could you elaborate on this a bit? The problem already exists that shader > can be par-linked (e.g., just a vertex shader) and used with fixed-function. > A big part of the reason that I implemented EXT_sso back in the day was to > generate infrastructure, etc. for better using shaders with fixed function. The only problem I have with EXT_sso is that you can link two programs, both having a vertex and fragment shader, and still mix-and-match their shaders independently as if all the shaders were separate/unlinked. For example: /* equivalent to glUseProgram(prog1); */ glUseShaderProgramEXT(GL_VERTEX_SHADER, prog1); glUseShaderProgramEXT(GL_FRAGMENT_SHADER, prog1); /* prog1 has its own fragment shader, but who cares! we don't have to bind it */ /* prog2 also has its own vertex shader */ glUseShaderProgramEXT(GL_VERTEX_SHADER, prog1); glUseShaderProgramEXT(GL_FRAGMENT_SHADER, prog2); /* more fun, we can put a geometry shader in between */ glUseShaderProgramEXT(GL_VERTEX_SHADER, prog1); glUseShaderProgramEXT(GL_GEOMETRY_SHADER, prog3); glUseShaderProgramEXT(GL_FRAGMENT_SHADER, prog1); /* assume prog3 has all 3 shaders, we can unbind the middle one */ glUseProgram(prog3); glUseShaderProgramEXT(GL_GEOMETRY_SHADER, NULL); I have no problem with linking program objects with a single shader and mixing and matching such program objects. However the ability to mix-and-match shaders no matter what program object they are part of is a real show-stopper for this optimization. Thankfully, this doesn't happen with fixed function and ARB_sso also forbids such usage. > > >> Now, to illustrate how the optimization works, consider these 2 shader IR >> dumps: >> >> >> Vertex shader (8 varyings): >> ... >> (declare (shader_out ) vec4 gl_FrontColor) >> (declare (shader_out ) vec4 gl_FrontSecondaryColor) >> (declare (shader_out ) (array vec4 6) gl_TexCoord) >> (function main >>(signature void >> (parameters >> ) >> ( >>... >>(assign (xyzw) (var_ref gl_FrontColor) (var_ref gl_Color) ) >>(assign (xyzw) (var_ref gl_FrontSecondaryColor) (var_ref >> gl_SecondaryColor) ) >>(assign (xyzw) (array_ref (var_ref gl_TexCoord) (constant int (1)) >> ) (var_ref gl_MultiTexCoord1) ) >>(assign (xyzw) (array_ref (var_ref gl_TexCoord) (constant int (4)) >> ) (var_ref gl_MultiTexCoord4) ) >>(assign (xyzw) (array_ref (var_ref gl_TexCoord) (constant int (5)) >> ) (var_ref gl_MultiTexCoord5) ) >> )) >> ) >> >> Fragment shader (6 varyings): >> ... >> (declare (shader_in ) vec4 gl_SecondaryColor) >> (declare (shader_in ) (array vec4 5) gl_TexCoord) >> (function main >>(signature void >> (parameters >> ) >> ( >>(declare () vec4 r) >>(assign (xyzw) (var_ref r) ... (var_ref gl_SecondaryColor) ) ) >>(assign (xyzw) (var_ref r) ... (array_ref (var_ref gl_TexCoord) >> (constant int (1)) ) ) ) ) >>(assign (xyzw) (var_ref r) ... (array_ref (var_ref gl_TexCoord) >> (constant int (2)) ) ) ) ) >>(assign (xyzw) (var_ref r) ... (array_ref (var_ref gl_TexCoord) >> (constant int (3)) ) ) ) ) >>(declare (temporary ) vec4 assignment_tmp) >>(assign (xyzw) (var_ref assignment_tmp) ... (array_ref (var_ref >> gl_TexCoord) (constant int (4)) ) ) ) ) >>... >> )) >> ) >> >> >> Note that only gl_TexCoord[1], gl_TexCoord[4], and gl_SecondaryColor >> are used by both shaders. The optimization replaces all occurences of >> varyings which are unused by the other stage by temporary variables. It >> also breaks down the gl_TexCoord array into separate vec4 variables if >> needed. Here's the result: > > > This sounds similar to the way Paul's varying packing works. Is there > synergy there? Also, since variables are renamed, does this interact with > transform feedback? The queries of GL_ARB_program_interface_query? I > suspect that it won't since this only affects built-in varyings, and > built-in varyings aren't usable with those interfaces. I haven't followed the varying pac
[Mesa-dev] [Bug 66149] [HSW] Background of application icon has garbage after update kernel&mesa in order to support Graphics [8086: 0a2e]
https://bugs.freedesktop.org/show_bug.cgi?id=66149 --- Comment #7 from Ian Romanick --- Eva, can you clarify for me. 9.1 works correctly, but master does not? If the bug still exists on master, the bug should not be closed. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] glsl/linker: eliminate unused and set-but-unused built-in varyings
On 06/13/2013 05:25 AM, Marek Olšák wrote:
This eliminates built-in varyings such as gl_Color, gl_SecondaryColor,
gl_TexCoord, and gl_FogFragCoord if they are unused by the next stage or
not written at all (e.g. gl_TexCoord elements). The gl_TexCoord array is
broken down into separate vec4s if needed.
---
src/glsl/Makefile.sources |1 +
src/glsl/ir_optimization.h |4 +
src/glsl/link_varyings.h |4 +
src/glsl/linker.cpp| 13 +-
src/glsl/opt_dead_builtin_varyings.cpp | 468
5 files changed, 488 insertions(+), 2 deletions(-)
create mode 100644 src/glsl/opt_dead_builtin_varyings.cpp
diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
index 50bad85..cb17cf8 100644
--- a/src/glsl/Makefile.sources
+++ b/src/glsl/Makefile.sources
@@ -81,6 +81,7 @@ LIBGLSL_FILES = \
$(GLSL_SRCDIR)/opt_constant_variable.cpp \
$(GLSL_SRCDIR)/opt_copy_propagation.cpp \
$(GLSL_SRCDIR)/opt_copy_propagation_elements.cpp \
+ $(GLSL_SRCDIR)/opt_dead_builtin_varyings.cpp \
$(GLSL_SRCDIR)/opt_dead_code.cpp \
$(GLSL_SRCDIR)/opt_dead_code_local.cpp \
$(GLSL_SRCDIR)/opt_dead_functions.cpp \
diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
index d38d5e3..fad6f1b 100644
--- a/src/glsl/ir_optimization.h
+++ b/src/glsl/ir_optimization.h
@@ -76,6 +76,10 @@ bool do_constant_variable_unlinked(exec_list *instructions);
bool do_copy_propagation(exec_list *instructions);
bool do_copy_propagation_elements(exec_list *instructions);
bool do_constant_propagation(exec_list *instructions);
+void do_dead_builtin_varyings(struct gl_context *ctx,
+ exec_list *producer, exec_list *consumer,
+ unsigned num_tfeedback_decls,
+ class tfeedback_decl *tfeedback_decls);
bool do_dead_code(exec_list *instructions, bool uniform_locations_assigned);
bool do_dead_code_local(exec_list *instructions);
bool do_dead_code_unlinked(exec_list *instructions);
diff --git a/src/glsl/link_varyings.h b/src/glsl/link_varyings.h
index daa9d79..7f7be35 100644
--- a/src/glsl/link_varyings.h
+++ b/src/glsl/link_varyings.h
@@ -125,6 +125,10 @@ public:
return this->vector_elements * this->matrix_columns * this->size;
}
+ unsigned get_location() const {
+ return this->location;
+ }
+
private:
/**
* The name that was supplied to glTransformFeedbackVaryings. Used for
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index a8537cf..129b665 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1887,6 +1887,9 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
goto done;
}
+ do_dead_builtin_varyings(ctx, sh->ir, NULL,
+ num_tfeedback_decls, tfeedback_decls);
+
demote_shader_inputs_and_outputs(sh, ir_var_shader_out);
/* Eliminate code that is now dead due to unused outputs being demoted.
@@ -1895,11 +1898,13 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
;
}
else if (first == MESA_SHADER_FRAGMENT) {
- /* If the program only contains a fragment shader, just demote
- * user-defined varyings.
+ /* If the program only contains a fragment shader...
*/
gl_shader *const sh = prog->_LinkedShaders[first];
+ do_dead_builtin_varyings(ctx, NULL, sh->ir,
+ num_tfeedback_decls, tfeedback_decls);
+
demote_shader_inputs_and_outputs(sh, ir_var_shader_in);
while (do_dead_code(sh->ir, false))
@@ -1919,6 +1924,10 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
tfeedback_decls))
goto done;
+ do_dead_builtin_varyings(ctx, sh_i->ir, sh_next->ir,
+next == MESA_SHADER_FRAGMENT ? num_tfeedback_decls : 0,
+tfeedback_decls);
+
demote_shader_inputs_and_outputs(sh_i, ir_var_shader_out);
demote_shader_inputs_and_outputs(sh_next, ir_var_shader_in);
diff --git a/src/glsl/opt_dead_builtin_varyings.cpp
b/src/glsl/opt_dead_builtin_varyings.cpp
new file mode 100644
index 000..eb99d1e
--- /dev/null
+++ b/src/glsl/opt_dead_builtin_varyings.cpp
@@ -0,0 +1,468 @@
+/*
+ * Copyright © 2013 Marek Olšák
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) sha
Re: [Mesa-dev] [PATCH 0/6] Eliminating unused built-in varyings
On 06/28/2013 08:42 AM, Ian Romanick wrote: On 06/13/2013 05:25 AM, Marek Olšák wrote: Hi everyone, this series adds a new GLSL compiler optimization pass which eliminates unused and set-but-unused built-in varyings and adds a few improvements to the GLSL linker in the process. Before I show you how it works, I wanna say that there are patches which are related to and will most probably conflict with the geometry shader work, but they are necessary because the linkage of varyings is largely suboptimal. Also, the GL_EXT_separate_shader_objects extension must be disabled for this optimization to be enabled. The reason is a program object with both a VS and FS can be bound partially, e.g. by glUseShaderProgramEXT(GL_VERTEX_SHADER, prog), so the extension makes every program object be just a set of "separate shaders". The extension is not important anyway. Could you elaborate on this a bit? The problem already exists that shader can be par-linked (e.g., just a vertex shader) and used with fixed-function. A big part of the reason that I implemented EXT_sso back in the day was to generate infrastructure, etc. for better using shaders with fixed function. Now, to illustrate how the optimization works, consider these 2 shader IR dumps: Vertex shader (8 varyings): ... (declare (shader_out ) vec4 gl_FrontColor) (declare (shader_out ) vec4 gl_FrontSecondaryColor) (declare (shader_out ) (array vec4 6) gl_TexCoord) (function main (signature void (parameters ) ( ... (assign (xyzw) (var_ref gl_FrontColor) (var_ref gl_Color) ) (assign (xyzw) (var_ref gl_FrontSecondaryColor) (var_ref gl_SecondaryColor) ) (assign (xyzw) (array_ref (var_ref gl_TexCoord) (constant int (1)) ) (var_ref gl_MultiTexCoord1) ) (assign (xyzw) (array_ref (var_ref gl_TexCoord) (constant int (4)) ) (var_ref gl_MultiTexCoord4) ) (assign (xyzw) (array_ref (var_ref gl_TexCoord) (constant int (5)) ) (var_ref gl_MultiTexCoord5) ) )) ) Fragment shader (6 varyings): ... (declare (shader_in ) vec4 gl_SecondaryColor) (declare (shader_in ) (array vec4 5) gl_TexCoord) (function main (signature void (parameters ) ( (declare () vec4 r) (assign (xyzw) (var_ref r) ... (var_ref gl_SecondaryColor) ) ) (assign (xyzw) (var_ref r) ... (array_ref (var_ref gl_TexCoord) (constant int (1)) ) ) ) ) (assign (xyzw) (var_ref r) ... (array_ref (var_ref gl_TexCoord) (constant int (2)) ) ) ) ) (assign (xyzw) (var_ref r) ... (array_ref (var_ref gl_TexCoord) (constant int (3)) ) ) ) ) (declare (temporary ) vec4 assignment_tmp) (assign (xyzw) (var_ref assignment_tmp) ... (array_ref (var_ref gl_TexCoord) (constant int (4)) ) ) ) ) ... )) ) Note that only gl_TexCoord[1], gl_TexCoord[4], and gl_SecondaryColor are used by both shaders. The optimization replaces all occurences of varyings which are unused by the other stage by temporary variables. It also breaks down the gl_TexCoord array into separate vec4 variables if needed. Here's the result: This sounds similar to the way Paul's varying packing works. Is there synergy there? Also, since variables are renamed, does this interact with transform feedback? The queries of GL_ARB_program_interface_query? I suspect that it won't since this only affects built-in varyings, and built-in varyings aren't usable with those interfaces. I take part of that back. You can do transform feedback on built-in varyings. I had that crossed with not being able to do XFB on the output of fixed-function. Vertex shader (3 varyings instead of 8): ... (declare (shader_out ) vec4 gl_out_TexCoord1) (declare (shader_out ) vec4 gl_out_TexCoord4) (declare (temporary ) vec4 gl_out_TexCoord5_dummy) (declare (temporary ) vec4 gl_out_FrontColor0_dummy) (declare (shader_out ) vec4 gl_FrontSecondaryColor) (function main (signature void (parameters ) ( ... (assign (xyzw) (var_ref gl_out_FrontColor0_dummy) (var_ref gl_Color) ) (assign (xyzw) (var_ref gl_FrontSecondaryColor) (var_ref gl_SecondaryColor) ) (assign (xyzw) (var_ref gl_out_TexCoord1) (var_ref gl_MultiTexCoord1) ) (assign (xyzw) (var_ref gl_out_TexCoord4) (var_ref gl_MultiTexCoord4) ) (assign (xyzw) (var_ref gl_out_TexCoord5_dummy) (var_ref gl_MultiTexCoord5) ) )) ) Fragment shader (3 varyings instead of 6): ... (declare (shader_in ) vec4 gl_in_TexCoord1) (declare (temporary ) vec4 gl_in_TexCoord2_dummy) (declare (temporary ) vec4 gl_in_TexCoord3_dummy) (declare (shader_in ) vec4 gl_in_TexCoord4) (declare (shader_in ) vec4 gl_SecondaryColor) (function main (signature void (parameters ) ( (declare () vec4 r) (assign (xyzw) (var_ref r) ... (var_ref gl_SecondaryColor) ) ) (assign (xyzw) (var_ref r) ... (var_ref gl_in_TexCoord1) ) ) ) (assign (xyzw) (var_ref r) ... (var_ref gl_in_TexCoord2_dummy) ) ) )
Re: [Mesa-dev] [PATCH 0/6] Eliminating unused built-in varyings
On 06/13/2013 05:25 AM, Marek Olšák wrote: Hi everyone, this series adds a new GLSL compiler optimization pass which eliminates unused and set-but-unused built-in varyings and adds a few improvements to the GLSL linker in the process. Before I show you how it works, I wanna say that there are patches which are related to and will most probably conflict with the geometry shader work, but they are necessary because the linkage of varyings is largely suboptimal. Also, the GL_EXT_separate_shader_objects extension must be disabled for this optimization to be enabled. The reason is a program object with both a VS and FS can be bound partially, e.g. by glUseShaderProgramEXT(GL_VERTEX_SHADER, prog), so the extension makes every program object be just a set of "separate shaders". The extension is not important anyway. Could you elaborate on this a bit? The problem already exists that shader can be par-linked (e.g., just a vertex shader) and used with fixed-function. A big part of the reason that I implemented EXT_sso back in the day was to generate infrastructure, etc. for better using shaders with fixed function. Now, to illustrate how the optimization works, consider these 2 shader IR dumps: Vertex shader (8 varyings): ... (declare (shader_out ) vec4 gl_FrontColor) (declare (shader_out ) vec4 gl_FrontSecondaryColor) (declare (shader_out ) (array vec4 6) gl_TexCoord) (function main (signature void (parameters ) ( ... (assign (xyzw) (var_ref gl_FrontColor) (var_ref gl_Color) ) (assign (xyzw) (var_ref gl_FrontSecondaryColor) (var_ref gl_SecondaryColor) ) (assign (xyzw) (array_ref (var_ref gl_TexCoord) (constant int (1)) ) (var_ref gl_MultiTexCoord1) ) (assign (xyzw) (array_ref (var_ref gl_TexCoord) (constant int (4)) ) (var_ref gl_MultiTexCoord4) ) (assign (xyzw) (array_ref (var_ref gl_TexCoord) (constant int (5)) ) (var_ref gl_MultiTexCoord5) ) )) ) Fragment shader (6 varyings): ... (declare (shader_in ) vec4 gl_SecondaryColor) (declare (shader_in ) (array vec4 5) gl_TexCoord) (function main (signature void (parameters ) ( (declare () vec4 r) (assign (xyzw) (var_ref r) ... (var_ref gl_SecondaryColor) ) ) (assign (xyzw) (var_ref r) ... (array_ref (var_ref gl_TexCoord) (constant int (1)) ) ) ) ) (assign (xyzw) (var_ref r) ... (array_ref (var_ref gl_TexCoord) (constant int (2)) ) ) ) ) (assign (xyzw) (var_ref r) ... (array_ref (var_ref gl_TexCoord) (constant int (3)) ) ) ) ) (declare (temporary ) vec4 assignment_tmp) (assign (xyzw) (var_ref assignment_tmp) ... (array_ref (var_ref gl_TexCoord) (constant int (4)) ) ) ) ) ... )) ) Note that only gl_TexCoord[1], gl_TexCoord[4], and gl_SecondaryColor are used by both shaders. The optimization replaces all occurences of varyings which are unused by the other stage by temporary variables. It also breaks down the gl_TexCoord array into separate vec4 variables if needed. Here's the result: This sounds similar to the way Paul's varying packing works. Is there synergy there? Also, since variables are renamed, does this interact with transform feedback? The queries of GL_ARB_program_interface_query? I suspect that it won't since this only affects built-in varyings, and built-in varyings aren't usable with those interfaces. Vertex shader (3 varyings instead of 8): ... (declare (shader_out ) vec4 gl_out_TexCoord1) (declare (shader_out ) vec4 gl_out_TexCoord4) (declare (temporary ) vec4 gl_out_TexCoord5_dummy) (declare (temporary ) vec4 gl_out_FrontColor0_dummy) (declare (shader_out ) vec4 gl_FrontSecondaryColor) (function main (signature void (parameters ) ( ... (assign (xyzw) (var_ref gl_out_FrontColor0_dummy) (var_ref gl_Color) ) (assign (xyzw) (var_ref gl_FrontSecondaryColor) (var_ref gl_SecondaryColor) ) (assign (xyzw) (var_ref gl_out_TexCoord1) (var_ref gl_MultiTexCoord1) ) (assign (xyzw) (var_ref gl_out_TexCoord4) (var_ref gl_MultiTexCoord4) ) (assign (xyzw) (var_ref gl_out_TexCoord5_dummy) (var_ref gl_MultiTexCoord5) ) )) ) Fragment shader (3 varyings instead of 6): ... (declare (shader_in ) vec4 gl_in_TexCoord1) (declare (temporary ) vec4 gl_in_TexCoord2_dummy) (declare (temporary ) vec4 gl_in_TexCoord3_dummy) (declare (shader_in ) vec4 gl_in_TexCoord4) (declare (shader_in ) vec4 gl_SecondaryColor) (function main (signature void (parameters ) ( (declare () vec4 r) (assign (xyzw) (var_ref r) ... (var_ref gl_SecondaryColor) ) ) (assign (xyzw) (var_ref r) ... (var_ref gl_in_TexCoord1) ) ) ) (assign (xyzw) (var_ref r) ... (var_ref gl_in_TexCoord2_dummy) ) ) ) (assign (xyzw) (var_ref r) ... (var_ref gl_in_TexCoord3_dummy) ) ) ) (declare (temporary ) vec4 assignment_tmp) (assign (xyzw) (var_ref assignment_tmp) ... (var_re
Re: [Mesa-dev] [PATCH] clover: Fix build with LLVM 3.4
Disregard this patch... Looks like Tom already pushed a fix last night.
--Aaron
On Fri, Jun 28, 2013 at 9:41 AM, Aaron Watry wrote:
> PathV1.h has been removed. In theory this can go back before llvm 3.4, but I
> haven't done the research to find out how far back.
>
> Signed-off-by: Aaron Watry
> ---
> src/gallium/state_trackers/clover/llvm/invocation.cpp | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 362f02f..ee0249d 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -43,7 +43,12 @@
> #include
> #include
> #include
> +#if HAVE_LLVM < 0x0304
> #include
> +#else
> +#include
> +#include
> +#endif
> #include
> #include
>
> @@ -222,9 +227,16 @@ namespace {
>
>llvm::PassManager PM;
>llvm::PassManagerBuilder Builder;
> +#if HAVE_LLVM < 0x0304
>llvm::sys::Path libclc_path =
> llvm::sys::Path(LIBCLC_LIBEXECDIR + processor +
> "-" + triple + ".bc");
> +#else
> + llvm::SmallString<1> libclc_path;
> + libclc_path = LIBCLC_LIBEXECDIR;
> + std::string file_name = processor + "-" + triple + ".bc";
> + llvm::sys::path::append(libclc_path, file_name);
> +#endif
>
>// Link the kernel with libclc
> #if HAVE_LLVM < 0x0303
> --
> 1.8.1.2
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] mesa, gallium: renumber shader indices according to their placement in pipeline
On 06/28/2013 08:53 AM, Jose Fonseca wrote:
- Original Message -
See my explanation in mtypes.h.
---
src/gallium/include/pipe/p_defines.h |7 ---
src/glsl/linker.cpp| 16
src/mesa/drivers/dri/i965/brw_shader.cpp |8 ++--
src/mesa/main/mtypes.h |8 ++--
src/mesa/main/shaderobj.h |4 ++--
src/mesa/main/uniform_query.cpp|2 +-
src/mesa/program/ir_to_mesa.cpp| 10 +++---
src/mesa/program/program.h |2 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 10 +++---
9 files changed, 30 insertions(+), 37 deletions(-)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 8af1a84..216cd2f 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -352,11 +352,12 @@ enum pipe_flush_flags {
/**
- * Shaders
+ * Shaders.
+ * These must have the same values as Mesa's MESA_SHADER_*.
Sorry for not noticing this earlier -- I haven't been able to keep up with
email traffic lately.
I'm afraid I can't agree with this. Gallium needs to be API agnostic -- it
doesn't make sense to have gallium go at the whims of particular state tracker
implementation details.
There is a lot of code out there that relies on this ordering. And
unfortunately reordering will cause it to fail, often in a silent manner (with
no compiler errors or warnings).
- Original Message -
The renumbering only makes sense for the GLSL linker and the only
reason for doing that in gallium too is that PIPE_SHADER_x must be
equal to MESA_SHADER_x.
This is an implementation detail.
PIPE_SHADER_x may have been paired with MESA_SHADER_x till now as convenience,
but now they are what they are.
I took a quick look at the state tracker. AFAICT, there's only one
place where we obviously depend on MESA_SHADER_x == PIPE_SHADER_x, at
st_extensions.c:152
The st_atom_shader/constbuf, etc. code looks OK.
I think we could remove the MESA_SHADER_x == PIPE_SHADER_x assumption
without too much trouble.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] llvmpipe: fix timer query if there's no bins
From: Roland Scheidegger
b04a295a4a0cd2defe352b3193b5fa79ca8fc9fc removed seemingly unnecessary
code in get_query. Turns out this code could in fact be reached - while
timestamps are always binned, if there are no bins (which happens if fb
size is 0) then the rasterization query code filling this in is still
never executed.
So fix this up by filling in some timestamp, but do it at EndQuery time
not GetQuery time which should be more appropriate.
Makes piglit arb_timer_query-timestamp-get happy again.
---
src/gallium/drivers/llvmpipe/lp_setup.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
b/src/gallium/drivers/llvmpipe/lp_setup.c
index 49b61c3..65f61ed 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup.c
@@ -40,6 +40,7 @@
#include "util/u_memory.h"
#include "util/u_pack_color.h"
#include "draw/draw_pipe.h"
+#include "os/os_time.h"
#include "lp_context.h"
#include "lp_memory.h"
#include "lp_scene.h"
@@ -1263,6 +1264,15 @@ lp_setup_end_query(struct lp_setup_context *setup,
struct llvmpipe_query *pq)
pq->type == PIPE_QUERY_OCCLUSION_PREDICATE ||
pq->type == PIPE_QUERY_PIPELINE_STATISTICS ||
pq->type == PIPE_QUERY_TIMESTAMP) {
+ if (pq->type == PIPE_QUERY_TIMESTAMP &&
+ !(setup->scene->tiles_x | setup->scene->tiles_y)) {
+/*
+ * If there's a zero width/height framebuffer, there's no bins and
+ * hence no rast task is ever run. So fill in something here
instead.
+ */
+pq->end[0] = os_time_get_nano();
+ }
+
if (!lp_scene_bin_everywhere(setup->scene,
LP_RAST_OP_END_QUERY,
lp_rast_arg_query(pq))) {
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] mesa, gallium: renumber shader indices according to their placement in pipeline
- Original Message -
> See my explanation in mtypes.h.
> ---
> src/gallium/include/pipe/p_defines.h |7 ---
> src/glsl/linker.cpp| 16
> src/mesa/drivers/dri/i965/brw_shader.cpp |8 ++--
> src/mesa/main/mtypes.h |8 ++--
> src/mesa/main/shaderobj.h |4 ++--
> src/mesa/main/uniform_query.cpp|2 +-
> src/mesa/program/ir_to_mesa.cpp| 10 +++---
> src/mesa/program/program.h |2 +-
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 10 +++---
> 9 files changed, 30 insertions(+), 37 deletions(-)
>
> diff --git a/src/gallium/include/pipe/p_defines.h
> b/src/gallium/include/pipe/p_defines.h
> index 8af1a84..216cd2f 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -352,11 +352,12 @@ enum pipe_flush_flags {
>
>
> /**
> - * Shaders
> + * Shaders.
> + * These must have the same values as Mesa's MESA_SHADER_*.
Sorry for not noticing this earlier -- I haven't been able to keep up with
email traffic lately.
I'm afraid I can't agree with this. Gallium needs to be API agnostic -- it
doesn't make sense to have gallium go at the whims of particular state tracker
implementation details.
There is a lot of code out there that relies on this ordering. And
unfortunately reordering will cause it to fail, often in a silent manner (with
no compiler errors or warnings).
- Original Message -
> The renumbering only makes sense for the GLSL linker and the only
> reason for doing that in gallium too is that PIPE_SHADER_x must be
> equal to MESA_SHADER_x.
This is an implementation detail.
PIPE_SHADER_x may have been paired with MESA_SHADER_x till now as convenience,
but now they are what they are.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66029] More robust way of detecting LLVM major and minor versions
https://bugs.freedesktop.org/show_bug.cgi?id=66029 --- Comment #4 from Klemens Baum --- Sent: http://lists.freedesktop.org/archives/mesa-dev/2013-June/041160.html -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] svga: use switch statement in svga_shader_type()
The renumbering only makes sense for the GLSL linker and the only
reason for doing that in gallium too is that PIPE_SHADER_x must be
equal to MESA_SHADER_x.
Marek
On Fri, Jun 28, 2013 at 4:32 PM, Jose Fonseca wrote:
>
>
> - Original Message -
>> Safer in case the PIPE_SHADER_x tokens get renumbered (as Marek
>> wanted to do).
>
> Renumbering PIPE_SHADER_x seems a pure time waster -- there is much more code
> that expects the current order -- and I see no benefit.
>
> This patch looks good nevertheles.
>> ---
>> src/gallium/drivers/svga/svga_state_constants.c | 15 ++-
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/gallium/drivers/svga/svga_state_constants.c
>> b/src/gallium/drivers/svga/svga_state_constants.c
>> index 77c9349..1c0edb4 100644
>> --- a/src/gallium/drivers/svga/svga_state_constants.c
>> +++ b/src/gallium/drivers/svga/svga_state_constants.c
>> @@ -46,13 +46,18 @@
>> /**
>> * Convert from PIPE_SHADER_* to SVGA3D_SHADERTYPE_*
>> */
>> -static int
>> +static unsigned
>> svga_shader_type(unsigned shader)
>> {
>> - assert(PIPE_SHADER_VERTEX + 1 == SVGA3D_SHADERTYPE_VS);
>> - assert(PIPE_SHADER_FRAGMENT + 1 == SVGA3D_SHADERTYPE_PS);
>> - assert(shader <= PIPE_SHADER_FRAGMENT);
>> - return shader + 1;
>> + switch (shader) {
>> + case PIPE_SHADER_VERTEX:
>> + return SVGA3D_SHADERTYPE_VS;
>> + case PIPE_SHADER_FRAGMENT:
>> + return SVGA3D_SHADERTYPE_PS;
>> + default:
>> + assert(!"Unexpected shader type");
>> + return SVGA3D_SHADERTYPE_VS;
>> + }
>> }
>>
>>
>> --
>> 1.7.10.4
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] clover: Fix build with LLVM 3.4
PathV1.h has been removed. In theory this can go back before llvm 3.4, but I
haven't done the research to find out how far back.
Signed-off-by: Aaron Watry
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 362f02f..ee0249d 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -43,7 +43,12 @@
#include
#include
#include
+#if HAVE_LLVM < 0x0304
#include
+#else
+#include
+#include
+#endif
#include
#include
@@ -222,9 +227,16 @@ namespace {
llvm::PassManager PM;
llvm::PassManagerBuilder Builder;
+#if HAVE_LLVM < 0x0304
llvm::sys::Path libclc_path =
llvm::sys::Path(LIBCLC_LIBEXECDIR + processor +
"-" + triple + ".bc");
+#else
+ llvm::SmallString<1> libclc_path;
+ libclc_path = LIBCLC_LIBEXECDIR;
+ std::string file_name = processor + "-" + triple + ".bc";
+ llvm::sys::path::append(libclc_path, file_name);
+#endif
// Link the kernel with libclc
#if HAVE_LLVM < 0x0303
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] svga: pass svga_compile_key by reference instead of value
Looks good to me
- Original Message -
> ---
> src/gallium/drivers/svga/svga_tgsi.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/drivers/svga/svga_tgsi.c
> b/src/gallium/drivers/svga/svga_tgsi.c
> index 56529c6..29fbe84 100644
> --- a/src/gallium/drivers/svga/svga_tgsi.c
> +++ b/src/gallium/drivers/svga/svga_tgsi.c
> @@ -266,7 +266,7 @@ svga_remap_generic_index(int8_t
> remap_table[MAX_GENERIC_VARYING],
> */
> static struct svga_shader_result *
> svga_tgsi_translate(const struct svga_shader *shader,
> -struct svga_compile_key key, unsigned unit)
> +const struct svga_compile_key *key, unsigned unit)
> {
> struct svga_shader_result *result = NULL;
> struct svga_shader_emitter emit;
> @@ -281,17 +281,17 @@ svga_tgsi_translate(const struct svga_shader *shader,
>
> emit.ptr = emit.buf;
> emit.unit = unit;
> - emit.key = key;
> + emit.key = *key;
>
> tgsi_scan_shader(shader->tokens, &emit.info);
>
> emit.imm_start = emit.info.file_max[TGSI_FILE_CONSTANT] + 1;
>
> if (unit == PIPE_SHADER_FRAGMENT)
> - emit.imm_start += key.fkey.num_unnormalized_coords;
> + emit.imm_start += key->fkey.num_unnormalized_coords;
>
> if (unit == PIPE_SHADER_VERTEX) {
> - emit.imm_start += key.vkey.need_prescale ? 2 : 0;
> + emit.imm_start += key->vkey.need_prescale ? 2 : 0;
> }
>
> emit.nr_hw_float_const =
> @@ -324,7 +324,7 @@ svga_tgsi_translate(const struct svga_shader *shader,
> result->shader = shader;
> result->tokens = (const unsigned *) emit.buf;
> result->nr_tokens = (emit.ptr - emit.buf) / sizeof(unsigned);
> - memcpy(&result->key, &key, sizeof key);
> + memcpy(&result->key, key, sizeof(*key));
> result->id = UTIL_BITMASK_INVALID_INDEX;
>
> if (SVGA_DEBUG & DEBUG_TGSI) {
> @@ -360,7 +360,7 @@ svga_translate_fragment_program(const struct
> svga_fragment_shader *fs,
> memcpy(key.generic_remap_table, fs->generic_remap_table,
>sizeof(fs->generic_remap_table));
>
> - return svga_tgsi_translate(&fs->base, key, PIPE_SHADER_FRAGMENT);
> + return svga_tgsi_translate(&fs->base, &key, PIPE_SHADER_FRAGMENT);
> }
>
>
> @@ -379,7 +379,7 @@ svga_translate_vertex_program(const struct
> svga_vertex_shader *vs,
> */
> svga_remap_generics(vkey->fs_generic_inputs, key.generic_remap_table);
>
> - return svga_tgsi_translate(&vs->base, key, PIPE_SHADER_VERTEX);
> + return svga_tgsi_translate(&vs->base, &key, PIPE_SHADER_VERTEX);
> }
>
>
> --
> 1.7.10.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] svga: use switch statement in svga_shader_type()
- Original Message -
> Safer in case the PIPE_SHADER_x tokens get renumbered (as Marek
> wanted to do).
Renumbering PIPE_SHADER_x seems a pure time waster -- there is much more code
that expects the current order -- and I see no benefit.
This patch looks good nevertheles.
> ---
> src/gallium/drivers/svga/svga_state_constants.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/svga/svga_state_constants.c
> b/src/gallium/drivers/svga/svga_state_constants.c
> index 77c9349..1c0edb4 100644
> --- a/src/gallium/drivers/svga/svga_state_constants.c
> +++ b/src/gallium/drivers/svga/svga_state_constants.c
> @@ -46,13 +46,18 @@
> /**
> * Convert from PIPE_SHADER_* to SVGA3D_SHADERTYPE_*
> */
> -static int
> +static unsigned
> svga_shader_type(unsigned shader)
> {
> - assert(PIPE_SHADER_VERTEX + 1 == SVGA3D_SHADERTYPE_VS);
> - assert(PIPE_SHADER_FRAGMENT + 1 == SVGA3D_SHADERTYPE_PS);
> - assert(shader <= PIPE_SHADER_FRAGMENT);
> - return shader + 1;
> + switch (shader) {
> + case PIPE_SHADER_VERTEX:
> + return SVGA3D_SHADERTYPE_VS;
> + case PIPE_SHADER_FRAGMENT:
> + return SVGA3D_SHADERTYPE_PS;
> + default:
> + assert(!"Unexpected shader type");
> + return SVGA3D_SHADERTYPE_VS;
> + }
> }
>
>
> --
> 1.7.10.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/21] i915: Remove GEN >= 4 extension support
On 06/28/2013 02:31 AM, Kenneth Graunke wrote: On 06/27/2013 06:20 PM, Ian Romanick wrote: From: Ian Romanick This copy of the source file is only used for GEN <= 3, so remove the dead code. Signed-off-by: Ian Romanick --- src/mesa/drivers/dri/i915/intel_extensions.c | 79 ++-- 1 file changed, 3 insertions(+), 76 deletions(-) This series looks good to me! Unfortunately, both you and Eric removed the gen checks from the i915/i965 extensions lists, so there were some conflicts. Yours looks a bit cleaner, so I created a new branch which is master + your series + anholt's series. It's 59 commits, and available as the 'fork-i915' branch of my tree: http://cgit.freedesktop.org/~kwg/mesa/log/?h=fork-i915 I also incorporated my feedback on patch 20, so I'd appreciate an ack if you believe that's right/wrong. Unless there are any objections, I hope to push it soon. If you incorporate Brian's suggestion on 19 and Andreas' suggestion on 12, that sounds great. :) --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH][V2] build: fix out-of-tree builds in gallium/auxiliary
On 28 June 2013 14:57, Andreas Boll wrote: > There is an open bug report about this issue: > https://bugs.freedesktop.org/show_bug.cgi?id=60197 > > Matt, could you take a look at this? > Which patch do you prefer? Quentin's patch is more generic as it uses $(dir), so merge that one. Ross ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] svga: pass svga_compile_key by reference instead of value
---
src/gallium/drivers/svga/svga_tgsi.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi.c
b/src/gallium/drivers/svga/svga_tgsi.c
index 56529c6..29fbe84 100644
--- a/src/gallium/drivers/svga/svga_tgsi.c
+++ b/src/gallium/drivers/svga/svga_tgsi.c
@@ -266,7 +266,7 @@ svga_remap_generic_index(int8_t
remap_table[MAX_GENERIC_VARYING],
*/
static struct svga_shader_result *
svga_tgsi_translate(const struct svga_shader *shader,
-struct svga_compile_key key, unsigned unit)
+const struct svga_compile_key *key, unsigned unit)
{
struct svga_shader_result *result = NULL;
struct svga_shader_emitter emit;
@@ -281,17 +281,17 @@ svga_tgsi_translate(const struct svga_shader *shader,
emit.ptr = emit.buf;
emit.unit = unit;
- emit.key = key;
+ emit.key = *key;
tgsi_scan_shader(shader->tokens, &emit.info);
emit.imm_start = emit.info.file_max[TGSI_FILE_CONSTANT] + 1;
if (unit == PIPE_SHADER_FRAGMENT)
- emit.imm_start += key.fkey.num_unnormalized_coords;
+ emit.imm_start += key->fkey.num_unnormalized_coords;
if (unit == PIPE_SHADER_VERTEX) {
- emit.imm_start += key.vkey.need_prescale ? 2 : 0;
+ emit.imm_start += key->vkey.need_prescale ? 2 : 0;
}
emit.nr_hw_float_const =
@@ -324,7 +324,7 @@ svga_tgsi_translate(const struct svga_shader *shader,
result->shader = shader;
result->tokens = (const unsigned *) emit.buf;
result->nr_tokens = (emit.ptr - emit.buf) / sizeof(unsigned);
- memcpy(&result->key, &key, sizeof key);
+ memcpy(&result->key, key, sizeof(*key));
result->id = UTIL_BITMASK_INVALID_INDEX;
if (SVGA_DEBUG & DEBUG_TGSI) {
@@ -360,7 +360,7 @@ svga_translate_fragment_program(const struct
svga_fragment_shader *fs,
memcpy(key.generic_remap_table, fs->generic_remap_table,
sizeof(fs->generic_remap_table));
- return svga_tgsi_translate(&fs->base, key, PIPE_SHADER_FRAGMENT);
+ return svga_tgsi_translate(&fs->base, &key, PIPE_SHADER_FRAGMENT);
}
@@ -379,7 +379,7 @@ svga_translate_vertex_program(const struct
svga_vertex_shader *vs,
*/
svga_remap_generics(vkey->fs_generic_inputs, key.generic_remap_table);
- return svga_tgsi_translate(&vs->base, key, PIPE_SHADER_VERTEX);
+ return svga_tgsi_translate(&vs->base, &key, PIPE_SHADER_VERTEX);
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] svga: use switch statement in svga_shader_type()
Safer in case the PIPE_SHADER_x tokens get renumbered (as Marek
wanted to do).
---
src/gallium/drivers/svga/svga_state_constants.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_state_constants.c
b/src/gallium/drivers/svga/svga_state_constants.c
index 77c9349..1c0edb4 100644
--- a/src/gallium/drivers/svga/svga_state_constants.c
+++ b/src/gallium/drivers/svga/svga_state_constants.c
@@ -46,13 +46,18 @@
/**
* Convert from PIPE_SHADER_* to SVGA3D_SHADERTYPE_*
*/
-static int
+static unsigned
svga_shader_type(unsigned shader)
{
- assert(PIPE_SHADER_VERTEX + 1 == SVGA3D_SHADERTYPE_VS);
- assert(PIPE_SHADER_FRAGMENT + 1 == SVGA3D_SHADERTYPE_PS);
- assert(shader <= PIPE_SHADER_FRAGMENT);
- return shader + 1;
+ switch (shader) {
+ case PIPE_SHADER_VERTEX:
+ return SVGA3D_SHADERTYPE_VS;
+ case PIPE_SHADER_FRAGMENT:
+ return SVGA3D_SHADERTYPE_PS;
+ default:
+ assert(!"Unexpected shader type");
+ return SVGA3D_SHADERTYPE_VS;
+ }
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH][V2] build: fix out-of-tree builds in gallium/auxiliary
There is an open bug report about this issue: https://bugs.freedesktop.org/show_bug.cgi?id=60197 Matt, could you take a look at this? Which patch do you prefer? 2013/6/28 Ross Burton > The rules were writing files to e.g. util/u_indices_gen.py, but in an > out-of-tree build this directory doesn't exist in the build directory. So, > create the directories just in case. > > Note: This patch is a candidate for the 9.0 and 9.1 branches. > 9.0 is still mentioned. > > Signed-off-by: Ross Burton > --- > src/gallium/auxiliary/Makefile.am |4 > 1 file changed, 4 insertions(+) > > diff --git a/src/gallium/auxiliary/Makefile.am > b/src/gallium/auxiliary/Makefile.am > index f14279b..670e124 100644 > --- a/src/gallium/auxiliary/Makefile.am > +++ b/src/gallium/auxiliary/Makefile.am > @@ -38,13 +38,17 @@ libgallium_la_SOURCES += \ > endif > > indices/u_indices_gen.c: $(srcdir)/indices/u_indices_gen.py > + $(MKDIR_P) indices > $(AM_V_GEN) $(PYTHON2) $< > $@ > > indices/u_unfilled_gen.c: $(srcdir)/indices/u_unfilled_gen.py > + $(MKDIR_P) indices > $(AM_V_GEN) $(PYTHON2) $< > $@ > > util/u_format_srgb.c: $(srcdir)/util/u_format_srgb.py > + $(MKDIR_P) util > $(AM_V_GEN) $(PYTHON2) $< > $@ > > util/u_format_table.c: $(srcdir)/util/u_format_table.py > $(srcdir)/util/u_format_pack.py $(srcdir)/util/u_format_parse.py > $(srcdir)/util/u_format.csv > + $(MKDIR_P) util > $(AM_V_GEN) $(PYTHON2) $(srcdir)/util/u_format_table.py > $(srcdir)/util/u_format.csv > $@ > -- > 1.7.10.4 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/21] Extension clean up
On 06/27/2013 07:20 PM, Ian Romanick wrote: This is my annual extension clean up blob. I don't expect much here to be controversial (or even interesting to read) except patches 12, 17, 18, and 21. LGTM. Just a minor formatting comment on #19. And I second Kenneth's comment on #20. For 5-21, Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 19/21] mesa: GL_ARB_texture_storage is not optional
On 06/27/2013 07:20 PM, Ian Romanick wrote:
From: Ian Romanick
In Mesa, this extension is implemented purely in software. Drivers may
*optionally* provide optimized paths.
NOTE: This has the side effect of enabling the extension in the radeon,
r200, and nouveau drivers.
Signed-off-by: Ian Romanick
---
docs/relnotes/9.2.html | 1 +
src/mesa/drivers/dri/i915/intel_extensions.c | 1 -
src/mesa/drivers/dri/i965/intel_extensions.c | 1 -
src/mesa/main/extensions.c | 3 +--
src/mesa/main/mtypes.h | 1 -
src/mesa/main/teximage.c | 9 +++--
src/mesa/main/texparam.c | 4
src/mesa/state_tracker/st_extensions.c | 1 -
8 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/docs/relnotes/9.2.html b/docs/relnotes/9.2.html
index 2f2c394..1f49191 100644
--- a/docs/relnotes/9.2.html
+++ b/docs/relnotes/9.2.html
@@ -48,6 +48,7 @@ Note: some of the new features are only available with
certain drivers.
GL_ARB_texture_multisample
GL_ARB_texture_storage_multisample
GL_ARB_texture_query_lod
+Enable GL_ARB_texture_storage on radeon, r200, and nouveau
Added new freedreno gallium driver
OSMesa interface for gallium llvmpipe/softpipe drivers
Gallium Heads-Up Display (HUD) feature for performance monitoring
diff --git a/src/mesa/drivers/dri/i915/intel_extensions.c
b/src/mesa/drivers/dri/i915/intel_extensions.c
index 74b304a..479217b 100644
--- a/src/mesa/drivers/dri/i915/intel_extensions.c
+++ b/src/mesa/drivers/dri/i915/intel_extensions.c
@@ -57,7 +57,6 @@ intelInitExtensions(struct gl_context *ctx)
ctx->Extensions.ARB_texture_env_combine = true;
ctx->Extensions.ARB_texture_env_crossbar = true;
ctx->Extensions.ARB_texture_env_dot3 = true;
- ctx->Extensions.ARB_texture_storage = true;
ctx->Extensions.ARB_vertex_program = true;
ctx->Extensions.ARB_vertex_shader = true;
ctx->Extensions.EXT_blend_color = true;
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 23b74a5..5064018 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -79,7 +79,6 @@ intelInitExtensions(struct gl_context *ctx)
ctx->Extensions.ARB_texture_non_power_of_two = true;
ctx->Extensions.ARB_texture_rg = true;
ctx->Extensions.ARB_texture_rgb10_a2ui = true;
- ctx->Extensions.ARB_texture_storage = true;
ctx->Extensions.ARB_vertex_program = true;
ctx->Extensions.ARB_vertex_shader = true;
ctx->Extensions.ARB_vertex_type_2_10_10_10_rev = true;
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 73282e1..f914981 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -149,7 +149,7 @@ static const struct extension extension_table[] = {
{ "GL_ARB_texture_rectangle", o(NV_texture_rectangle),
GL, 2004 },
{ "GL_ARB_texture_rgb10_a2ui", o(ARB_texture_rgb10_a2ui),
GL, 2009 },
{ "GL_ARB_texture_rg", o(ARB_texture_rg),
GL, 2008 },
- { "GL_ARB_texture_storage", o(ARB_texture_storage),
GL, 2011 },
+ { "GL_ARB_texture_storage", o(dummy_true),
GL, 2011 },
{ "GL_ARB_texture_storage_multisample",
o(ARB_texture_storage_multisample), GL, 2012 },
{ "GL_ARB_texture_swizzle", o(EXT_texture_swizzle),
GL, 2008 },
{ "GL_ARB_timer_query", o(ARB_timer_query),
GL, 2010 },
@@ -403,7 +403,6 @@ _mesa_enable_sw_extensions(struct gl_context *ctx)
ctx->Extensions.ARB_texture_non_power_of_two = GL_TRUE;
ctx->Extensions.ARB_texture_rg = GL_TRUE;
ctx->Extensions.ARB_texture_compression_rgtc = GL_TRUE;
- ctx->Extensions.ARB_texture_storage = GL_TRUE;
ctx->Extensions.ARB_vertex_program = GL_TRUE;
ctx->Extensions.ARB_vertex_shader = GL_TRUE;
ctx->Extensions.ARB_sync = GL_TRUE;
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 2879341..a19ecd6 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3036,7 +3036,6 @@ struct gl_extensions
GLboolean ARB_texture_query_lod;
GLboolean ARB_texture_rg;
GLboolean ARB_texture_rgb10_a2ui;
- GLboolean ARB_texture_storage;
GLboolean ARB_texture_storage_multisample;
GLboolean ARB_timer_query;
GLboolean ARB_transform_feedback2;
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 5226687..be03a60 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1852,12 +1852,9 @@ legal_texsubimage_target(struct gl_context *ctx, GLuint
dims,
Re: [Mesa-dev] [PATCH] build: fix out-of-tree builds in gallium/auxiliary
Hi Andreas, Both good points, V2 sent. Ross ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH][V2] build: fix out-of-tree builds in gallium/auxiliary
The rules were writing files to e.g. util/u_indices_gen.py, but in an out-of-tree build this directory doesn't exist in the build directory. So, create the directories just in case. Note: This patch is a candidate for the 9.0 and 9.1 branches. Signed-off-by: Ross Burton --- src/gallium/auxiliary/Makefile.am |4 1 file changed, 4 insertions(+) diff --git a/src/gallium/auxiliary/Makefile.am b/src/gallium/auxiliary/Makefile.am index f14279b..670e124 100644 --- a/src/gallium/auxiliary/Makefile.am +++ b/src/gallium/auxiliary/Makefile.am @@ -38,13 +38,17 @@ libgallium_la_SOURCES += \ endif indices/u_indices_gen.c: $(srcdir)/indices/u_indices_gen.py + $(MKDIR_P) indices $(AM_V_GEN) $(PYTHON2) $< > $@ indices/u_unfilled_gen.c: $(srcdir)/indices/u_unfilled_gen.py + $(MKDIR_P) indices $(AM_V_GEN) $(PYTHON2) $< > $@ util/u_format_srgb.c: $(srcdir)/util/u_format_srgb.py + $(MKDIR_P) util $(AM_V_GEN) $(PYTHON2) $< > $@ util/u_format_table.c: $(srcdir)/util/u_format_table.py $(srcdir)/util/u_format_pack.py $(srcdir)/util/u_format_parse.py $(srcdir)/util/u_format.csv + $(MKDIR_P) util $(AM_V_GEN) $(PYTHON2) $(srcdir)/util/u_format_table.py $(srcdir)/util/u_format.csv > $@ -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: fix out-of-tree builds in gallium/auxiliary
2013/6/28 Ross Burton > The rules were writing files to e.g. util/u_indices_gen.py, but in an > out-of-tree build this directory doesn't exist in the build directory. So, > create the directories just in case. > > Note: This patch is a candidate for the 9.0 and 9.1 branches. > I think you can drop 9.0, since gallium was converted to Automake in mesa 9.1. > > Signed-off-by: Ross Burton > --- > src/gallium/auxiliary/Makefile.am |4 > 1 file changed, 4 insertions(+) > > diff --git a/src/gallium/auxiliary/Makefile.am > b/src/gallium/auxiliary/Makefile.am > index f14279b..0c3e7ba 100644 > --- a/src/gallium/auxiliary/Makefile.am > +++ b/src/gallium/auxiliary/Makefile.am > @@ -38,13 +38,17 @@ libgallium_la_SOURCES += \ > endif > > indices/u_indices_gen.c: $(srcdir)/indices/u_indices_gen.py > + mkdir --parents indices > Please use the autoconf variable $(MKDIR_P) instead of mkdir --parents. With these changes: Reviewed-by: Andreas Boll > $(AM_V_GEN) $(PYTHON2) $< > $@ > > indices/u_unfilled_gen.c: $(srcdir)/indices/u_unfilled_gen.py > + mkdir --parents indices > $(AM_V_GEN) $(PYTHON2) $< > $@ > > util/u_format_srgb.c: $(srcdir)/util/u_format_srgb.py > + mkdir --parents util > $(AM_V_GEN) $(PYTHON2) $< > $@ > > util/u_format_table.c: $(srcdir)/util/u_format_table.py > $(srcdir)/util/u_format_pack.py $(srcdir)/util/u_format_parse.py > $(srcdir)/util/u_format.csv > + mkdir --parents util > $(AM_V_GEN) $(PYTHON2) $(srcdir)/util/u_format_table.py > $(srcdir)/util/u_format.csv > $@ > -- > 1.7.10.4 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Return ZeroVec/dummyReg instead of NULL pointer
On 06/27/2013 05:37 PM, Anuj Phogat wrote:
Assertions are not sufficient to check for null pointers as they don't
show up in release builds. So, return ZeroVec/dummyReg instead of NULL
pointer in get_{src,dst}_register_pointer(). This should calm down
static analysis tool.
Signed-off-by: Anuj Phogat
---
src/mesa/program/prog_execute.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/mesa/program/prog_execute.c b/src/mesa/program/prog_execute.c
index b902006..560332a 100644
--- a/src/mesa/program/prog_execute.c
+++ b/src/mesa/program/prog_execute.c
@@ -145,7 +145,7 @@ get_src_register_pointer(const struct prog_src_register
*source,
_mesa_problem(NULL,
"Invalid src register file %d in get_src_register_pointer()",
source->File);
- return NULL;
+ return ZeroVec;
}
}
@@ -184,7 +184,7 @@ get_dst_register_pointer(const struct prog_dst_register
*dest,
_mesa_problem(NULL,
"Invalid dest register file %d in get_dst_register_pointer()",
dest->File);
- return NULL;
+ return dummyReg;
}
}
@@ -199,7 +199,6 @@ fetch_vector4(const struct prog_src_register *source,
const struct gl_program_machine *machine, GLfloat result[4])
{
const GLfloat *src = get_src_register_pointer(source, machine);
- ASSERT(src);
if (source->Swizzle == SWIZZLE_NOOP) {
/* no swizzling */
@@ -302,7 +301,6 @@ fetch_vector1(const struct prog_src_register *source,
const struct gl_program_machine *machine, GLfloat result[4])
{
const GLfloat *src = get_src_register_pointer(source, machine);
- ASSERT(src);
result[0] = src[GET_SWZ(source->Swizzle, 0)];
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 56710] src/mapi/glapi/glapitemp.h:1640:1: warning: no previous prototype for ‘glReadBufferNV’ [-Wmissing-prototypes]
https://bugs.freedesktop.org/show_bug.cgi?id=56710 Andreas Boll changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Andreas Boll --- (In reply to comment #14) > (In reply to comment #13) > > Could you still reproduce this bug? > > Appears to be fixed to me. Thanks for testing. -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/21] i915: Remove GEN >= 4 extension support
On 06/27/2013 06:20 PM, Ian Romanick wrote: From: Ian Romanick This copy of the source file is only used for GEN <= 3, so remove the dead code. Signed-off-by: Ian Romanick --- src/mesa/drivers/dri/i915/intel_extensions.c | 79 ++-- 1 file changed, 3 insertions(+), 76 deletions(-) This series looks good to me! Unfortunately, both you and Eric removed the gen checks from the i915/i965 extensions lists, so there were some conflicts. Yours looks a bit cleaner, so I created a new branch which is master + your series + anholt's series. It's 59 commits, and available as the 'fork-i915' branch of my tree: http://cgit.freedesktop.org/~kwg/mesa/log/?h=fork-i915 I also incorporated my feedback on patch 20, so I'd appreciate an ack if you believe that's right/wrong. Unless there are any objections, I hope to push it soon. --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] build: fix out-of-tree builds in gallium/auxiliary
The rules were writing files to e.g. util/u_indices_gen.py, but in an out-of-tree build this directory doesn't exist in the build directory. So, create the directories just in case. Note: This patch is a candidate for the 9.0 and 9.1 branches. Signed-off-by: Ross Burton --- src/gallium/auxiliary/Makefile.am |4 1 file changed, 4 insertions(+) diff --git a/src/gallium/auxiliary/Makefile.am b/src/gallium/auxiliary/Makefile.am index f14279b..0c3e7ba 100644 --- a/src/gallium/auxiliary/Makefile.am +++ b/src/gallium/auxiliary/Makefile.am @@ -38,13 +38,17 @@ libgallium_la_SOURCES += \ endif indices/u_indices_gen.c: $(srcdir)/indices/u_indices_gen.py + mkdir --parents indices $(AM_V_GEN) $(PYTHON2) $< > $@ indices/u_unfilled_gen.c: $(srcdir)/indices/u_unfilled_gen.py + mkdir --parents indices $(AM_V_GEN) $(PYTHON2) $< > $@ util/u_format_srgb.c: $(srcdir)/util/u_format_srgb.py + mkdir --parents util $(AM_V_GEN) $(PYTHON2) $< > $@ util/u_format_table.c: $(srcdir)/util/u_format_table.py $(srcdir)/util/u_format_pack.py $(srcdir)/util/u_format_parse.py $(srcdir)/util/u_format.csv + mkdir --parents util $(AM_V_GEN) $(PYTHON2) $(srcdir)/util/u_format_table.py $(srcdir)/util/u_format.csv > $@ -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 56710] src/mapi/glapi/glapitemp.h:1640:1: warning: no previous prototype for ‘glReadBufferNV’ [-Wmissing-prototypes]
https://bugs.freedesktop.org/show_bug.cgi?id=56710 --- Comment #14 from Jon TURNEY --- (In reply to comment #13) > Could you still reproduce this bug? Appears to be fixed to me. -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66149] [HSW] Background of application icon has garbage after update kernel&mesa in order to support Graphics [8086: 0a2e]
https://bugs.freedesktop.org/show_bug.cgi?id=66149 --- Comment #6 from Andreas Boll --- (In reply to comment #4) > The issue can't be reproduced with 9.1 branch. > When will 9.1.4 release? Thanks! It's planned to be released on monday. http://lists.freedesktop.org/archives/mesa-dev/2013-June/040999.html -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66149] [HSW] Background of application icon has garbage after update kernel&mesa in order to support Graphics [8086: 0a2e]
https://bugs.freedesktop.org/show_bug.cgi?id=66149 Gordon Jin changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #5 from Gordon Jin --- I think we can close this. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 12/21] mesa: Remove GL_MESA_resize_buffers
I think you might squash the attached diff into your patch.
Andreas.
2013/6/28 Ian Romanick
> From: Ian Romanick
>
> Commit bab755a made the implementation a no-op, and it was only ever
> enabled by software rasterizers.
>
> Signed-off-by: Ian Romanick
> ---
> docs/relnotes/9.2.html | 2 ++
> src/mapi/glapi/gen/gl_API.xml | 2 +-
> src/mapi/glapi/gen/mesadef.py | 1 -
> src/mesa/drivers/windows/gdi/mesa.def | 1 -
> src/mesa/main/extensions.c | 2 --
> src/mesa/main/framebuffer.c | 10 --
> src/mesa/main/framebuffer.h | 4
> src/mesa/main/mtypes.h | 1 -
> src/mesa/main/tests/dispatch_sanity.cpp | 3 ---
> 9 files changed, 3 insertions(+), 23 deletions(-)
>
> diff --git a/docs/relnotes/9.2.html b/docs/relnotes/9.2.html
> index 08e82d0..2f2c394 100644
> --- a/docs/relnotes/9.2.html
> +++ b/docs/relnotes/9.2.html
> @@ -65,6 +65,8 @@ Note: some of the new features are only available with
> certain drivers.
> Removed d3d1x state tracker (unused, unmaintained and broken)
> Removed GL_EXT_clip_volume_hint because no driver had enabled it since
> 2007.
> +Removed GL_MESA_resize_buffers because it was only really implemented
> by
> +the (unsupported) GDI driver.
>
>
>
> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> index a066fe2..82b908f 100644
> --- a/src/mapi/glapi/gen/gl_API.xml
> +++ b/src/mapi/glapi/gen/gl_API.xml
> @@ -11032,7 +11032,7 @@
>
>
>
> -
> +
>
>
>
> diff --git a/src/mapi/glapi/gen/mesadef.py b/src/mapi/glapi/gen/mesadef.py
> index f6d33cb..77cc4a3 100644
> --- a/src/mapi/glapi/gen/mesadef.py
> +++ b/src/mapi/glapi/gen/mesadef.py
> @@ -134,7 +134,6 @@ def PrintTail():
> print '\t_mesa_new_buffer_object'
> print '\t_mesa_new_texture_object'
> print '\t_mesa_problem'
> -print '\t_mesa_ResizeBuffersMESA'
> print '\t_mesa_store_compressed_teximage1d'
> print '\t_mesa_store_compressed_teximage2d'
> print '\t_mesa_store_compressed_teximage3d'
> diff --git a/src/mesa/drivers/windows/gdi/mesa.def
> b/src/mesa/drivers/windows/gdi/mesa.def
> index fec7bba..92736b3 100644
> --- a/src/mesa/drivers/windows/gdi/mesa.def
> +++ b/src/mesa/drivers/windows/gdi/mesa.def
> @@ -556,7 +556,6 @@ EXPORTS
> glFogCoorddvEXT
> glFogCoordPointerEXT
> glBlendFuncSeparateEXT
> - glResizeBuffersMESA
> glWindowPos2dMESA
> glWindowPos2dvMESA
> glWindowPos2fMESA
> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
> index 8f96a77..9c90bbe 100644
> --- a/src/mesa/main/extensions.c
> +++ b/src/mesa/main/extensions.c
> @@ -307,7 +307,6 @@ static const struct extension extension_table[] = {
> { "GL_IBM_texture_mirrored_repeat", o(dummy_true),
> GLL,1998 },
> { "GL_INGR_blend_func_separate",
> o(EXT_blend_func_separate), GLL,1999 },
> { "GL_MESA_pack_invert",o(MESA_pack_invert),
> GL, 2002 },
> - { "GL_MESA_resize_buffers",
> o(MESA_resize_buffers), GL, 1999 },
> { "GL_MESA_texture_array", o(MESA_texture_array),
> GLL,2007 },
> { "GL_MESA_texture_signed_rgba",o(EXT_texture_snorm),
> GL, 2009 },
> { "GL_MESA_window_pos", o(dummy_true),
> GLL,2000 },
> @@ -445,7 +444,6 @@ _mesa_enable_sw_extensions(struct gl_context *ctx)
> /*ctx->Extensions.EXT_transform_feedback = GL_TRUE;*/
> ctx->Extensions.EXT_vertex_array_bgra = GL_TRUE;
> ctx->Extensions.MESA_pack_invert = GL_TRUE;
> - ctx->Extensions.MESA_resize_buffers = GL_TRUE;
> ctx->Extensions.MESA_texture_array = GL_TRUE;
> ctx->Extensions.MESA_ycbcr_texture = GL_TRUE;
> ctx->Extensions.NV_blend_square = GL_TRUE;
> diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
> index d28882a..4ec4118 100644
> --- a/src/mesa/main/framebuffer.c
> +++ b/src/mesa/main/framebuffer.c
> @@ -319,16 +319,6 @@ _mesa_resize_framebuffer(struct gl_context *ctx,
> struct gl_framebuffer *fb,
> }
> }
>
> -/*
> - * XXX THIS IS OBSOLETE
> - */
> -void GLAPIENTRY
> -_mesa_ResizeBuffersMESA( void )
> -{
> -}
> -
> -
> -
> /**
> * Examine all the framebuffer's renderbuffers to update the Width/Height
> * fields of the framebuffer. If we have renderbuffers with different
> diff --git a/src/mesa/main/framebuffer.h b/src/mesa/main/framebuffer.h
> index 1b1caab..2645664 100644
> --- a/src/mesa/main/framebuffer.h
> +++ b/src/mesa/main/framebuffer.h
> @@ -71,10 +71,6 @@ _mesa_resize_framebuffer(struct gl_context *ctx, struct
> gl_framebuffer *fb,
> extern void
> _mesa_resizebuffers( struct gl_context *ctx );
>
> -extern void GLAPIENTRY
>
