Re: [Mesa3d-dev] plumbing for gallium swrast_dri.so
I pushed this to master, swrastg_dri was added to the autoconf build system only. I also did a merge with gallium-resources for st/dri at ~gsap7/gallium-resources-merge-drisw, it basically reverts the old conversion, merges and redoes the conversion because there were a lot of conflicts, hope this is ok. regards, George. On Tue, Mar 23, 2010 at 6:52 PM, George Sapountzis gsapount...@gmail.com wrote: On Sun, Mar 14, 2010 at 12:25 PM, George Sapountzis gsapount...@gmail.com wrote: Hi, I put some patches at http://cgit.freedesktop.org/~gsap7/mesa/log/?h=gallium-drisw that do the plumbing in order to build the swrast_dri wrapper around gallium instead of classic mesa. For reference, swrast_dri is the fallback driver loaded by libGL (with LIBGL_ALWAYS_SOFTWARE) and xserver. It must not link with libdrm, nor use any drm headers during building because it is also used on platforms without drm. I updated the patches with the feedback from the list and added TODO items at the top of drisw.c with the remaining issues. I think it's in good state, given the scope of swrastg_dri.so, and would like to merge this to master. So please review and test, esp. DRI2 and scons (since I cannot test DRI2 and have a tendency to break the build system ...) There is also the issue of when to choose swrastg_dri.so over swrast_dri.so that should be handled by the loaders, just rename swrastg_dri.so to swrast_dri.so for now. regards, George. -- 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] plumbing for gallium swrast_dri.so
On Thu, Mar 25, 2010 at 9:49 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: On Thu, Mar 25, 2010 at 7:00 PM, George Sapountzis gsapount...@gmail.com wrote: On Thu, Mar 25, 2010 at 7:58 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: 0003 moves drisw into dri/sw and the drm dri files into dri/drm, yet again for clarity. 0004 moves the common files into a common directory. I think that it may be better to just consolidate dri_screen.c / dri_context.c / dri_drawable.c / dri_extension.c in a single file named dri.c or dri_api.c or dri_driver_api.c similar to the glx/xlib state_tracker. There is not much left in the above files after splitting out version-specific code. Then you will have: dri_api.c or dri_driver_api.c for the DRI window system binding dri_st_api.c and dri1.c dri2.c drisw.c for the different versions the only outlier is dri1_helper which I agree may have a better name. But then I looked at this a lot lately and your suggestion may be better for someone looking at it after some time. I think you can do both, the moving of the files is more for making it blatantly clear what is going on. The common files live in the common directory and the rest are in their own directory. This mirrors what is done in egl. I'm ambivalent about grouping the files together. And I don't think that moving them it a common directory stops us from doing either one. Then again dri_extension.c is quite useless, and should probably be moved into dri_screen either way. Are you strongly against the layout that I suggested? I have no real problem with doing both? Ah ok, then the suggested layout serves well its purpose. Wrt to consilidating in dri_driver_api.c (dri_util.c is effectively dri_api.c), it depends on what your plans are for st/dri and if it involves adding more common code, I don't have other plans for st/dri :-) I'll add a comment about the ifdef's (srceen / swap_buffers in dri_screen.c, flush_front / alloc_buffers in dri_st_api.c) and to drisw_util.h about its relationship to dri_util.h . One thing that could be done to reduce the amount of #ifdefs would be to move the tables from dri_screen.c into drisw.c and dri2.c. yes, this could be done unless the suggestion above is adopted, in which case I thinks it's probably better to keep all the dri_ functions static and the _DriverAPI tables in the common file. There is only one function that is static that is used in the tables, or are you meaning that we should make them static as we move all of them into a single file? yes, if we move them all to dri_driver_api.c then it makes more sense to make them static and keep _DriverAPI in dri_driver_api.c with an ifdef. -- 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] Current tinderbox regression (swrastg_dri, sparc64)
On Fri, Mar 26, 2010 at 2:23 AM, Chris Ball c...@laptop.org wrote: Hi, http://tinderbox.x.org/builds/2010-03-25-0018/logs/libGL/#build mklib: Making Linux shared library: swrastg_dri.so.tmp gcc -o swrastg_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o swrastg_dri.so.tmp -L/home/cjb/xorg-build/lib -ldrm -lexpat -lm -lpthread -ldl swrastg_dri.so.tmp: undefined reference to `__sync_sub_and_fetch_4' swrastg_dri.so.tmp: undefined reference to `__sync_add_and_fetch_4' (Only seen on sparc64.) my guess is that glapi uses sync primitives (see glthread.h) and the test is done against stubs which does not contain these primitives. it should be possible to build the real libglapi.a first (by adding a Makefile in src/mesa/glapi) and then do the link test using the real libglapi.a -- 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] plumbing for gallium swrast_dri.so
On Sun, Mar 14, 2010 at 12:25 PM, George Sapountzis gsapount...@gmail.com wrote: Hi, I put some patches at http://cgit.freedesktop.org/~gsap7/mesa/log/?h=gallium-drisw that do the plumbing in order to build the swrast_dri wrapper around gallium instead of classic mesa. For reference, swrast_dri is the fallback driver loaded by libGL (with LIBGL_ALWAYS_SOFTWARE) and xserver. It must not link with libdrm, nor use any drm headers during building because it is also used on platforms without drm. I updated the patches with the feedback from the list and added TODO items at the top of drisw.c with the remaining issues. I think it's in good state, given the scope of swrastg_dri.so, and would like to merge this to master. So please review and test, esp. DRI2 and scons (since I cannot test DRI2 and have a tendency to break the build system ...) There is also the issue of when to choose swrastg_dri.so over swrast_dri.so that should be handled by the loaders, just rename swrastg_dri.so to swrast_dri.so for now. regards, George. -- 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] New branch to switch st/dri to st_api.h
That was commit 9ec29e31919e85f9230867f43841c0e74be930d3 when doing a pristine build. I reverted it for now. On Sun, Mar 21, 2010 at 2:31 PM, STEVE555 stevenward...@hotmail.com wrote: Hi Chia-I Wu, I've just updated my copy of Mesa master today after your merge and the latest commits(from about 11:30 am GMT).I build Mesa with these configure options: ./configure --prefix=/usr --enable-32-bit --enable-xcb --enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif --enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga --with-max-width=4096 --with-max-height=4096 --enable-debug. I've used both gmake and make after ./configure,and Mesa keeps hitting this error when it tries to build the svga state-tracker: gmake[4]: Entering directory `/opt/mesa/src/gallium/drivers/svga' rm -f depend touch depend /usr/bin/makedepend -fdepend -I/usr/lib/gcc/i686-redhat-linux/4.4.3/include -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -I../../../../src/gallium/drivers/svga/include -std=gnu99 -fvisibility=hidden -DHAVE_STDINT_H -DHAVE_SYS_TYPES_H svgadump/svga_shader_dump.c svgadump/svga_shader_op.c svgadump/svga_dump.c svga_cmd.c svga_context.c svga_draw.c svga_draw_arrays.c svga_draw_elements.c svga_pipe_blend.c svga_pipe_blit.c svga_pipe_clear.c svga_pipe_constants.c svga_pipe_depthstencil.c svga_pipe_draw.c svga_pipe_flush.c svga_pipe_fs.c svga_pipe_misc.c svga_pipe_query.c svga_pipe_rasterizer.c svga_pipe_sampler.c svga_pipe_vertex.c svga_pipe_vs.c svga_screen.c svga_screen_buffer.c svga_screen_texture.c svga_screen_cache.c svga_state.c svga_state_need_swtnl.c svga_state_constants.c svga_state_framebuffer.c svga_state_rss.c svga_state_tss.c svga_state_vdecl.c svga_state_fs.c svga_state_vs.c svga_swtnl_backend.c svga_swtnl_draw.c svga_swtnl_state.c svga_tgsi.c svga_tgsi_decl_sm20.c svga_tgsi_decl_sm30.c svga_tgsi_insn.c 2 /dev/null gmake[4]: *** No rule to make target `depend', needed by `default'. Stop. gmake[4]: Leaving directory `/opt/mesa/src/gallium/drivers/svga' gmake[3]: *** [default] Error 1 gmake[3]: Leaving directory `/opt/mesa/src/gallium/drivers' gmake[2]: *** [default] Error 1 gmake[2]: Leaving directory `/opt/mesa/src/gallium' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/opt/mesa/src' make: *** [default] Error 1 Regards, STEVE555 Sedat Dilek wrote: On Sun, Mar 21, 2010 at 10:33 AM, Chia-I Wu olva...@gmail.com wrote: On Sun, Mar 21, 2010 at 5:19 PM, Sedat Dilek sedat.di...@googlemail.com wrote: [...] Even I see OpenArena got a boost from ~25fps (7.8 GIT) to ~32fps (master GIT incl. gallium-st-api-dri merge) $ cat oa_benchmark.txt s...@seduxbox:~/src/anholt_oa-benchmark$ openarena +exec anholt 21 | egrep -e '[0-9]+ frames' 840 frames 26.3 seconds 31.9 fps 9.0/31.3/90.0/9.9 ms Thanks for your work! Unless I have some magic power that I am not aware of, the boost should be attributed to r300g developers. I think, it is helpful to benchmark from time to time. I was comparing the both branches 7.8 and 7.9-devel in general and especiall r300g dri/st. Indeed, Chapeau to all contributors to r300g development. -- Sedat -- Download Intel® 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 -- View this message in context: http://old.nabble.com/New-branch-to-switch-st-dri-to-st_api.h-tp27940955p27975796.html Sent from the mesa3d-dev mailing list archive at Nabble.com. -- Download Intel® 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 -- 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
Re: [Mesa3d-dev] New branch to switch st/dri to st_api.h
On Sun, Mar 21, 2010 at 4:31 PM, Marek Olšák mar...@gmail.com wrote: Please do git pull --rebase origin instead of git pull origin to avoid Merge branch 'master' of ... commits. yes, i left them because the intervening commits happened between a local 'git clean -fdx' and a 'git push' ... to denote the point of the 'git clean -fdx', anyway ... -- 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] plumbing for gallium swrast_dri.so
On Sun, Mar 21, 2010 at 4:46 AM, Chia-I Wu olva...@gmail.com wrote: On Fri, Mar 19, 2010 at 09:57:41PM +0200, George Sapountzis wrote: The timing of the first attempt was unfortunate because it was in the middle of a re-factoring I had not realized it was happening. The good thing is that after the changes by Chia-I and Keith, implementing swrastg_dri.so is much simpler. I update the patches at the above branch, gallium swrast_dri.so works now with the following caveats: * stride: the driver and the loader compute the stride independently. They usually agree, but when you start resizing and they finally don't, you get a regular oblique image. If you run with valgrind, you also get a regular message the size of the mismatch, at each PutImage. * fences: i did not use any, are they needed for cell/llvmpipe ? Nice work. I haven't tried this, but I think there should be DRM_CREATE_DRISW and drisw_api.h, similar to how DRI1 is supported, and let winsys/drm decide which version to support. swrast will be the only one to support DRM_CREATE_DRISW. This will also give st/dri a chance to define whatever needed to swrast to implement displaytarget_display in drisw_api.h, both at drm_api::create_screen time and pipe_screen::flush_frontbuffer time. drisw_st_framebuffer_flush_front will then only prepare a pipe_surface for the given attachment and call pipe_screen::flush_frontbuffer. Similar to what st/glx is doing. This may also solve the resize issue. Ah ok, I see this is the right way to do it in gallium. The problem is that DRISW, similar to DRI2, will need to call the loader from the winsys, and from a quick look, this is not done for DRI2 either. So this probably will have to wait for the infrastructure to grow for DRI2 and DRISW will be adapted accordingly afterwards. Wrt the resize issue, solving it properly requires adding the stride as a parameter to the putImage hook of the DRISW loader extension. I committed an ugly workaround at ~gsap7/gallium-drisw which works for softpipe but I don't know when it will explode platform-, rendering- or performance-wise. If it is feasible, I think it is better to have st/dri support all three of DRI1/DRI2/DRISW at the same time when drm.h is available; And have st/dri support only DRISW when drm.h is not available. This will eliminate the need for st/drisw. Yes, it is feasible but it requires mingling with the mesa build system, which I am not too enthusiastic about :-) Thanks for your comments! George. -- 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] softpipe/llvmpipe build regression
Can you please try a clean build ? softpipe_create_screen is defined in the newly added file soft_screen.c and maybe you did not rebuild drm/sw If I actually broke this as well, admittedly I should have stayed away from the computer today On Sun, Mar 21, 2010 at 6:42 PM, Xavier Chantry chantry.xav...@gmail.com wrote: scons dri=no drivers=softpipe or llvmpipe glxgears: symbol lookup error: /home/xavier/app/mesa/build/linux-x86_64/lib/libGL.so.1: undefined symbol: gallium_soft_create_screen Works after these two reverts : Revert gallium: add soft screen helper This reverts commit f87a5f6499f51f651c2a9f2d4682875b22926905. Revert drm/sw: just s/softpipe_create_screen/gallium_soft_create_screen/ This reverts commit 5d524cce9c4fcc18ed977801d59ba7bb911020db. Am I doing something wrong or is it indeed still broken after f87a5f6 ? -- 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 -- 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] softpipe/llvmpipe build regression
On Sun, Mar 21, 2010 at 6:50 PM, George Sapountzis gsapount...@gmail.com wrote: Can you please try a clean build ? softpipe_create_screen is defined in the newly added file soft_screen.c and maybe you did not rebuild drm/sw s/softpipe_create_screen/gallium_soft_create_screen/ in the above sentence, only to confirm the statement below. If I actually broke this as well, admittedly I should have stayed away from the computer today -- 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] softpipe/llvmpipe build regression
On Sun, Mar 21, 2010 at 6:50 PM, George Sapountzis gsapount...@gmail.com wrote: Can you please try a clean build ? softpipe_create_screen is defined in the newly added file soft_screen.c and maybe you did not rebuild drm/sw If I actually broke this as well, admittedly I should have stayed away from the computer today On Sun, Mar 21, 2010 at 6:42 PM, Xavier Chantry chantry.xav...@gmail.com wrote: scons dri=no drivers=softpipe or llvmpipe glxgears: symbol lookup error: /home/xavier/app/mesa/build/linux-x86_64/lib/libGL.so.1: undefined symbol: gallium_soft_create_screen ah, this is the scons build, should be fixed in master now. sorry for that, it seems that I cannot read in addition to type today ... -- 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] Mesa (master): gallium: add soft screen helper
On Sun, Mar 21, 2010 at 7:43 PM, George Sapountzis gsapount...@gmail.com wrote: On Sun, Mar 21, 2010 at 7:22 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: George, This is basically a reproduction of a facility I had in target-helpers previously (swrast_screen.c or similar), which I removed after feedback from Jose that supporting it with scons created more ugliness than we saved in the C code. Ah ok, i was not aware of this This change breaks layering in the build system by making code in the utility libraries conditionally built depending on which targets we're supporting. Ideally the code in auxilliary wouldn't have any idea whether softpipe, llvmpipe or any other driver is out there. This commit did not build soft_screen.c with auxiliary but symlinked it at each target and build it there, I guess this is not pretty either. For the record, the scons build seemed to work (after getting broken) as reported by Xavier. For the meantime, I'd say just duplicate the function in the few places which use it. There aren't many currently. Longer term, I think we probably want a little targets/common or similar, rather than trying to bundle this into auxilliary. Ah ok, so it will be build once and all places will use the same software renderer by default. Ok, I just reverted the commit and the commits that fix it. It seems that there will be three places using it (libgl-xlib, drm/sw and drm/swrast). I'll give it a try some other day when I can read and type. -- 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] plumbing for gallium swrast_dri.so
On Sun, Mar 14, 2010 at 12:25 PM, George Sapountzis gsapount...@gmail.com wrote: Hi, I put some patches at http://cgit.freedesktop.org/~gsap7/mesa/log/?h=gallium-drisw that do the plumbing in order to build the swrast_dri wrapper around gallium instead of classic mesa. For reference, swrast_dri is the fallback driver loaded by libGL (with LIBGL_ALWAYS_SOFTWARE) and xserver. It must not link with libdrm, nor use any drm headers during building because it is also used on platforms without drm. The branch is to the point where glxinfo runs and needs some glue with __DRIswrastLoaderExtension in order to show something other than black windows. The problem is that there seems to be two places where to put the glue, either in st/.../dri_drawable.c or in ws/.../swrast_drm_api.c . Can someone more familiar with gallium take a look at the branch and provide hints ? The timing of the first attempt was unfortunate because it was in the middle of a re-factoring I had not realized it was happening. The good thing is that after the changes by Chia-I and Keith, implementing swrastg_dri.so is much simpler. I update the patches at the above branch, gallium swrast_dri.so works now with the following caveats: * stride: the driver and the loader compute the stride independently. They usually agree, but when you start resizing and they finally don't, you get a regular oblique image. If you run with valgrind, you also get a regular message the size of the mismatch, at each PutImage. * fences: i did not use any, are they needed for cell/llvmpipe ? There are some patches (mostly one-liners) at the start of the branch on other code, please take a look and object. regards, George. -- 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] plumbing for gallium swrast_dri.so
On Mon, Mar 15, 2010 at 3:11 AM, Ian Romanick i...@freedesktop.org wrote: If you're going to do this, please make a separate driver. Call it swrastg or something. I use swrast for testing new core Mesa features that I implement, and I don't want to be forced to muck about with Gallium to do that. sure, it will be called swrastg_dri.so and selected with LIBGL_GALLIUM_SOFTWARE or something with lowest priority. -- 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] plumbing for gallium swrast_dri.so
Hi, I put some patches at http://cgit.freedesktop.org/~gsap7/mesa/log/?h=gallium-drisw that do the plumbing in order to build the swrast_dri wrapper around gallium instead of classic mesa. For reference, swrast_dri is the fallback driver loaded by libGL (with LIBGL_ALWAYS_SOFTWARE) and xserver. It must not link with libdrm, nor use any drm headers during building because it is also used on platforms without drm. The branch is to the point where glxinfo runs and needs some glue with __DRIswrastLoaderExtension in order to show something other than black windows. The problem is that there seems to be two places where to put the glue, either in st/.../dri_drawable.c or in ws/.../swrast_drm_api.c . Can someone more familiar with gallium take a look at the branch and provide hints ? thanks, George. -- 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] glapi execmem [was Re: code generation for dynamic extensions broken ?]
On Wed, Mar 10, 2010 at 2:18 AM, George Sapountzis gsapount...@gmail.com wrote: It turned out that there were two bugs in glapi. One with using non-exec memory and the other with using an un-relocated function template for entry-point generation. I put fixes at: Since we are already generating static dispatch stubs for all known extensions, I guess we can add a few more static stubs and use them, instead of generating on-the-fly. I put an example about this in the getproc-debug branch, but I don't know if it's a good idea. I put a patch for using executable memory at: http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-execmem It just maps a single page with PROTO_EXEC and uses it as a backing store for generated entrypoints. Since there are many configure variables for glapi, please review and test. The variables are mostly: arch: x86, x86-64, sparc threading: tls, threads, no-threads I tested with tls on x86. Testing means comparing libGL from getproc-debug (based on master) vs. libGL from getproc-execmem-debug (based on getproc-execmem) and making sure new libGL either fixes or does not regress. To build libGL: configure ... make -C src/mesa/ libglapi.a make -C src/glx/ LD_PRELOAD=./lib/libGL.so.1.2 ./progs/demos/fbotexture regards, George. -- 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] code generation for dynamic extensions broken ?
On Mon, Mar 8, 2010 at 10:37 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 George Sapountzis wrote: I made a small test to test code genration for dynamic extensions in http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-test When using libGL + swrast_dri.so from getproc-test, the dynamic extensions code is not exercised and the test passes. When using libGL from mesa 7.7 and swrast_dri.so from getproc-test, the extension string does contain GL_MESA_test_extension but the test segfaults. There are a few places where this could break. - The generated dispatch stub function is wrong. - The dispatch offset used by the driver is wrong. - The dispatch remapping used by the driver is wrong. It turned out that there were two bugs in glapi. One with using non-exec memory and the other with using an un-relocated function template for entry-point generation. I put fixes at: http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-debug I also tested with libGL pretending to not know fbo extensions, the fbo* demos and tests render correctly. I get a warning about an invalid enum in RenderbufferStorageMultisample(target) but i don't know where it comes from and it does not affect rendering. Since we are already generating static dispatch stubs for all known extensions, I guess we can add a few more static stubs and use them, instead of generating on-the-fly. I put an example about this in the getproc-debug branch, but I don't know if it's a good idea. regards, George. -- 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] code generation for dynamic extensions broken ?
On Wed, Mar 10, 2010 at 2:18 AM, George Sapountzis gsapount...@gmail.com wrote: I also tested with libGL pretending to not know fbo extensions, the fbo* demos and tests render correctly. I get a warning about an invalid enum in RenderbufferStorageMultisample(target) but i don't know where it comes from and it does not affect rendering. ignore the warning, it's due to a forgotten debugging call to the first dynamic function assuming it's the test extension, which is not the case with fbo. -- 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] code generation for dynamic extensions broken ?
Some comments: e38a234.. shouldn't get merged as-is, right? I mean, there must be some sort of mesa_debug macro or similar, so that debug messages are configurable. ditto for d0b35e9. right. from getproc-cleaunp..getproc-debug only the two fixes will be merged d6c973c is a strange patch; the additions to GLAPI_SOURCES seem unrelated to the patch itself. mesa_exec_malloc is defined in the added sources from main/ 977d5d: it seems like there should be some other way to disable this. I've been trying to make time to have these XMLs be exhaustive in their coverage of GL and GLX extensions, for example, which is good for other reasons. that was in order to test adding fbo extensions on-the-fly, not intended for merging. Most importantly: have you tested with mangled symbols (compile w/ USE_MGL_NAMESPACE defined)? It looks like the functions added in 682971c need #ifdef MANGLE cases. the commit just moves code. I guess get_extension_proc() needs ifdef's for mangle similar to get_static_proc(), but that can be fixed separately thanks, George. -- 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] code generation for dynamic extensions broken ?
Hi, I made a small test to test code genration for dynamic extensions in http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-test When using libGL + swrast_dri.so from getproc-test, the dynamic extensions code is not exercised and the test passes. When using libGL from mesa 7.7 and swrast_dri.so from getproc-test, the extension string does contain GL_MESA_test_extension but the test segfaults. It seems that dynamic extensions code is broken (since at least 7.7), unless there is something wrong with the test or my arch: model name : AMD Athlon(tm) XP 2200+ flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up regards, George. -- 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] Build error messages in building Progs/Tests
should be fixed now in master On Thu, Mar 4, 2010 at 4:21 PM, STEVE555 stevenward...@hotmail.com wrote: I've got closer in solving my problem to get progs/tests to build.Here's what I did: I edited my ld.so.conf and and put just one space under the code in there /usr and /usr/lib directly underneath. I then ran ldconfig.Then I opened up Konsole as root on the Mesa folder and I ran these commands: export LD__LIBRARY_PATH=/usr export PKG_CONFIG_PATH=/usr I pressed return on both of those commands,did a gmake -B realclean..I also did a git pull origin to get the latest commits. I then issued my new ./confiigure options: ./configure --prefix=/usr --enable-32-bit --enable-xcb --enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif --enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga --with-max-width=4096 --with-max-height=4096 Then I ran gmake.The build got past the error I posted earlier,,but it stops at this new error: gcc -I. -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 fptest1.c -L../../lib -lglut -lGLEW -lGLU -lGL -lm -o fptest1 gcc -I. -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 fptexture.c -L../../lib -lglut -lGLEW -lGLU -lGL -lm -o fptexture python getprocaddress.py getproclist.h Traceback (most recent call last): File getprocaddress.py, line 8, in module import gl_XML ImportError: No module named gl_XML gmake[2]: *** [getproclist.h] Error 1 gmake[2]: Leaving directory `/opt/mesa/progs/tests' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/opt/mesa/progs' gmake: *** [default] Error 1 I''ve noticed thhat there is a patch named Fix syntax screw ups introduced in 016fc30, 6e8e4b9 and f7dde2c both on Nabble and in my Hotmail account,I''m thinking about applying that patch and see if it fixes the problem. Regards, STEVE555 STEVE555 wrote: Here is some additional information when I was trying to build Mesa with the latest commits today: gcc -c -I. -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 arraytexture.c -o arraytexture.o gcc -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 arraytexture.o readtex.o -L../../lib -lglut -lGLEW -lGLU -lGL -lm -o arraytexture gcc -I. -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 auxbuffer.c -L../../lib -lglut -lGLEW -lGLU -lGL -lm -o auxbuffer auxbuffer.c: In function ‘event_loop’: auxbuffer.c:422: warning: implicit declaration of function ‘glWindowPos2iARB’ /usr/bin/ld: /tmp/cchlqm9X.o: undefined reference to symbol 'XLookupKeysym' /usr/bin/ld: note: 'XLookupKeysym' is defined in DSO /usr/lib/libX11.so.6 so try adding it to the linker command line /usr/lib/libX11.so.6: could not read symbols: Invalid operation collect2: ld returned 1 exit status gmake[2]: *** [auxbuffer] Error 1 gmake[2]: Leaving directory `/opt/mesa/progs/tests' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory
Re: [Mesa3d-dev] Build failure in glapi/glapi.c
On Tue, Mar 2, 2010 at 12:38 AM, Johannes Obermayr johannesoberm...@gmx.de wrote: Latest mesa does not compile. Thanks. Johannes gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include -I../../src/gallium/auxiliary -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 state_tracker/st_texture.c -o state_tracker/st_texture.o gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include -I../../src/gallium/auxiliary -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 glapi/glapi.c -o glapi/glapi.o glapi/glapi.c: In function '_glapi_check_multithread': glapi/glapi.c:178: error: expected expression before 'void' glapi/glapi.c:178: error: too many arguments to function '_glapi_init_multithread' glapi/glapi.c:180: error: expected ';' before 'knownID' gmake[2]: *** [glapi/glapi.o] Error 1 gmake[2]: *** Waiting for unfinished jobs gmake[2]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/mesa' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/usr/src/packages/BUILD/Mesa/src' make: *** [default] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.IlpHA4 (%build) Should be fixed in master. Sorry for that and thanks to Jose for fixing it. -- 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] [PATCH] Build failure in glapi/glapi_getproc.c
that was me, should compile now On Tue, Mar 2, 2010 at 3:22 AM, Mike Stroyan m...@lunarg.com wrote: The recent changes to _glapi_check_table included building the full version build every time. That broke builds for OpenGL ES1 and OpenGL ES2. They don't have all of the table members that OpenGL does. This first broke in commit 42f3241e04b6cd74829dfb64b4a154ac8a4e6a48 in glapi/glapi.c. But the problem function moved from glapi/glapi.c to glapi/glapi_getproc.c in commit fae5758fac963ce014e3d43f1bca7fb489e02bf9 . -- Mike Stroyan - Software Architect LunarG, Inc. - The Graphics Experts Cell: (970) 219-7905 Email: m...@lunarg.com Website: http://www.lunarg.com -- 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 -- 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] glapi cleanups
Hi, I did some glapi cleanups at http://cgit.freedesktop.org/~gsap7/mesa/log/?h=glapi-cleanup . Please review. regards, George. -- 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] glapi: mode code generation to subdir
Hi, I put 3 patches in http://people.freedesktop.org/~gsap7/glapi/ that mv the code generation functionality in the gen subdir. Please review, regards, George. -- 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] [PATCH 0/2] Make GLX optional in libGL
2010/2/8 Kristian Høgsberg k...@bitplanet.net: 2010/2/6 Chia-I Wu olva...@gmail.com: We can then build libGL.so with or without libglx.a depending on the configure optins. Later, src/mesa/drivers/x11/ could be changed to build libglxsw.a. We will be able to choose between 3 flavors of libGL.so, or choose all of them (to catch build failure) I wanted to do something similar, but the problem is: where do you build libGL? And glx is part of libGL so it's consistent to call the directory src/gl. And I don't think it's worth the effort to make it possible to plug in different glx implementations, we already have the dri sw driver as well as server side sw fallback for glx. What about the following: when --disable-glx is defined do not visit src/glx at all and build libGL alongside libEGL (from within src/egl/main ?). The above is consistent with the mesa pattern of building glapi and then using it from each window system subdir/driver, and probably causes less churn than the current patch. Multiple libGL's probably requires building from src/mesa/glapi but that's probably predicated on cleaning the code generation stuff. I think the above cuts it for now. And please leave GLX code under src/glx. regards, George. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
