[Mesa-dev] [Bug 30261] New: [GLSL 1.20] allowing inconsistent invariant declaration between two vertex shaders
https://bugs.freedesktop.org/show_bug.cgi?id=30261 Summary: [GLSL 1.20] allowing inconsistent invariant declaration between two vertex shaders Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: minor Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: gordon@intel.com CC: i...@freedesktop.org Created an attachment (id=38793) View: https://bugs.freedesktop.org/attachment.cgi?id=38793 Review: https://bugs.freedesktop.org/review?bug=30261&attachment=38793 new piglit case GLSL 1.20 section 4.3.6 says: The type and presence of the invariant qualifiers of varying variables with the same name declared in linked vertex and fragments shaders must match, otherwise the link command will fail. GLSL 1.50 section 4.6.1 says more clearly: For variables leaving one shader and coming into another shader, the invariant keyword has to be used in both shaders, or a link error will result. The mesa glsl compiler fails link correctly for one vertex shader and one fragment shader. But it links (incorrectly) successfully for two vertex shaders. This also exists in the old glsl compiler. So I'm not marking this as release blocker. Tested on Piketon (i965) with mesa master ca92ae2699c4aad21c0811b9a5562b9223816caf. New piglit case attached. (This issues also applies for centroid. I'll add a new case for it after this one gets handled.) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] [PATCH] gallium/docs: Fixed a typo in the SCS opcode description.
Signed-off-by: Tilman Sauerbeck --- src/gallium/docs/source/tgsi.rst |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst index e588c5b..4c1f47a 100644 --- a/src/gallium/docs/source/tgsi.rst +++ b/src/gallium/docs/source/tgsi.rst @@ -726,7 +726,7 @@ This instruction replicates its result. dst.z = 0 - dst.y = 1 + dst.w = 1 .. opcode:: TXB - Texture Lookup With Bias -- 1.7.2.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] tgsi: Actually care what check_soa_dependencies says
Hi Jakob, On Sat, 2010-09-18 at 07:30 -0700, Jakob Bornecrantz wrote: > On Sat, Sep 18, 2010 at 4:26 PM, Jakob Bornecrantz > wrote: > > Looking over some of the piglit failings that Vinsons have posted running > > on softpipe (we are down to 3005/3048). At first I was just going to make > > the output not turn into a warn, but looking at the function it looks like > > it actually should return the status and fail. > > > > This fixes both. This is a good idea IMO. Given the existing of gallivm and tgsi_exec.c, both being pretty correct, and the former very fast, I'm not sure what use is tgsi_sse2 catering for anymore. So I think that at very least it should not make things worse. A few cleanups: MOV is being whilelisted twice -- the second one can be removed, and the /* XXX: ... */ comment moved to the top of the function. > Ops, looks like I ctrl-z the tests this was happening in. Its warning > on shaders/fp-abs-01 and the ouput is: > Warning: src/dst aliasing in instruction is not handled: > 1: COS TEMP[1], TEMP[1]. > > For those who where interested in it. There are a bunch of opcodes for which tgsi_sse2 actually doesn't trip over, but are not white-listed yet, like COS. I went through the code and added all I could find. Also, tgsi_check_soa_dependencies ignores indirect registers. Patch attached. Jose diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c b/src/gallium/auxiliary/tgsi/tgsi_exec.c index 298f3d0..2609ea0 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_exec.c +++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c @@ -605,8 +605,10 @@ tgsi_check_soa_dependencies(const struct tgsi_full_instruction *inst) for (i = 0; i < inst->Instruction.NumSrcRegs; i++) { if ((inst->Src[i].Register.File == inst->Dst[0].Register.File) && - (inst->Src[i].Register.Index == - inst->Dst[0].Register.Index)) { + ((inst->Src[i].Register.Index == +inst->Dst[0].Register.Index) || + inst->Src[i].Register.Indirect || + inst->Dst[0].Register.Indirect)) { /* loop over dest channels */ uint channelsWritten = 0x0; FOR_EACH_ENABLED_CHANNEL(*inst, chan) { diff --git a/src/gallium/auxiliary/tgsi/tgsi_sse2.c b/src/gallium/auxiliary/tgsi/tgsi_sse2.c index 785a9fb..379771c 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_sse2.c +++ b/src/gallium/auxiliary/tgsi/tgsi_sse2.c @@ -2835,6 +2835,26 @@ check_soa_dependencies(const struct tgsi_full_instruction *inst) case TGSI_OPCODE_MOV: case TGSI_OPCODE_MUL: case TGSI_OPCODE_XPD: + case TGSI_OPCODE_RCP: + case TGSI_OPCODE_RSQ: + case TGSI_OPCODE_EXP: + case TGSI_OPCODE_LOG: + case TGSI_OPCODE_DP3: + case TGSI_OPCODE_DP4: + case TGSI_OPCODE_DP2A: + case TGSI_OPCODE_EX2: + case TGSI_OPCODE_LG2: + case TGSI_OPCODE_POW: + case TGSI_OPCODE_XPD: + case TGSI_OPCODE_DPH: + case TGSI_OPCODE_COS: + case TGSI_OPCODE_SIN: + case TGSI_OPCODE_TEX: + case TGSI_OPCODE_TXB: + case TGSI_OPCODE_TXP: + case TGSI_OPCODE_NRM: + case TGSI_OPCODE_NRM4: + case TGSI_OPCODE_DP2: /* OK - these opcodes correctly handle SOA dependencies */ break; default: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glsl2: Add pass to remove redundant jumps
On Tue, 14 Sep 2010 03:55:06 +0200, Luca Barbieri wrote: > ir_lower_jumps should already do the jump unification, and > could/should also remove the continue. > It's probably best to put all jump manipulations there to avoid > risking rerunning all passes a number of times linear in the program > size. > > Regarding ifs, it would be nice to also remove empty else branches, > and possibly convert if(c) {} else {code()} to if(!c) {code()} or I remember writing the code to do that, but now I don't see it anywhere. It should happen in ir_if_simplification, I think. > perhaps do the reverse canonicalization instead. > And also things like "if(c) {if(c) {code()}}" to if(c) {code()} We don't have anything for handling constraints on values, and it would be nice if we did. > as well as "if(1) {code()}" to "code()", That's in ir_if_simplification. pgpTmwRZ893Cx.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: Honour destination operand's writemask in the SCS implementation.
Signed-off-by: Tilman Sauerbeck --- src/gallium/drivers/r600/r600_shader.c | 49 +-- 1 files changed, 27 insertions(+), 22 deletions(-) diff --git a/src/gallium/drivers/r600/r600_shader.c b/src/gallium/drivers/r600/r600_shader.c index 4da6850..7e51db6 100644 --- a/src/gallium/drivers/r600/r600_shader.c +++ b/src/gallium/drivers/r600/r600_shader.c @@ -932,32 +932,37 @@ static int tgsi_scs(struct r600_shader_ctx *ctx) /* dst.x = COS */ - memset(&alu, 0, sizeof(struct r600_bc_alu)); - alu.inst = CTX_INST(V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_COS); - r = tgsi_dst(ctx, &inst->Dst[0], 0, &alu.dst); - if (r) - return r; + if (inst->Dst[0].Register.WriteMask & TGSI_WRITEMASK_X) { + memset(&alu, 0, sizeof(struct r600_bc_alu)); + alu.inst = CTX_INST(V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_COS); + r = tgsi_dst(ctx, &inst->Dst[0], 0, &alu.dst); + if (r) + return r; - alu.src[0].sel = ctx->temp_reg; - alu.src[0].chan = 0; - alu.last = 1; - r = r600_bc_add_alu(ctx->bc, &alu); - if (r) - return r; + alu.src[0].sel = ctx->temp_reg; + alu.src[0].chan = 0; + alu.last = 1; + r = r600_bc_add_alu(ctx->bc, &alu); + if (r) + return r; + } /* dst.y = SIN */ - memset(&alu, 0, sizeof(struct r600_bc_alu)); - alu.inst = CTX_INST(V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_SIN); - r = tgsi_dst(ctx, &inst->Dst[0], 1, &alu.dst); - if (r) - return r; + if (inst->Dst[0].Register.WriteMask & TGSI_WRITEMASK_Y) { + memset(&alu, 0, sizeof(struct r600_bc_alu)); + alu.inst = CTX_INST(V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_SIN); + r = tgsi_dst(ctx, &inst->Dst[0], 1, &alu.dst); + if (r) + return r; + + alu.src[0].sel = ctx->temp_reg; + alu.src[0].chan = 0; + alu.last = 1; + r = r600_bc_add_alu(ctx->bc, &alu); + if (r) + return r; + } - alu.src[0].sel = ctx->temp_reg; - alu.src[0].chan = 0; - alu.last = 1; - r = r600_bc_add_alu(ctx->bc, &alu); - if (r) - return r; return 0; } -- 1.7.2.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/docs: Fixed a typo in the SCS opcode description.
Looks good, thanks Tilman. Keith On Sun, Sep 19, 2010 at 8:24 AM, Tilman Sauerbeck wrote: > Signed-off-by: Tilman Sauerbeck > --- > src/gallium/docs/source/tgsi.rst | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/gallium/docs/source/tgsi.rst > b/src/gallium/docs/source/tgsi.rst > index e588c5b..4c1f47a 100644 > --- a/src/gallium/docs/source/tgsi.rst > +++ b/src/gallium/docs/source/tgsi.rst > @@ -726,7 +726,7 @@ This instruction replicates its result. > > dst.z = 0 > > - dst.y = 1 > + dst.w = 1 > > > .. opcode:: TXB - Texture Lookup With Bias > -- > 1.7.2.3 > > ___ > 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] draw_stream_output seems to be broken by design
The current version of draw_stream_output in softpipe seems to attempt to draw using the currently bound stream output buffer as input. This does not match D3D10/11's DrawAuto, which instead draws with the current vertex buffer (and requires having only one bound), but using the primitive count from the latest stream output draw call. MSDN says: <> It also doesn't match DrawTransformFeedback, which draws according to the transform feedback object provided as a parameter. In addition to that, the softpipe approach seems obviously wrong because it makes it impossible to both draw the last stream output buffer and also capture new stream output to another buffer (which is common in the DirectX examples, flipping between two buffers). I think a candidate for a Gallium design would be to add the stream output "CSO" as a parameter to draw_stream_output. If it is passed as NULL, then it draws according to the last draw with stream output on the context (according to D3D10) and if not NULL according to the draw with stream output with that specific CSO bound (according to ARB_transform_feedback2). Furthermore a flag in the CSO to enable/disable CSO-specific SO count recording might allow some driver optimization in the D3D10 case. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Trivially enable GL_ARB_texture_border_clamp for nouveau_vieux
Hi! Patch was not exactly correct, pre-GeForce3 (pre nv20) cards can't do texture borders, even if said mode (CLAMP_TO_BORDER) listed in current headers (nouveau_class.h) and code has case switch for it. But strangely, for me extension pop up in list just as i added it (i was played with cubemaps, got one face from requred six in cubemap demo, highly corrupted, but it is another story), and Mesa finally reported OpenGL 1.3/ of cource, it was lie (due to non-working cubemaps and useless clamp_to_border), but still . make sure you have correct dri driver loaded, LIBGL_DEBUG=verbose usually will tell you from where it tried to load dri driver. As for list of extensions blob exposed GL_ARB_pixel_buffer_object - need some work, i'm not sure what this one want exactly GL_ARB_point_parameters GL_ARB_point_sprite - unfortunately not as trivial as they sounds will look at them GL_ARB_shader_objects GL_ARB_shading_language_100 - sounds like software-emulated on nv17 :( GL_ARB_texture_cube_map - hopefully soon. GL_ARB_vertex_program - should be trivial, in software GL_ARB_vertex_shader - this one harder, even if in sw. GL_S3_s3tc - played with this one, no luck, due to my incapability to write non-trivial code GL_EXT_clip_volume_hint - another one i don't know about GL_EXT_Cg_shader GL_EXT_gpu_program_parameters - - sounds like sw emulation again (nv17 has no advanced pixel processors, not even at GF3-level, so only very-very simple Cg (C-for-Graphics, if i remember correctly) programs will have very slim chance to run accelerated) GL_EXT_paletted_texture - should be simple GL_EXT_pixel_buffer_object - see GL_ARB_pixel_buffer_object GL_EXT_point_parameters - see ARB variant GL_EXT_shared_texture_palette - not sure what this one mean at specification level ... GL_EXT_texture_compression_s3tc - should be enabled automatically when s3tc support will be ready GL_EXT_texture_cube_map - same here GL_EXT_texture_env_dot3 - hopefully same here, but need to check GL_EXT_texture_lod - not sure, isn't it enabled already? GL_KTX_buffer_region - something very specific to Autodesk, not sure if it will ever be supported, i even read this ext not recommended for generic use. GL_NV_fence - hopefully just need some path from kernel, but may be name 'fence' just mislead me. GL_NV_fog_distance - Francisco worked on fog sucessfully, hopefully he has something to add on this one. GL_NV_pixel_data_range - i don't meet this one yet GL_NV_point_sprite - nv version of point sprites ? GL_NV_register_combiners - mesa lacks support for this one GL_NV_vertex_array_range GL_NV_vertex_array_range2 - hopefully someday ... GL_NV_vertex_program GL_NV_vertex_program1_1 - again, should be not too hard in sw. GL_SGIS_multitexture - probably already enabled in hw, as early version of ARB_multitexture, may be with some differencies. GL_SUN_slice_accum - old extensions i know very little about ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29789] TALLOC_CFLAGS not used properly
https://bugs.freedesktop.org/show_bug.cgi?id=29789 --- Comment #2 from David Ronis 2010-09-19 12:18:11 PDT --- Folks, this should be trivial to fix, but hasn't been. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 29789] TALLOC_CFLAGS not used properly
https://bugs.freedesktop.org/show_bug.cgi?id=29789 David Ronis changed: What|Removed |Added Severity|major |critical -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] [PATCH] python/tests: Fixed tri.py for API and TGSI syntax changes.
Signed-off-by: Tilman Sauerbeck --- The same fix needs to be applied to a bunch of other Python scripts, but tri.py seems to be a good starting point. src/gallium/tests/python/samples/tri.py |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/gallium/tests/python/samples/tri.py b/src/gallium/tests/python/samples/tri.py index fed929d..6d17c88 100644 --- a/src/gallium/tests/python/samples/tri.py +++ b/src/gallium/tests/python/samples/tri.py @@ -88,8 +88,8 @@ def test(dev): # rasterizer rasterizer = Rasterizer() -rasterizer.front_winding = PIPE_WINDING_CW -rasterizer.cull_mode = PIPE_WINDING_NONE +rasterizer.front_ccw = False +rasterizer.cull_face = PIPE_FACE_NONE rasterizer.scissor = 1 ctx.set_rasterizer(rasterizer) @@ -161,8 +161,8 @@ def test(dev): # vertex shader vs = Shader(''' VERT -DCL IN[0], POSITION, CONSTANT -DCL IN[1], COLOR, CONSTANT +DCL IN[0] +DCL IN[1] DCL OUT[0], POSITION, CONSTANT DCL OUT[1], COLOR, CONSTANT 0:MOV OUT[0], IN[0] -- 1.7.2.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/docs: Fixed a typo in the SCS opcode description.
keith whitwell [2010-09-19 18:37]: > Looks good, thanks Tilman. Thanks, I've pushed the patch. > On Sun, Sep 19, 2010 at 8:24 AM, Tilman Sauerbeck > wrote: > > Signed-off-by: Tilman Sauerbeck > > --- > > src/gallium/docs/source/tgsi.rst | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/src/gallium/docs/source/tgsi.rst > > b/src/gallium/docs/source/tgsi.rst > > index e588c5b..4c1f47a 100644 > > --- a/src/gallium/docs/source/tgsi.rst > > +++ b/src/gallium/docs/source/tgsi.rst > > @@ -726,7 +726,7 @@ This instruction replicates its result. > > > > dst.z = 0 > > > > - dst.y = 1 > > + dst.w = 1 > > > > > > .. opcode:: TXB - Texture Lookup With Bias > > -- > > 1.7.2.3 > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpwLRr4Ae7q0.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30124] Mesa 7.9 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=30124 Bug 30124 depends on bug 30231, which changed state. Bug 30231 Summary: [i915g] undefined symbol: talloc_vasprintf_append https://bugs.freedesktop.org/show_bug.cgi?id=30231 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] Removing ARB_imaging subset extensions
On our way to OpenGL 3.0, it would be nice to clean out some of the optional deprecated features that Mesa supports. The ARB_imaging subset is the highest on my list -- it significantly clutters up the pixel path, and has always been optional even though the specification text got rolled into OpenGL 1.2. ATI's proprietary driver never supported the imaging subset, and what I've read of NVIDIA's implementation online, its presence is a user trap. Keeping an implementation of it is not helping our users from a performance or portability perspective. I've pushed a branch to my repo removing most of SGI_color_matrix, SGI_color_table, EXT_histogram, and EXT_convolution. Here's the diffstat: drivers/common/driverfuncs.c |2 drivers/common/meta.c | 82 -- drivers/dri/i965/brw_state_upload.c |1 drivers/dri/intel/intel_extensions.c |2 drivers/dri/intel/intel_tex_image.c | 20 drivers/dri/radeon/radeon_texture.c | 16 drivers/dri/savage/savagetex.c|3 drivers/dri/unichrome/via_tex.c | 22 main/attrib.c | 29 main/blend.c |6 main/colortab.c | 204 - main/colortab.h |7 main/context.c|8 main/convolve.c | 1307 -- main/convolve.h | 70 - main/dd.h |9 main/debug.c |3 main/dlist.c |2 main/enable.c | 89 -- main/extensions.c | 17 main/get.c| 76 - main/histogram.c | 971 - main/histogram.h |2 main/image.c | 141 --- main/image.h |5 main/matrix.c |6 main/mfeatures.h |1 main/mtypes.h | 125 --- main/pixel.c | 170 main/querymatrix.c|4 main/texcompress_fxt1.c |3 main/texcompress_s3tc.c |5 main/teximage.c | 62 - main/texstore.c | 210 - program/prog_statevars.c | 29 program/prog_statevars.h |3 state_tracker/st_atom_pixeltransfer.c | 130 --- state_tracker/st_cb_readpixels.c |3 state_tracker/st_cb_texture.c |6 state_tracker/st_extensions.c |1 swrast/s_copypix.c| 107 -- swrast/s_drawpix.c| 92 -- swrast/s_readpix.c| 59 - 43 files changed, 96 insertions(+), 4014 deletions(-) That's 2.7% of mesa/main/, and driver size dropped correspondingly. Note that we don't get to completely drop histogram.c and convolve.c, as we're supposed to have the entrypoints and just emit INVALID_OPERATION for the missing extensions even if the ARB_imaging subset isn't present. If we don't have any strong justification for keeping this code, I'd like to merge this to master. pgpJvdzyuOzOg.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Removing ARB_imaging subset extensions
On Sun, Sep 19, 2010 at 5:59 PM, Eric Anholt wrote: > On our way to OpenGL 3.0, it would be nice to clean out some of the > optional deprecated features that Mesa supports. The ARB_imaging subset > is the highest on my list -- it significantly clutters up the pixel > path, and has always been optional even though the specification text > got rolled into OpenGL 1.2. ATI's proprietary driver never supported > the imaging subset, and what I've read of NVIDIA's implementation > online, its presence is a user trap. Keeping an implementation of it is > not helping our users from a performance or portability perspective. > > I've pushed a branch to my repo removing most of SGI_color_matrix, > SGI_color_table, EXT_histogram, and EXT_convolution. Here's the > diffstat: > > drivers/common/driverfuncs.c | 2 > drivers/common/meta.c | 82 -- > drivers/dri/i965/brw_state_upload.c | 1 > drivers/dri/intel/intel_extensions.c | 2 > drivers/dri/intel/intel_tex_image.c | 20 > drivers/dri/radeon/radeon_texture.c | 16 > drivers/dri/savage/savagetex.c | 3 > drivers/dri/unichrome/via_tex.c | 22 > main/attrib.c | 29 > main/blend.c | 6 > main/colortab.c | 204 - > main/colortab.h | 7 > main/context.c | 8 > main/convolve.c | 1307 > -- > main/convolve.h | 70 - > main/dd.h | 9 > main/debug.c | 3 > main/dlist.c | 2 > main/enable.c | 89 -- > main/extensions.c | 17 > main/get.c | 76 - > main/histogram.c | 971 - > main/histogram.h | 2 > main/image.c | 141 --- > main/image.h | 5 > main/matrix.c | 6 > main/mfeatures.h | 1 > main/mtypes.h | 125 --- > main/pixel.c | 170 > main/querymatrix.c | 4 > main/texcompress_fxt1.c | 3 > main/texcompress_s3tc.c | 5 > main/teximage.c | 62 - > main/texstore.c | 210 - > program/prog_statevars.c | 29 > program/prog_statevars.h | 3 > state_tracker/st_atom_pixeltransfer.c | 130 --- > state_tracker/st_cb_readpixels.c | 3 > state_tracker/st_cb_texture.c | 6 > state_tracker/st_extensions.c | 1 > swrast/s_copypix.c | 107 -- > swrast/s_drawpix.c | 92 -- > swrast/s_readpix.c | 59 - > 43 files changed, 96 insertions(+), 4014 deletions(-) > > That's 2.7% of mesa/main/, and driver size dropped correspondingly. > Note that we don't get to completely drop histogram.c and convolve.c, as > we're supposed to have the entrypoints and just emit INVALID_OPERATION > for the missing extensions even if the ARB_imaging subset isn't present. > > If we don't have any strong justification for keeping this code, I'd > like to merge this to master. I am completely okay with this. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] draw_stream_output seems to be broken by design
On Sunday 19 September 2010 13:44:33 Luca Barbieri wrote: > The current version of draw_stream_output in softpipe seems to attempt > to draw using the currently bound stream output buffer as input. It's because I never had the time to actually test it properly. The interface is right though, the implementation is supposed to follow the D3D semantics and we should stick with that, instead of passing cso's and making behavior switch based on magic null arguments. z ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] draw_stream_output seems to be broken by design
> It's because I never had the time to actually test it properly. The interface > is right though, the implementation is supposed to follow the D3D semantics > and we should stick with that, instead of passing cso's and making behavior > switch based on magic null arguments. I think you need that to implement ARB_transform_feedback2. How would you implement this (note the id parameter) without a corresponding CSO parameter in Gallium? void DrawTransformFeedback(enum mode, uint id); Of course you can do it with a SO_STATISTICS queries, but it's awkward and requires the CPU to wait on the GPU (also, if the user is using such a query himself, it might be an issue). The NULL argument might be avoided, but that would cause D3D state trackers to need to track and keep alive the last stream output CSO, and might force the driver to unnecessarily write out the value to a buffer instead of just keeping it in an hardware register. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r300g: Always try to build libr300compiler.a
Make libr300compiler.a a PHONY target so that this library will always be built. This fixes the problem of libr300compiler.a not being updated when r300g is being built and r300c is not. This is a candidate for the Mesa 7.9 branch. --- src/gallium/drivers/r300/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/r300/Makefile b/src/gallium/drivers/r300/Makefile index 728bc40..66d900e 100644 --- a/src/gallium/drivers/r300/Makefile +++ b/src/gallium/drivers/r300/Makefile @@ -39,5 +39,6 @@ EXTRA_OBJECTS = \ include ../../Makefile.template +.PHONY: $(COMPILER_ARCHIVE) $(COMPILER_ARCHIVE): $(MAKE) -C $(TOP)/src/mesa/drivers/dri/r300/compiler -- 1.7.2.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Correction about GL_SUN_slice_accum
It is not as old as I was thinking http://www.opengl.org/registry/specs/SUN/slice_accum.txt $Date: 02/03/13 15:15:35 $Revision: 1.3 $ But extension itself talks about accumulation buffer(s)[0], they supported currently in software in mesa, and many old consumer-level cards seems don't have them implemented in hardware, unfortunately including old (pre-nv30) Nvidia cards, as far as i know . On nv30 and up accumulation buffer can be emulated, sort of. See [1], or [2] for 12-bit accumulation buffer. There was some interest in implementing accum. buffer in Mesa as metaop (?) or in mesa state tracker for Gallium drivers, but nothing come out, AFAIK. Sorry, can't find links right now [0] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.4497&rep=rep1&type=pdf - "The Accumulation Buffer: Hardware Support for High-Quality Rendering" [1] http://www.petewarden.com/notes/archives/2005/05/fragment_progra.html [2] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.9136&rep=rep1&type=pdf - "Complex Water Effects at Interactive Frame Rates" ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev