[Mesa3d-dev] [Bug 27514] New: implementation error: Unsupported opcode 79 (TEX) in vertex shader
https://bugs.freedesktop.org/show_bug.cgi?id=27514 Summary: implementation error: Unsupported opcode 79 (TEX) in vertex shader Product: Mesa Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: musteres...@googlemail.com Hi there :) I just wanted to report a bug (if it is) to you. It happens on my up to date Ubuntu Lucid 64bit which is running on my laptop (which is a lenovo ibm thinkpad T500 with intel graphics module i915) When using the openscenegraph sample application shipped with the distributions package, i encounter the following error: osgshaderterrain Creating terrain...done. Mesa 7.7.1-DEVEL implementation error: Unsupported opcode 79 (TEX) in vertex shader Please report at bugzilla.freedesktop.org Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,) do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try adjusting the vblank_mode configuration parameter. The do_wait line appears with every sample. The programm does not crash, it just shows the terrain which would normally have shaders applied, but which is now black and with flickering black bars in z direction (so called up) I don't know if that will help you any further, but if you need more information, here i am ;) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 27514] implementation error: Unsupported opcode 79 (TEX) in vertex shader
https://bugs.freedesktop.org/show_bug.cgi?id=27514 --- Comment #1 from Daniel Oertwig musteres...@googlemail.com 2010-04-07 06:59:26 PDT --- Mesa package version is 7.7-4ubuntu1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 27514] implementation error: Unsupported opcode 79 (TEX) in vertex shader
https://bugs.freedesktop.org/show_bug.cgi?id=27514 Roland Scheidegger srol...@vmware.com changed: What|Removed |Added Component|Mesa core |Drivers/DRI/i965 AssignedTo|mesa3d-...@lists.sourceforg |e...@anholt.net |e.net | --- Comment #2 from Roland Scheidegger srol...@vmware.com 2010-04-07 07:12:09 PDT --- This message is coming from the i965 dri driver, which does not implement vertex texturing. Unless I'm mistaken though the driver always said it didn't support vertex texturing (what does glxinfo -l say about number of vertex texture units), hence this would actually be an application bug if it still tries to use vertex texturing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Tue, 2010-04-06 at 03:28 -0700, Keith Whitwell wrote: On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote: There's something fishy in u_upload_mgr, could you please review the first two patches here? http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources With this, r300g works again. Hmm, I think the second of the patches (flush range relative to mapped range vs whole buffer) may be addressing a regression that has creeped into the -resources branch regarding this behaviour - ie. I think the code you modified was actually correct, but that pipe_flush_mapped_buffer_range() has changed to do the wrong thing. I'll try and figure out what should be happening. I've pushed a change which hopefully corrects the behaviour of the buffer_range inlines. Can you give it a try? Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] gallium in 7.8.1 failing to build on SnowLeopard
I have another build failure reported to me for gallium on OSX. Any thoughts? Here's the full log: https://trac.macports.org/attachment/ticket/24393/mesa_7.8.1_SnowLepard.txt /bin/sh ../../../../bin/mklib -o OpenVG -linker '/usr/bin/gcc-4.2 ' -ldflags '' \ -major 1 \ -minor 0 \ -patch 0 \ -install ../../../../lib \ api_context.o api_filters.o api_images.o api_masks.o api_misc.o api_paint.o api_params.o api_path.o api_text.o api_transform.o vgu.o vg_context.o vg_state.o vg_tracker.o vg_translate.o polygon.o bezier.o path.o paint.o arc.o image.o renderer.o stroker.o mask.o shader.o shaders_cache.o ../../../../src/gallium/auxiliary/libgallium.a -lm mklib: Making Darwin shared library: libOpenVG.1.0.dylib Undefined symbols: _util_format_read_4f, referenced from: _pipe_tile_raw_to_rgba in libgallium.a(u_tile.o) _util_format_write_4f, referenced from: _pipe_put_tile_rgba in libgallium.a(u_tile.o) _util_format_description, referenced from: _create_texture in vg_tracker.o _create_texture in vg_tracker.o __vega_unpack_float_span_rgba in vg_translate.o __vega_unpack_float_span_rgba in vg_translate.o __vega_unpack_float_span_rgba in vg_translate.o __vega_unpack_float_span_rgba in vg_translate.o _pipe_put_tile_raw in libgallium.a(u_tile.o) _pipe_put_tile_raw in libgallium.a(u_tile.o) _pipe_put_tile_raw in libgallium.a(u_tile.o) _pipe_get_tile_raw in libgallium.a(u_tile.o) _pipe_get_tile_raw in libgallium.a(u_tile.o) _pipe_get_tile_raw in libgallium.a(u_tile.o) _pipe_tile_raw_to_rgba in libgallium.a(u_tile.o) _pipe_tile_raw_to_rgba in libgallium.a(u_tile.o) _pipe_tile_raw_to_rgba in libgallium.a(u_tile.o) _pipe_get_tile_rgba in libgallium.a(u_tile.o) _pipe_get_tile_rgba in libgallium.a(u_tile.o) _pipe_get_tile_rgba in libgallium.a(u_tile.o) _pipe_get_tile_rgba in libgallium.a(u_tile.o) _pipe_get_tile_rgba in libgallium.a(u_tile.o) _pipe_put_tile_rgba in libgallium.a(u_tile.o) _pipe_put_tile_rgba in libgallium.a(u_tile.o) _pipe_put_tile_rgba in libgallium.a(u_tile.o) _pipe_put_tile_rgba in libgallium.a(u_tile.o) _pipe_put_tile_rgba in libgallium.a(u_tile.o) _pipe_put_tile_rgba in libgallium.a(u_tile.o) _pipe_put_tile_rgba in libgallium.a(u_tile.o) _pipe_put_tile_rgba in libgallium.a(u_tile.o) _util_copy_rect in libgallium.a(u_rect.o) _util_copy_rect in libgallium.a(u_rect.o) _util_copy_rect in libgallium.a(u_rect.o) _util_copy_rect in libgallium.a(u_rect.o) _util_copy_rect in libgallium.a(u_rect.o) _util_fill_rect in libgallium.a(u_rect.o) _util_fill_rect in libgallium.a(u_rect.o) _util_fill_rect in libgallium.a(u_rect.o) _util_fill_rect in libgallium.a(u_rect.o) _util_fill_rect in libgallium.a(u_rect.o) _util_surface_fill in libgallium.a(u_rect.o) _util_format_write_4ub, referenced from: _util_pack_color_ub in vg_translate.o ld: symbol(s) not found collect2: ld returned 1 exit status mklib: Installing libOpenVG.1.0.dylib libOpenVG.1.dylib libOpenVG.dylib in ../../../../lib mv: rename libOpenVG.1.0.dylib to ../../../../lib/libOpenVG.1.0.dylib: No such file or directory make[4]: *** [../../../../lib/libOpenVG.so] Error 1 make[3]: *** [subdirs] Error 1 make[2]: *** [default] Error 1 make[1]: *** [subdirs] Error 1 make: *** [default] Error 1 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Wed, Apr 7, 2010 at 7:01 PM, Keith Whitwell kei...@vmware.com wrote: On Tue, 2010-04-06 at 03:28 -0700, Keith Whitwell wrote: On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote: There's something fishy in u_upload_mgr, could you please review the first two patches here? http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resourceshttp://cgit.freedesktop.org/%7Emareko/mesa/log/?h=gallium-resources With this, r300g works again. Hmm, I think the second of the patches (flush range relative to mapped range vs whole buffer) may be addressing a regression that has creeped into the -resources branch regarding this behaviour - ie. I think the code you modified was actually correct, but that pipe_flush_mapped_buffer_range() has changed to do the wrong thing. I'll try and figure out what should be happening. I've pushed a change which hopefully corrects the behaviour of the buffer_range inlines. Can you give it a try? Now glean/bufferObject fails on softpipe and r300g. I haven't tested other drivers. -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Tue, Apr 6, 2010 at 10:47 PM, Keith Whitwell kei...@vmware.com wrote: On Fri, 2010-04-02 at 20:43 -0700, Dave Airlie wrote: Just going down the r300g piglit failures and noticed fbo-drawbuffers failed, I've no idea if this passes on Intel hw, but it appears the texenvprogram really needs to understand the draw buffers. The attached patch fixes it here for me on r300g anyone want to test this on Intel with the piglit test before/after? Dave. This change makes sense looks good to me. Thanks pushed to 7.8. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
