Re: [Mesa-dev] [PATCH] glx: fix compile error in egl_glx.c.

On 09/17/2013 12:46 PM, Gaetan Nadon wrote: > egl_glx.c:40:22: fatal error: X11/Xlib.h: No such file or directory > > The compiler cannot find the Xlib.h in the installed system headers. > All supplied include directives point to inside the mesa module. > The X11_CFLAGS variable is undefined (not

[Mesa-dev] [Bug 69541] ir_constant_expression.cpp(1384) : error C3861: 'isnormal': identifier not found

https://bugs.freedesktop.org/show_bug.cgi?id=69541 --- Comment #1 from Kenneth Graunke --- FWIW it looks like MSVC 2013 added isnormal(), but still lacks copysign(): http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx -- You are receiving this mail

Re: [Mesa-dev] [PATCH] i965/gen4: Fix fragment program rectangle texture shadow compares.

On 09/18/2013 01:18 PM, Eric Anholt wrote: > The rescale_texcoord(), if it does something, will return just the > GLSL-sized coordinate, leaving out the 3rd and 4th components where we > were storing our projected shadow compare and the texture projector. > Deref the shadow compare before using the

Re: [Mesa-dev] [PATCH V3 06/11] i965: w/a for gather4 green RG32F

On 09/15/2013 02:58 AM, Chris Forbes wrote: > Signed-off-by: Chris Forbes > --- > src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 4 > src/mesa/drivers/dri/i965/brw_program.h| 5 + > src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 4 > src/mesa/drivers/dri/i965/brw_wm.c

Re: [Mesa-dev] [PATCH V3 04/11] i965/fs: Add support for ir_tg4

On 09/15/2013 02:58 AM, Chris Forbes wrote: > Lowers ir_tg4 (from textureGather and textureGatherOffset builtins) to > SHADER_OPCODE_TG4. > > The usual post-sampling swizzle workaround can't work for ir_tg4, > so avoid doing that: > > * For R/G/B/A swizzles use the hardware channel select (lives

Re: [Mesa-dev] [PATCH 10/24] glsl: Implement parser support for atomic counters.

Ian Romanick writes: >[...] + if (field_type->atomic_size()) { +YYLTYPE loc = decl_list->get_location(); + _mesa_glsl_error(&loc, state, "atomic counter in structure or " + "uniform block"); + } + A

Re: [Mesa-dev] [PATCH 11/17] mesa: Get GL_MAX_VARYING_FLOATS_ARB from VertexProgram.MaxOutputComponents

I don't remember implementing anything in the GLSL linker for colors not to be counted against the maximum varying count limit. R500 supports GL_ARB_color_buffer_float, but not GL3.0. R300 and R500 have special slots for colors. Marek On Wed, Sep 18, 2013 at 10:30 PM, Paul Berry wrote: > On 18

Re: [Mesa-dev] [PATCH 02/24] glsl: Initialize all member variables of _mesa_glsl_parse_state on construction.

Ian Romanick writes: > On 09/18/2013 01:35 PM, Paul Berry wrote: >>[...] >> * Initializing class members in the constructor is common practice in >> C++, and therefore less surprising to developers who are new to the Mesa >> code base. >> >> * If a class initializes all its members in the constr

Re: [Mesa-dev] [PATCH 02/24] glsl: Initialize all member variables of _mesa_glsl_parse_state on construction.

On 09/18/2013 07:43 AM, Ian Romanick wrote: > On 09/15/2013 02:10 AM, Francisco Jerez wrote: >> The _mesa_glsl_parse_state object relies on the memory allocator >> zeroing out its contents before it's initialized, which seems rather >> risky. One of the following commits will homogenize implementa

Re: [Mesa-dev] [PATCH 04/24] ralloc: Unify overloads of the new operator and guarantee object destruction.

On 09/15/2013 12:10 AM, Francisco Jerez wrote: > This patch introduces a pair of helper functions providing a common > implementation of the "new" and "delete" operators for all C++ classes > that are allocated by ralloc via placement new. The 'ralloc_new' > helper function takes care of setting u

[Mesa-dev] [RFC PATCH 5/5] glsl: Switch a few more classes to DECLARE_RALLOC_CXX_OPERATORS.

Now that the macros arrange for the destructors to be called, we can use them in these cases too. Signed-off-by: Kenneth Graunke --- src/glsl/glsl_symbol_table.h | 30 +- src/glsl/loop_analysis.h | 17 + 2 files changed, 2 insertions(+), 45 deletio

[Mesa-dev] [PATCH 2/5] glsl: Use the new DECLARE_R[Z]ALLOC_CXX_OPERATORS in a bunch of places.

This eliminates a lot of boilerplate and should be 100% equivalent. Signed-off-by: Kenneth Graunke --- src/glsl/ast.h| 38 ++- src/glsl/glsl_parser_extras.h | 17 +- src/glsl/glsl_symbol_table.cpp| 15 +--

[Mesa-dev] [PATCH 1/5] ralloc: Introduce new macros for defining C++ new/delete operators.

Most of our C++ classes define placement new and delete operators so we can do convenient allocation via: thing *foo = new(mem_ctx) thing(...) Currently, this is done via a lot of boilerplate. By adding simple macros to ralloc, we can condense this to a single line, making it trivial to add t

[Mesa-dev] [RFC PATCH 4/5] ralloc: Make the C++ macros arrange for class destructors to be called.

Previously, almost all classes didn't actually call their destructors, which is non-intuitive for C++ code. Setting them up to be called was somewhat of a pain, since it required defining a helper function. With the new macros, we can easily encapsulate this complexity, making destructors just ha

[Mesa-dev] [PATCH 3/5] i965, mesa: Use the new DECLARE_R[Z]ALLOC_CXX_OPERATORS macros.

These classes declared a placement new operator, but didn't declare a delete operator. Switching to the macro gives them a delete operator, which probably is a good idea anyway. This also eliminates a lot of boilerplate. Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/brw_cfg.h

Re: [Mesa-dev] [PATCH 10/24] glsl: Implement parser support for atomic counters.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/18/2013 03:43 PM, Francisco Jerez wrote: > Ian Romanick writes: > >> On 09/17/2013 03:51 PM, Paul Berry wrote: >>> On 15 September 2013 00:10, Francisco Jerez >>> mailto:curroje...@riseup.net>> wrote: >>> [...] >>> >>> GLSL 4.20 clarifies tha

Re: [Mesa-dev] [PATCH 10/24] glsl: Implement parser support for atomic counters.

Ian Romanick writes: > On 09/17/2013 03:51 PM, Paul Berry wrote: >> On 15 September 2013 00:10, Francisco Jerez > > wrote: >>[...] >> >> GLSL 4.20 clarifies that atomic counter offsets must be unique and >> non-overlapping (see GLSL 4.20 4.4.4.1 "Atomic Counter Layo

Re: [Mesa-dev] [PATCH 02/24] glsl: Initialize all member variables of _mesa_glsl_parse_state on construction.

On 18 September 2013 13:15, Ian Romanick wrote: > On 09/18/2013 01:35 PM, Paul Berry wrote: > > On 18 September 2013 07:43, Ian Romanick > > wrote: > > > > On 09/15/2013 02:10 AM, Francisco Jerez wrote: > > > The _mesa_glsl_parse_state object relies on the me

[Mesa-dev] [PATCH 4/9] i965: Stop allocating miptrees with first_level != 0.

If the caller shows up with GL_BASE_LEVEL != 0, it doesn't mean that the texture will over the course of its lifetime have that nonzero baselevel, it means that the caller is filling the texture from the bottom up for some reason (one could imagine demand-loading detailed texture layers at runtime,

[Mesa-dev] [PATCH 3/9] i965: Drop a special case for guessing small miptree levels.

Let's say you started allocating your 2D texture with level 2 of a tree as a 1x1 image. The driver doesn't know if this means that level 0 is 4x4 or 4x1 or 1x4, so we would just allocate a single 1x1 and let it get copied in to the real location at texture validate time later. Since this is just

[Mesa-dev] [PATCH pre-06/17] i965: Set *Program.Max{Input, Output}Components

From: Ian Romanick Now that MaxVaryings is > 16, VertexProgram.MaxOutputComponents, GeometryProgram.MaxInputComponents, GeometryProgram.MaxOutputComponents, and FragmentProgram.MaxInputComponents also need to be set. Signed-off-by: Ian Romanick Cc: Paul Berry --- Since Paul's "i965/gen6+: Supp

Re: [Mesa-dev] [PATCH 11/17] mesa: Get GL_MAX_VARYING_FLOATS_ARB from VertexProgram.MaxOutputComponents

On 18 September 2013 13:04, Ian Romanick wrote: > On 09/13/2013 01:45 PM, Paul Berry wrote: > > On 11 September 2013 16:28, Ian Romanick > > wrote: > > Another question which we haven't really addressed is how Mesa's front > > end linker should check these limits, gi

[Mesa-dev] [PATCH 9/9] i965: Add a real native TexStorage path.

We originally had a path just did the loop and called ctx->Driver.AllocTextureImageBuffer(), which I moved into Mesa core. But we can do better, avoiding incorrect miptree size guesses and later texture validations by just directly allocating the miptree and setting it to all the images. --- src/

[Mesa-dev] [PATCH 6/9] i965: Don't relayout a texture just for baselevel changes.

As long as the baselevel, maxlevel still sit inside the range we had previously validated, there's no need to reallocate the texture. I also hope this makes our texture validation logic much more obvious. It's taken me enough tries to write this change, that's for sure. Reduces miptree copy count

[Mesa-dev] [PATCH 8/9] i965: Add missing license to intel_tex_validate.c.

I've rewritten a lot of this file. --- src/mesa/drivers/dri/i965/intel_tex_validate.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/src/mesa/drivers/dri/i965/intel_tex_validate.c b/src/mesa/drivers/dri/i965/intel_tex_validate.c index e44c3ca..0b1bfe6 100644 --- a/sr

[Mesa-dev] [PATCH] i965/gen4: Fix fragment program rectangle texture shadow compares.

The rescale_texcoord(), if it does something, will return just the GLSL-sized coordinate, leaving out the 3rd and 4th components where we were storing our projected shadow compare and the texture projector. Deref the shadow compare before using the shared rescale-the-coordinate code to fix the prob

Re: [Mesa-dev] [PATCH 02/24] glsl: Initialize all member variables of _mesa_glsl_parse_state on construction.

On 09/18/2013 01:35 PM, Paul Berry wrote: > On 18 September 2013 07:43, Ian Romanick > wrote: > > On 09/15/2013 02:10 AM, Francisco Jerez wrote: > > The _mesa_glsl_parse_state object relies on the memory allocator > > zeroing out its contents before it's i

Re: [Mesa-dev] [PATCH 11/17] mesa: Get GL_MAX_VARYING_FLOATS_ARB from VertexProgram.MaxOutputComponents

On 09/13/2013 01:45 PM, Paul Berry wrote: > On 11 September 2013 16:28, Ian Romanick > wrote: > > On 09/11/2013 04:05 PM, Paul Berry wrote: > > On 10 September 2013 12:10, Ian Romanick > >

[Mesa-dev] [PATCH 5/9] i965: Don't allocate a 1-level texture when GL_GENERATE_MIPMAP is set.

Given that a teximage that calls us with this flag set will immediately proceed to allocate the other levels, we can probably just go ahead and allocate those levels now. Reduces miptree copies in piglit by about .05%. --- src/mesa/drivers/dri/i965/intel_tex_image.c | 3 ++- 1 file changed, 2 ins

[Mesa-dev] [PATCH 2/9] i965: Totally switch around how we handle nonzero baselevel-first_level.

This has no effect currently, because intel_finalize_mipmap_tree() always makes mt->first_level == tObj->BaseLevel. The change I made before to handle it (b1080cfbdb0a084122fcd662cd27b4748c5598fd) got very close to working, but after fixing some unrelated bugs in the series, it still left tex-mipl

[Mesa-dev] [PATCH 7/9] i965: Always allocate validated miptrees from level 0.

No change in copies during a piglit run, but it's one less first_level != 0 in our codebase. --- src/mesa/drivers/dri/i965/intel_tex_validate.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/mesa/drivers/dri/i965/intel_tex_validate.c b/src/mesa/drivers/dri/i965/i

[Mesa-dev] [PATCH 1/9] i965: Always look up from the object's mt when setting up texturing state.

We know that the object's mt is equal to the firstimage's mt because it's gone through intel_finalize_mipmap_tree(). Saves a lookup of firstimage on pre-gen7. --- src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 4 +--- src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 2 +- 2 files changed,

[Mesa-dev] mt->first_level != BaseLevel

Until now, whenever someone adjusts BaseLevel, we copy around the miptree contents to a new miptree that starts from BaseLevel, which is pretty awful when you think about things like generating mipmaps using FBOs and BaseLevel/MaxLevel (which our glGenerateMipmap() does). Disentangling this code h

Re: [Mesa-dev] [PATCH 10/24] glsl: Implement parser support for atomic counters.

Ian Romanick writes: > On 09/15/2013 02:10 AM, Francisco Jerez wrote: >>[...] >> >> >> +#include >> +#include > > No. We are not using STL or templates. > Any reason for it to be still so? Actually I started implementing this patch using one of mesa's hash tables, but at some point I rea

Re: [Mesa-dev] [PATCH 02/24] glsl: Initialize all member variables of _mesa_glsl_parse_state on construction.

Ian Romanick writes: > On 09/15/2013 02:10 AM, Francisco Jerez wrote: >> The _mesa_glsl_parse_state object relies on the memory allocator >> zeroing out its contents before it's initialized, which seems rather >> risky. One of the following commits will homogenize implementations >> of the new o

Re: [Mesa-dev] [PATCH 08/24] glsl: Add new atomic_uint built-in GLSL type.

Paul Berry writes: > On 17 September 2013 14:14, Francisco Jerez wrote: > >> Paul Berry writes: >> >> > On 17 September 2013 12:18, Paul Berry wrote: >> >[...] >> > I also notice that most of your uses of atomic_size() in this patch >> series >> > are merely to see whether the type contains an

Re: [Mesa-dev] [PATCH 02/24] glsl: Initialize all member variables of _mesa_glsl_parse_state on construction.

On 18 September 2013 07:43, Ian Romanick wrote: > On 09/15/2013 02:10 AM, Francisco Jerez wrote: > > The _mesa_glsl_parse_state object relies on the memory allocator > > zeroing out its contents before it's initialized, which seems rather > > risky. One of the following commits will homogenize i

[Mesa-dev] [Bug 69541] New: ir_constant_expression.cpp(1384) : error C3861: 'isnormal': identifier not found

https://bugs.freedesktop.org/show_bug.cgi?id=69541 Priority: medium Bug ID: 69541 Keywords: regression CC: matts...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: ir_constant_expression.cpp(1384) : error C3861:

Re: [Mesa-dev] [PATCH] glsl: Delete builtin_builder::shader when destroying built-ins.

Kenneth Graunke writes: > I would use _mesa_delete_shader, but it's declared static, and we don't > really need any of the stuff in it anyway. > > This fixes a memory leak caught by Valgrind. > > Signed-off-by: Kenneth Graunke Reviewed-by: Eric Anholt pgp4R26YuTpnz.pgp Description: PGP signa

Re: [Mesa-dev] [PATCH 02/24] glsl: Initialize all member variables of _mesa_glsl_parse_state on construction.

Ian Romanick writes: > On 09/15/2013 02:10 AM, Francisco Jerez wrote: >> The _mesa_glsl_parse_state object relies on the memory allocator >> zeroing out its contents before it's initialized, which seems rather >> risky. One of the following commits will homogenize implementations >> of the new o

Re: [Mesa-dev] [PATCH 08/24] glsl: Add new atomic_uint built-in GLSL type.

On 09/17/2013 02:18 PM, Paul Berry wrote: > On 15 September 2013 00:10, Francisco Jerez > wrote: > > --- > src/glsl/ast_to_hir.cpp | 1 + > src/glsl/builtin_type_macros.h | 2 ++ > src/glsl/builtin_types.cpp

Re: [Mesa-dev] [PATCH] android: Remove builtin_compiler

On 09/13/2013 07:15 AM, Adrian M Negreanu wrote: On Fri, Sep 13, 2013 at 5:01 PM, Ian Romanick wrote: Getting rid of the builtin_compiler from the Android build is a good idea... but I'll let Chad or someone who knows /anything/ about the Android build system actually review the patch. Acked-b

Re: [Mesa-dev] [PATCH 10/24] glsl: Implement parser support for atomic counters.

On 09/17/2013 03:51 PM, Paul Berry wrote: > On 15 September 2013 00:10, Francisco Jerez > wrote: > > --- > src/glsl/ast.h| 15 ++ > src/glsl/ast_to_hir.cpp | 68 > +-- > src/gl

Re: [Mesa-dev] [PATCH 10/24] glsl: Implement parser support for atomic counters.

On 09/15/2013 02:10 AM, Francisco Jerez wrote: > --- > src/glsl/ast.h| 15 ++ > src/glsl/ast_to_hir.cpp | 68 > +-- > src/glsl/ast_type.cpp | 13 +++-- > src/glsl/glsl_lexer.ll| 2 +- > src/glsl/glsl_parser

Re: [Mesa-dev] [PATCH 02/24] glsl: Initialize all member variables of _mesa_glsl_parse_state on construction.

On 09/15/2013 02:10 AM, Francisco Jerez wrote: > The _mesa_glsl_parse_state object relies on the memory allocator > zeroing out its contents before it's initialized, which seems rather > risky. One of the following commits will homogenize implementations > of the new operator in a way that would b

[Mesa-dev] [Bug 55817] Torchlight: Texture renders as garbage

https://bugs.freedesktop.org/show_bug.cgi?id=55817 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Mesa-dev] [Bug 55817] Torchlight: Texture renders as garbage

https://bugs.freedesktop.org/show_bug.cgi?id=55817 --- Comment #11 from Tim Allen --- Luckily, I still have the same character I used for taking the attached screenshots, and the game hasn't regenerated the levels in the intervening months. I don't have Mesa 9.2, I'm just using Debian's Mesa 9.1.

Re: [Mesa-dev] [PATCH 3/3] util/u_blit: Implement util_blit_pixels via pipe_context::blit.

On Wed, Sep 18, 2013 at 12:36 PM, Jose Fonseca wrote: > - Original Message - >> Isn't u_blit a candidate for removal considering it has no user in Mesa? > > u_blit still has users outside mesa. And it provides features that > pipe_context::blit does not: > > - util_blit_pixels() will call

[Mesa-dev] [Bug 55817] Torchlight: Texture renders as garbage

https://bugs.freedesktop.org/show_bug.cgi?id=55817 --- Comment #10 from Sven Arvidsson --- Is this bug fixed? I can't seem to reproduce it with Mesa 9.2, but I might be looking in the wrong places? -- You are receiving this mail because: You are the assignee for the bug. ___

Re: [Mesa-dev] [PATCH 2/3] util/u_blit: Support blits from cubemaps.

- Original Message - > Am 17.09.2013 20:32, schrieb jfons...@vmware.com: > > From: José Fonseca > > > > By calling util_map_texcoords2d_onto_cubemap. > > > > A new parameter for util_blit_pixels_tex is necessary, as > > pipe_sampler_view::first_layer is always supposed to point to the fi

Re: [Mesa-dev] [PATCH 3/3] util/u_blit: Implement util_blit_pixels via pipe_context::blit.

- Original Message - > Isn't u_blit a candidate for removal considering it has no user in Mesa? u_blit still has users outside mesa. And it provides features that pipe_context::blit does not: - util_blit_pixels() will call pipe_context::resource_copy for non-stretch blits, which is pote

Re: [Mesa-dev] Gallium debugging help

Hi James, 1) Try: GALLIUM_TRACE=~/gallium.trace ./gbmtest 2) Trace is an optional component, so make sure it's built in your driver. See for example src/gallium/targets/dri-r600/Makefile.am to know how to add it. 3) The easiest way to debug gallium is to use a debugger. Marek On Wed, Sep 18,