Re: [Mesa3d-dev] [PATCH] dri/nouveau: Adjust to latest libdrm
On Wed, 2010-02-17 at 11:21 +1000, Ben Skeggs wrote: > On Tue, 2010-02-16 at 21:30 +0100, Johannes Obermayr wrote: > > Mesa compiles now in dri/nouveau (without compiler warnings). > Thanks for this, I completely forgot about the legacy driver not being > in my default build. > > Rather than using (chan->end - chan->cur), using AVAIL_RING(chan) is > preferred. I made that change and pushed the patch. Thank you! Ben. > > Ben. > > > > 1. Do the same as Ben Skeggs did with commit "nouveau: fix for latest > > libdrm" on Gallium > > 2. "chan->pushbuf->remaining" is now "chan->end - chan->cur" (see libdrm > > commit "nouveau: interface changes for 0.0.16 DRM") > > 3. Compiled successfully for openSUSE 11.2 and Factory (i586 and x86_64) > > 4. Tested with my GeForce2 GTS (NV15) > > 4.1 glxinfo tells that it is accelerated > > 4.2 glxinfo ~1000 FPS (without screen corruption) > > 4.3 kubrick has screen corruption (gray cubies and horizontal lines) and > > makes system so slow that I must press reset button. I do not know whether > > it was before because my main card is a GeForce 5600FX (NV31) and I > > installed my NV15 only a few minutes for testing this patch... > > > > Please commit it if it is proper... > > -- > > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > > http://p.sf.net/sfu/solaris-dev2dev > > ___ Mesa3d-dev mailing list > > Mesa3d-dev@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > > -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] dri/nouveau: Adjust to latest libdrm
On Tue, 2010-02-16 at 21:30 +0100, Johannes Obermayr wrote: > Mesa compiles now in dri/nouveau (without compiler warnings). Thanks for this, I completely forgot about the legacy driver not being in my default build. Rather than using (chan->end - chan->cur), using AVAIL_RING(chan) is preferred. Ben. > > 1. Do the same as Ben Skeggs did with commit "nouveau: fix for latest libdrm" > on Gallium > 2. "chan->pushbuf->remaining" is now "chan->end - chan->cur" (see libdrm > commit "nouveau: interface changes for 0.0.16 DRM") > 3. Compiled successfully for openSUSE 11.2 and Factory (i586 and x86_64) > 4. Tested with my GeForce2 GTS (NV15) > 4.1 glxinfo tells that it is accelerated > 4.2 glxinfo ~1000 FPS (without screen corruption) > 4.3 kubrick has screen corruption (gray cubies and horizontal lines) and > makes system so slow that I must press reset button. I do not know whether it > was before because my main card is a GeForce 5600FX (NV31) and I installed my > NV15 only a few minutes for testing this patch... > > Please commit it if it is proper... > -- > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > ___ Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Build failure in Mesa
On Tue, 2010-02-16 at 09:25 +0100, Johannes Obermayr wrote: > Hi, > > Ben Skeggs latest changes in Mesa cause a build failure (libdrm is latest git > ...). Rebuild latest libdrm from git, you'll also need an updated kernel module. Ben. > > Thanks. > Johannes > > gmake[3]: Entering directory `/usr/src/packages/BUILD/Mesa/src/mesa/drivers' > gmake[4]: Entering directory > `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri' > sed -e 's,@INSTALL_DIR@,/usr,' -e 's,@INSTALL_LIB_DIR@,/usr/lib,' -e > 's,@INSTALL_INC_DIR@,/usr/include,' -e 's,@VERSION@,7.8.0,' -e > 's,@DRI_DRIVER_DIR@,/usr/lib/dri,' -e 's,@DRI_PC_REQ_PRIV@,libdrm >= 2.4.15,' > dri.pc.in > dri.pc > gmake[5]: Entering directory > `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/nouveau' > running /usr/bin/makedepend > gmake[5]: Leaving directory > `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/nouveau' > gmake[5]: Entering directory > `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/nouveau' > gmake[6]: Entering directory > `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/nouveau' > gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver > -I../../../../../include -I../../../../../src/mesa > -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri > -I/usr/include/drm-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 -I/usr/include/drm > -I/usr/include/nouveau../common/utils.c -o ../common/utils.o > gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver > -I../../../../../include -I../../../../../src/mesa > -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri > -I/usr/include/drm-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 -I/usr/include/drm > -I/usr/include/nouveau../common/vblank.c -o ../common/vblank.o > gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver > -I../../../../../include -I../../../../../src/mesa > -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri > -I/usr/include/drm-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 -I/usr/include/drm > -I/usr/include/nouveau../common/dri_util.c -o ../common/dri_util.o > gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver > -I../../../../../include -I../../../../../src/mesa > -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri > -I/usr/include/drm-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 -I/usr/include/drm > -I/usr/include/nouveau../common/xmlconfig.c -o ../common/xmlconfig.o > gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver > -I../../../../../include -I../../../../../src/mesa > -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri > -I/usr/include/drm-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 -I/usr/include/drm > -I/usr/include/nouveau../common/texmem.c -o ../common/texmem.o > gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver > -I../../../../../include -I../../../../../src/mesa > -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri > -I/usr/include/drm-g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math > -fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX
Re: [Mesa3d-dev] Gallium feature levels
On Tue, 2010-01-12 at 11:01 -0500, Younes Manton wrote: > On Tue, Jan 12, 2010 at 9:44 AM, Keith Whitwell wrote: > > On Tue, 2010-01-12 at 06:33 -0800, Roland Scheidegger wrote: > >> >>> > >> >>> Profile 7 (2009)6 (2008) > >> 5 > >> >>> (2006)4 (2004)3 (2003)2 (2002) 1 > >> (2000) > >> >>> Fragment Shader Yes Yes > >> Yes > >> >>> Yes Yes Yes Yes > >> >> DX 7 didn't have any shader model IIRC. DX8/8.1 introduced shader > >> models > >> >> 1.0-1.3/1.4. > >> > > >> > Yea, that level should be gone. > >> Though thinking about this, maybe we should keep a level below lowest > >> dx9 feature level, since gallium drivers exist which are pretty low on > >> the feature scale (like the nv04/10/20). I don't know how well they'll > >> ever going to work, since they'd need the fixed function fragment > >> operations out of tgsi, but maybe we shouldn't prevent it by forcing > >> them to announce support of fragment shaders. > > > > The base level of gallium functionality included fragment shaders from > > the start, these early nv drivers don't really change that. > > > > In my view these are a speculative bet that with a lot of effort it is > > possible to turn shaders back into fixed-function, but supporting that > > isn't a design goal for gallium as a whole. > > > > Keith > > Just my opinion, > > I wouldn't count on nv04-nv20 actually staying in gallium. At some > point we wanted to experiment with shaders on fixed func, but I don't > think anyone is really motivated or optimistic that it will turn out > well. They're already rotting as it is. Francisco Jerez is working on > a classic Mesa driver for these and if/when they're worth pushing to > master I'd expect the gallium drivers to be axed. Agreed. IMO they could be removed now, I don't see them ever being done, and Francisco's drivers are shaping up quite nicely already. Ben. > > -- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] st/dri: no need to request fake front buffer
On Wed, 2009-12-30 at 18:45 +0100, Thomas Hellstrom wrote: > Ben, Hey Thomas, > > Your commit 1336989ec breaks front buffer rendering on Xserver < 1.7. > > Shouldn't the change that silently added a fake front attachment have > been accompanied by a bump in SERVER_DRI2_MINOR_VERSION to signal a new > capability? Then we could have inserted some conditional code... > > The way tfp is handled in the xorg state tracker is that when it detects > a fake front request on a pixmap it actually hands it the real front, > which makes the code work also on older servers. I can't recall the exact details at the moment, but from discussion with a couple of people the xorg state tracker is doing the wrong thing. The client should never get handed the real front buffer in DRI2, all requests for front should hand a fake front back. If you don't look at it beforehand I'll try and remember to look at it again when I get back into the office on the 4th. The commit in question fixed gallium drivers for Nouveau (and r300 would have been effected too, but I don't have the hardware to test) and EXT_tfp. From the looks of it any DDX that wasn't the xorg state tracker would have been broken. Ben. > > /Thomas > > > > > -- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] gallium-blitter
On Mon, 2009-11-16 at 14:59 +0100, Christoph Bumiller wrote: > Corbin Simpson schrieb: > > URL: > > http://cgit.freedesktop.org/~csimpson/mesa/log/?h=gallium-blitter > > > > So, with r600g right around the corner, I'd like to do something about > > this blitter/no blitter thing. > > > > This patch series contains one new getparam, PIPE_CAP_BLITTER, and a > > proposed ABI change to accompany it. > > > > surface_copy and surface_fill are proposed to have a way of indicating > > whether or not they successfully performed the fill/blit. It is up to > > the state tracker to determine whether or not to rely on these functions. > > > > Issues: > > - Should clear be included with these two? I don't think any drivers are > > doing anything with clear except wiring it up to util_clear... > Just wanted to mention nv50 actually has a special hardware clear path, > which > supports separate R/G/B/A/Z/S clear and respects scissors, it doesn't > use util_clear. As do most (all?) of the previous generations of nv hardware. > > -- > > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > > is the only developer event you need to attend this year. Jumpstart your > > developing skills, take BlackBerry mobile applications to market and stay > > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > > http://p.sf.net/sfu/devconference > > ___ > > Mesa3d-dev mailing list > > Mesa3d-dev@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > > > > > -- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Nouveau git drm git, mesa 7.5 git, xbmc crash and kwin crash
On Sat, 2009-05-16 at 09:44 +0200, Eric Valette wrote: > Younes Manton wrote: > > >> However, I have a permanent, always reproducible crash running xbmc > > > > Mesa driver is not stable or ready for end users so things like this > > are normal at the moment. > > Very constructive answer when I see 7.5 is at RC2... The nouveau driver is not intended to be built. If it's enabled in the default build, perhaps that should be changed. Ben. > > --eric > > > > > -- > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): nouveau: rewrite winsys in terms of drm_api, support dri2 state tracker
On Wed, 2009-03-18 at 09:04 +, Keith Whitwell wrote: > On Tue, 2009-03-17 at 18:15 -0700, Ben Skeggs wrote: > > Module: Mesa > > Branch: master > > Commit: e00ae524e236afba1305150cacd634eaa1f5460b > > URL: > > http://cgit.freedesktop.org/mesa/mesa/commit/?id=e00ae524e236afba1305150cacd634eaa1f5460b > > > > Author: Ben Skeggs > > Date: Wed Mar 18 08:22:35 2009 +1000 > > > > nouveau: rewrite winsys in terms of drm_api, support dri2 state tracker > > > > drm_api is a set of hooks used by the dri2 state tracker, this wraps our > > dri1 code around the same set of hooks. > > > > Currently the dri2 build will produce nouveau_dri2.so which you'll need > > to install as nouveau_dri.so if you wish to try it. The dri2 state > > tracker doesn't make it easy for a driver to support both paths in the > > same binary. > > I'd like to see the glx/dri state tracker restore support for both dri1 > and dri2. That may lead to some slightly less-clean interfaces, but the > reality is that dri1 continues to be important for driver developers... Indeed, I'm 100% for this as well and had planned on talking to you guys to see how you wanted to achieve this :) Ben. > > If there's a real reason for a dri2-only entity, that could be supported > separately, but I think most people at this stage want to be supporting > both. > > Keith > > -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): nv50: rework for texture_transfer changes
On Fri, 2009-02-20 at 10:17 +0100, Michel Dänzer wrote:
> On Thu, 2009-02-19 at 23:58 -0800, Ben Skeggs wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 63a3a3762c8e1a67666d36b35fdb0ada8e4b7d08
> > URL:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=63a3a3762c8e1a67666d36b35fdb0ada8e4b7d08
> >
> > Author: Ben Skeggs
> > Date: Fri Feb 20 09:32:47 2009 +1000
> >
> > nv50: rework for texture_transfer changes
>
> Thanks for this, and sorry for any inconvenience the transfer changes
> may have caused.
No problems at all. I'll probably have a shot a fixing up the other
nouveau pipe drivers tomorrow if I get the chance and noone else beats
me to it.
>
>
> > +static void
> > +nv50_transfer_unmap(struct pipe_screen *pscreen, struct pipe_transfer *ptx)
> > +{
> > + struct nv50_transfer *tx = (struct nv50_transfer *)ptx;
> > + struct nv50_miptree *mt = nv50_miptree(ptx->texture);
> > +
> > + if (ptx->usage != PIPE_TRANSFER_READ) {
> > + nv50_transfer_rect_m2mf(pscreen, tx->buffer,
> > tx->base.stride,
> > + 0, 0, tx->base.width,
> > tx->base.height,
> > + mt->buffer, tx->level_pitch,
> > + tx->level_x, tx->level_y,
> > + tx->level_width, tx->level_height,
> > + tx->base.block.size, tx->base.width,
> > + tx->base.height, NOUVEAU_BO_GART,
> > + NOUVEAU_BO_VRAM | NOUVEAU_BO_GART);
> > + }
> > +
> > + pipe_buffer_unmap(pscreen, mt->buffer);
> > +}
>
> BTW, you may want to defer the upload to transfer destruction time, in
> case the state tracker were to map/unmap the transfer several times.
Ah, thanks for that. The thought crossed my mind while I was writing
it, and got forgotten!
Ben.
>
>
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Nouveau] Memory corruption on Gallium window resize, diagnosed?
Am Mittwoch, den 12.11.2008, 00:26 +0200 schrieb Pekka Paalanen:
> Hi,
>
> I've been playing with nouveau/mesa branch gallium-0.1, trying to get
> trivial/tri working on nv20 (with nv10 code). When ever I resize the window,
> it ends up in an assert failure:
Hey,
I fixed nv4x recently, gallium-0.2 branch...
Ben.
>
> #0 0xf790744f in _debug_assert_fail (expr=0xf791908f "0", file=0xf7919050
> "nv20_state_emit.c", line=139,
> function=0xf7919034 "nv20_state_emit_framebuffer") at p_debug.c:335
> #1 0xf76fe723 in nv20_state_emit_framebuffer (nv20=0x805ef68) at
> nv20_state_emit.c:139
> #2 0xf76fef2e in nv20_emit_hw_state (nv20=0x805ef68) at nv20_state_emit.c:255
> #3 0xf76ff70b in nv20_draw_elements (pipe=0x805ef68, indexBuffer=0x0,
> indexSize=0, prim=4, start=0, count=3) at nv20_vbo.c:20
> #4 0xf76ff922 in nv20_draw_arrays (pipe=0x805ef68, prim=4, start=0, count=3)
> at nv20_vbo.c:73
> #5 0xf7743ac8 in st_draw_vbo (ctx=0x8074d18, arrays=0x80ade38,
> prims=0x80ac994, nr_prims=1, ib=0x0, min_index=0, max_index=2)
> at state_tracker/st_draw.c:634
> #6 0xf782c140 in vbo_exec_vtx_flush (exec=0x80ac870) at
> vbo/vbo_exec_draw.c:248
> #7 0xf782a858 in vbo_exec_FlushVertices (ctx=0x8074d18, flags=1) at
> vbo/vbo_exec_api.c:752
> #8 0xf7761f39 in _mesa_Flush () at main/context.c:1815
> #9 0xf7e00ae6 in glFlush () at ../../../src/mesa/glapi/glapitemp.h:1170
> #10 0x08048dba in Draw () at tri.c:83
> #11 0xf7ecdc54 in processWindowWorkList (window=0x8051200) at
> glut_event.c:1302
> #12 0xf7ecdd3a in __glutProcessWindowWorkLists () at glut_event.c:1354
> #13 0xf7ecddb1 in glutMainLoop () at glut_event.c:1375
> #14 0x08048fd8 in main (argc=1, argv=0xfff760e4) at tri.c:132
>
> The struct pipe_surface used there contains garbage:
>
> (gdb) print *fb->cbufs[0]
> $4 = {buffer = 0xf7d901a0, format = -136773216, status = 1, clear_value = 0,
> width = 189, height = 181, block = {size = 4, width = 1,
> height = 1}, nblocksx = 189, nblocksy = 181, stride = 768, layout = 0,
> offset = 0, refcount = 0, usage = 12, winsys = 0x0,
> texture = 0x0, face = 0, level = 0, zslice = 88}
>
> I tried to track what writes the insane value to the format field,
> and always came up with malloc and free, which didn't make any sense.
>
> Then I ran it with valgrind:
>
> ==5322== Invalid read of size 4
> ==5322==at 0x7B6887C: pipe_surface_reference (p_inlines.h:93)
> ==5322==by 0x7B6881F: copy_framebuffer_state (cso_context.c:781)
> ==5322==by 0x7B68962: cso_set_framebuffer (cso_context.c:791)
> ==5322==by 0x7AB5441: update_framebuffer_state (st_atom_framebuffer.c:147)
> ==5322==by 0x7AB3E41: st_validate_state (st_atom.c:188)
> ==5322==by 0x7ABDA2E: st_clear (st_cb_clear.c:517)
> ==5322==by 0x7B0BED5: _mesa_Clear (clear.c:177)
> ==5322==by 0x47F25FA: glClear (glapitemp.h:1100)
> ==5322==by 0x8048CE9: Draw (tri.c:72)
> ==5322==by 0x46F2C53: processWindowWorkList (glut_event.c:1302)
> ==5322==by 0x46F2D39: __glutProcessWindowWorkLists (glut_event.c:1354)
> ==5322==by 0x46F2DB0: glutMainLoop (glut_event.c:1375)
> ==5322== Address 0x7638a0c is 68 bytes inside a block of size 84 free'd
> ==5322==at 0x46D99EC: free (vg_replace_malloc.c:323)
> ==5322==by 0x797E17D: nv20_miptree_surface_release (nv20_miptree.c:144)
> ==5322==by 0x7AC0C69: pipe_surface_reference (p_inlines.h:95)
> ==5322==by 0x7AC07D3: st_renderbuffer_alloc_storage (st_cb_fbo.c:97)
> ==5322==by 0x7A07844: _mesa_resize_framebuffer (framebuffer.c:292)
> ==5322==by 0x79C2F65: st_resize_framebuffer (st_framebuffer.c:147)
> ==5322==by 0x7950CB3: nouveau_context_bind (nouveau_context.c:324)
> ==5322==by 0x794A6E4: DoBindContext (dri_util.c:380)
> ==5322==by 0x794A78E: driBindContext (dri_util.c:413)
> ==5322==by 0x47C14B2: BindContextWrapper (glxext.c:1621)
> ==5322==by 0x47C15F2: MakeContextCurrent (glxext.c:1675)
> ==5322==by 0x47C1927: glXMakeCurrent (glxext.c:1797)
> ==5322==
>
> and a couple more invalid reads, and a segfault.
> My theory is: when the window resize occurs, somewhere along the path
>
> st_renderbuffer_alloc_storage(GLcontext * ctx, struct gl_renderbuffer *rb,
> GLenum internalFormat,
> GLuint width, GLuint height)
> {
>struct pipe_context *pipe = ctx->st->pipe;
>struct st_renderbuffer *strb = st_renderbuffer(rb);
>struct pipe_texture template;
>unsigned surface_usage;
>
>/* Free the old surface and texture
> */
>pipe_surface_reference( &strb->surface, NULL );
>pipe_texture_reference( &strb->texture, NULL );
>
> is executed, which AFAICT frees the pipe_surface. My backtraces
> show it really is freed, since the pipe_surface::refcount = 1
> and decreases to zero. Then the new pipe_surface is allocated
> and things are looking good so far. This is seen in the
> "freed" part of the valgrind stack trace.
>
> Then we get to the first glClear afte
Re: [Mesa3d-dev] Gallium HW winsys
Am Freitag, den 11.07.2008, 16:56 +0200 schrieb Jakob Bornecrantz: > On Thu, Jul 10, 2008 at 6:22 PM, Younes Manton <[EMAIL PROTECTED]> wrote: > > I'm trying to get the HW winsys stuff set up for XvMC and have some > > questions. > > > > Is there any problem with dlopen()ing the DRI driver (in this case > > nouveau_dri.so) and instead of writing my own winsys? Stephane > > suggested I look into this, even though the winsys is supposed to be > > tied to the API. For Softpipe I looked at what Mesa's winsys was doing > > and implemented the stuff I needed and ignored any GL-specific things, > > but I realize now I may have been able to load egl_softpipe.so and > > reused their winsys. Is this acceptable for nouveau if I can live with > > some possibly minor GL dependencies?. I'm looking at dri_glx.c and > > glxext.c to see how this might be done. > > As things currently are you need to make sure that libGL.so linked to > the application. I think it just enough to dlopen() it GLOBAL and then > dlopen *_dri.so you want. > > You then need some hocks and things to get the pipe_winsys and > context creation out of the winsys or write code on your own side. > I think you might be better of just writing your own winsys. But yes > that is a lot of code duplication. > > If you look at the gallium i915 driver it has one dri winsys and one > EGL winsys. Both these share a lot of backend code in a common > directory, this part only talks to the DRM. Now I know this is beyond > the scope of your gsoc but you could try to talk to the nouveau guys > about it. I'd already half planned to look at doing something similar for nouveau at some point actually. Younes, if you decide you could use something similar let me know and I'll try to take a look in the next couple of days while I have a bit of spare time. Ben. > > dri: gallium/winsys/dri/intel > EGL: gallium/winsys/egl_drm/intel > backend: gallium/winsys/common/intel_drm > > Cheers Jakob. > > - > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] gallium: ARB_position_invariant fix
Hey, Current git ignores the IsPositionInvariant vertex program flag. Attached is a patch to fix the issue. Tested with progs/tests/arbvptorus on Nouveau/NV40. Cheers, Ben. 0001-gallium-obey-ARB_position_invariant-in-vertex-progr.patch Description: application/mbox - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium + NV40 + glClipPlane
Am Freitag, den 14.12.2007, 17:09 + schrieb Keith Whitwell:
> Ben Skeggs wrote:
> > Am Dienstag, den 11.12.2007, 12:47 +1100 schrieb Ben Skeggs:
> >> Hello,
> >>
> >> On nv40 hardware, fixed-function glClipPlane must be implemented in a
> >> vertex program.
> >>
> >> Attached is a patch which adds support for the clip distance vtxprog
> >> outputs as described in GL_NV_vertex_program{2,3,4}. The patch also
> >> allows the driver to configure whether it wants the fixed-function vp
> >> generator to insert clip planes, and the style of matrix multiplications
> >> it prefers.
> >>
> >> If there's no objection I'd like to commit this as it's required for
> >> implementing clip planes in the nv40 gallium driver.
> > No objections then? :) If not I'll commit this tomorrow night after I
> > finish work.
> >
>
> Ben, sorry I missed this the first time round.
>
> I think there's a bit of thinking needed on clip planes generally - I'm
> playing around a little with the i965 driver that also performs the
> cliptesting in a post-amble to the vertex shader. The software draw/
> module would also ideally work this way...
>
> Can you give me a couple of days to look at the issue & maybe work
> through it a bit more with you?
Sounds good. There's also the case of "hw supports vtxprogs, but does
clip planes through other means" to take care of, the current interface
would probably have to stay for this case?
Ben.
>
> Keith
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium + NV40 + glClipPlane
Am Dienstag, den 11.12.2007, 12:47 +1100 schrieb Ben Skeggs:
> Hello,
>
> On nv40 hardware, fixed-function glClipPlane must be implemented in a
> vertex program.
>
> Attached is a patch which adds support for the clip distance vtxprog
> outputs as described in GL_NV_vertex_program{2,3,4}. The patch also
> allows the driver to configure whether it wants the fixed-function vp
> generator to insert clip planes, and the style of matrix multiplications
> it prefers.
>
> If there's no objection I'd like to commit this as it's required for
> implementing clip planes in the nv40 gallium driver.
No objections then? :) If not I'll commit this tomorrow night after I
finish work.
Ben.
>
> Cheers,
> Ben.
> -
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___ Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Gallium + NV40 + glClipPlane
Hello,
On nv40 hardware, fixed-function glClipPlane must be implemented in a
vertex program.
Attached is a patch which adds support for the clip distance vtxprog
outputs as described in GL_NV_vertex_program{2,3,4}. The patch also
allows the driver to configure whether it wants the fixed-function vp
generator to insert clip planes, and the style of matrix multiplications
it prefers.
If there's no objection I'd like to commit this as it's required for
implementing clip planes in the nv40 gallium driver.
Cheers,
Ben.
diff --git a/src/mesa/main/ffvertex_prog.c b/src/mesa/main/ffvertex_prog.c
index 8fcb9e5..ead8b69 100644
--- a/src/mesa/main/ffvertex_prog.c
+++ b/src/mesa/main/ffvertex_prog.c
@@ -47,6 +47,8 @@
struct state_key {
+ unsigned matrix_dp4;
+
unsigned light_global_enabled:1;
unsigned light_local_viewer:1;
unsigned light_twoside:1;
@@ -77,6 +79,8 @@ struct state_key {
unsigned texgen_mode2:4;
unsigned texgen_mode3:4;
} unit[8];
+
+ unsigned clip_planes:6;
};
@@ -167,6 +171,8 @@ static struct state_key *make_state_key( GLcontext *ctx )
*/
assert(fp);
+ key->matrix_dp4 = ctx->VertexProgram._TnlProgramOptions.MatrixDP4;
+
key->fragprog_inputs_read = fp->Base.InputsRead;
if (ctx->RenderMode == GL_FEEDBACK) {
@@ -260,6 +266,13 @@ static struct state_key *make_state_key( GLcontext *ctx )
texUnit->GenModeQ );
}
}
+
+ if (ctx->VertexProgram._TnlProgramOptions.BuildClipPlanes) {
+ for (i = 0; i < MAX_CLIP_PLANES; i++) {
+ if (ctx->Transform.ClipPlanesEnabled & (1 << i))
+key->clip_planes |= (1 << i);
+ }
+ }
return key;
}
@@ -272,12 +285,6 @@ static struct state_key *make_state_key( GLcontext *ctx )
*/
#define DISASSEM (MESA_VERBOSE&VERBOSE_DISASSEM)
-/* Should be tunable by the driver - do we want to do matrix
- * multiplications with DP4's or with MUL/MAD's? SSE works better
- * with the latter, drivers may differ.
- */
-#define PREFER_DP4 0
-
#define MAX_INSN 256
/* Use uregs to represent registers internally, translate to Mesa's
@@ -675,7 +682,7 @@ static struct ureg get_eye_position( struct tnl_program *p )
p->eye_position = reserve_temp(p);
- if (PREFER_DP4) {
+ if (p->state->matrix_dp4) {
register_matrix_param5( p, STATE_MODELVIEW_MATRIX, 0, 0, 3,
0, modelview );
@@ -737,15 +744,13 @@ static struct ureg get_eye_normal( struct tnl_program *p )
return p->eye_normal;
}
-
-
static void build_hpos( struct tnl_program *p )
{
struct ureg pos = register_input( p, VERT_ATTRIB_POS );
struct ureg hpos = register_output( p, VERT_RESULT_HPOS );
struct ureg mvp[4];
- if (PREFER_DP4) {
+ if (p->state->matrix_dp4) {
register_matrix_param5( p, STATE_MVP_MATRIX, 0, 0, 3,
0, mvp );
emit_matrix_transform_vec4( p, hpos, mvp, pos );
@@ -757,6 +762,21 @@ static void build_hpos( struct tnl_program *p )
}
}
+static void build_clip_planes( struct tnl_program *p )
+{
+ struct ureg eye = get_eye_position( p );
+ struct ureg user_plane, clip;
+ int i;
+
+ for (i = 0; i < MAX_CLIP_PLANES; i++) {
+ if (!(p->state->clip_planes & (1 << i)))
+ continue;
+
+ register_matrix_param5( p, STATE_CLIPPLANE, i, 0, 0, 0, &user_plane );
+ clip = register_output( p, VERT_RESULT_CLIP0 + i );
+ emit_op2( p, OPCODE_DP4, clip, WRITEMASK_X, eye, user_plane );
+ }
+}
static GLuint material_attrib( GLuint side, GLuint property )
{
@@ -1358,7 +1378,7 @@ static void build_texture_transform( struct tnl_program *p )
struct ureg in = (!is_undef(out_texgen) ?
out_texgen :
register_input(p, VERT_ATTRIB_TEX0+i));
- if (PREFER_DP4) {
+ if (p->state->matrix_dp4) {
register_matrix_param5( p, STATE_TEXTURE_MATRIX, i, 0, 3,
0, texmat );
emit_matrix_transform_vec4( p, out, texmat, in );
@@ -1427,6 +1447,10 @@ static void build_tnl_program( struct tnl_program *p )
*/
build_hpos(p);
+ /* User clipping planes */
+ if (p->state->clip_planes)
+ build_clip_planes(p);
+
/* Lighting calculations:
*/
if (p->state->fragprog_inputs_read & (FRAG_BIT_COL0|FRAG_BIT_COL1)) {
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 8e49431..6538ec2 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -243,7 +243,13 @@ enum
#define VERT_RESULT_BFC0 13
#define VERT_RESULT_BFC1 14
#define VERT_RESULT_EDGE 15
-#define VERT_RESULT_VAR0 16 /**< shader varying */
+#define VERT_RESULT_CLIP0 16
+#define VERT_RESULT_CLIP1 17
+#define VERT_RESULT_CLIP2 18
+#define VERT_RESULT_CLIP3 19
+#define VERT_RESULT_CLIP4 20
+#define VERT_RESULT_CLIP5 21
+#define VERT_RESULT_VAR0 22 /**< shader varying */
#define VERT_RESULT_MAX (VERT_RESULT_VAR0 + MAX_VARYING)
/[EMAIL PROTECTED]/
@@ -1987,6 +1993,12 @@ struct gl_vertex_program_state
/** Program to emulate fixed
Re: [Mesa3d-dev] Query object interface.
Am Freitag, den 23.11.2007, 10:21 + schrieb Keith Whitwell: > Ben Skeggs wrote: > > Hey, > > > > Attached is a patch which adds driver hooks to update the status of a > > query object (both to core mesa, and the gallium state tracker). There > > is currently an issue with applications that spin waiting for > > GL_QUERY_RESULT_AVAILABLE_ARB to be true (eg. arbocclude). The current > > code will simply check return q->Ready, and doesn't give the driver a > > chance to actually update this field, so the application will end up > > spinning forever. > > > > The workaround in nouveau (current git, and nv4x gallium driver) > > currently forces the application to block until a query result is > > available when it calls glEndQuery(). Obviously this isn't a nice > > solution! > > I think I'm going to rejig the pipe query interface. I'm not really > happy with the pipe_query_object struct, I think it can just go away and > become an opaque handle to a structure private to the driver, so we get > an interface more like this: > > struct pipe_query_object *(*create_query)( struct pipe_context *pipe, >unsigned query_type ); > > void (*destroy_query)(struct pipe_context *pipe, > struct pipe_query_object *q); > > void (*begin_query)(struct pipe_context *pipe, > struct pipe_query_object *q); > > void (*end_query)(struct pipe_context *pipe, >struct pipe_query_object *q); > > boolean (*get_query_result)(struct pipe_context *pipe, > struct pipe_query_object *q, > boolean wait, > uint64_t *result); > This looks much better. In the nv4x gallium driver I currently store pointers to the pipe_query_objects in an array and use that to lookup the driver private info. The above interface would do away with that hack :) > > Even this is probably too constrained as future query types may provide > some more elaborate structure as a result, eg multiple hardware counters > in a struct or similar. Perhaps something like the current struct pipe_query_object, but keep the driver's create_query() call so it can allocate the pipe object as a subclass of its own query object struct. And have the driver maintain the fields of pipe_query_object it supports? Ben. > > Keith - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Query object interface.
Hey,
Attached is a patch which adds driver hooks to update the status of a
query object (both to core mesa, and the gallium state tracker). There
is currently an issue with applications that spin waiting for
GL_QUERY_RESULT_AVAILABLE_ARB to be true (eg. arbocclude). The current
code will simply check return q->Ready, and doesn't give the driver a
chance to actually update this field, so the application will end up
spinning forever.
The workaround in nouveau (current git, and nv4x gallium driver)
currently forces the application to block until a query result is
available when it calls glEndQuery(). Obviously this isn't a nice
solution!
Cheers,
Ben.
diff --git a/src/mesa/drivers/common/driverfuncs.c b/src/mesa/drivers/common/driverfuncs.c
index 96e5037..2228754 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -227,6 +227,7 @@ _mesa_init_driver_functions(struct dd_function_table *driver)
driver->BeginQuery = _mesa_begin_query;
driver->EndQuery = _mesa_end_query;
driver->WaitQuery = _mesa_wait_query;
+ driver->UpdateQuery = _mesa_update_query;
/* APPLE_vertex_array_object */
driver->NewArrayObject = _mesa_new_array_object;
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index f089fcb..d45276e 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -814,6 +814,7 @@ struct dd_function_table {
void (*BeginQuery)(GLcontext *ctx, struct gl_query_object *q);
void (*EndQuery)(GLcontext *ctx, struct gl_query_object *q);
void (*WaitQuery)(GLcontext *ctx, struct gl_query_object *q);
+ void (*UpdateQuery)(GLcontext *ctx, struct gl_query_object *q);
/[EMAIL PROTECTED]/
diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index 688d0fc..1222a58 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -88,6 +88,15 @@ _mesa_wait_query(GLcontext *ctx, struct gl_query_object *q)
assert(q->Ready);
}
+/**
+ * Update a query. Software driver fallback.
+ * Called via ctx->Driver.EndQuery().
+ */
+void
+_mesa_update_query(GLcontext *ctx, struct gl_query_object *q)
+{
+ q->Ready = GL_TRUE;
+}
/**
* Delete an occlusion query object.
@@ -386,6 +395,8 @@ _mesa_GetQueryObjectivARB(GLuint id, GLenum pname, GLint *params)
}
break;
case GL_QUERY_RESULT_AVAILABLE_ARB:
+ if (!q->Ready)
+ctx->Driver.UpdateQuery(ctx, q);
*params = q->Ready;
break;
default:
diff --git a/src/mesa/main/queryobj.h b/src/mesa/main/queryobj.h
index d466aae..670cc03 100644
--- a/src/mesa/main/queryobj.h
+++ b/src/mesa/main/queryobj.h
@@ -45,6 +45,8 @@ _mesa_end_query(GLcontext *ctx, struct gl_query_object *q);
extern void
_mesa_wait_query(GLcontext *ctx, struct gl_query_object *q);
+extern void
+_mesa_update_query(GLcontext *ctx, struct gl_query_object *q);
extern void GLAPIENTRY
_mesa_GenQueriesARB(GLsizei n, GLuint *ids);
diff --git a/src/mesa/pipe/p_context.h b/src/mesa/pipe/p_context.h
index 8bed958..58086dc 100644
--- a/src/mesa/pipe/p_context.h
+++ b/src/mesa/pipe/p_context.h
@@ -83,6 +83,7 @@ struct pipe_context {
void (*begin_query)(struct pipe_context *pipe, struct pipe_query_object *q);
void (*end_query)(struct pipe_context *pipe, struct pipe_query_object *q);
void (*wait_query)(struct pipe_context *pipe, struct pipe_query_object *q);
+ void (*update_query)(struct pipe_context *pipe, struct pipe_query_object *q);
/*
* State functions
diff --git a/src/mesa/pipe/softpipe/sp_context.c b/src/mesa/pipe/softpipe/sp_context.c
index d5e68c1..327c92c 100644
--- a/src/mesa/pipe/softpipe/sp_context.c
+++ b/src/mesa/pipe/softpipe/sp_context.c
@@ -207,6 +207,14 @@ softpipe_wait_query(struct pipe_context *pipe, struct pipe_query_object *q)
assert(0);
}
+static void
+softpipe_update_query(struct pipe_context *pipe, struct pipe_query_object *q)
+{
+ /* Should never get here since we indicated that the result was
+* ready in softpipe_end_query().
+*/
+ assert(0);
+}
static const char *softpipe_get_name( struct pipe_context *pipe )
{
@@ -346,6 +354,7 @@ struct pipe_context *softpipe_create( struct pipe_winsys *pipe_winsys,
softpipe->pipe.begin_query = softpipe_begin_query;
softpipe->pipe.end_query = softpipe_end_query;
softpipe->pipe.wait_query = softpipe_wait_query;
+ softpipe->pipe.update_query = softpipe_update_query;
softpipe->pipe.get_name = softpipe_get_name;
softpipe->pipe.get_vendor = softpipe_get_vendor;
diff --git a/src/mesa/state_tracker/st_cb_queryobj.c b/src/mesa/state_tracker/st_cb_queryobj.c
index 5b95dd7..66b10f8 100644
--- a/src/mesa/state_tracker/st_cb_queryobj.c
+++ b/src/mesa/state_tracker/st_cb_queryobj.c
@@ -134,6 +134,17 @@ st_WaitQuery(GLcontext *ctx, struct gl_query_object *q)
q->Result = stq->pq.count;
}
+static void
+st_UpdateQuery(GLcontext *ctx, struct gl_query_object *q)
+{
+ struct pipe_context *pipe = ctx->st->pipe;
+ struct st_quer
Re: [Mesa3d-dev] Scenes, [was: Re: Gallium buffer clear interface.]
Am Freitag, den 21.09.2007, 08:45 +0100 schrieb Keith Whitwell: > Brian Paul wrote: > > Ben Skeggs wrote: > >> I've been playing gallium on NV40 hardware a bit this week, so far it > >> seems very nice. However... :) > >> > >> The hardware supports selective clearing of each channel of the primary > >> render target, depth, and stencil buffers in a single operation. The > >> current buffer clear interface is called with separate pipe_surface > >> structs for each GL_x_BUFFER_BIT, which makes it difficult to use this > >> functionality (which is somewhat faster when clearing both colour and > >> depth/stencil buffers at the same time). > >> > >> Is there any plan for a pipe->fb_clear() (for example) interface, which > >> would pass in a bit mask saying "clear these buffers that are currently > >> bound to the framebuffer", similar to the interface in the "old" driver > >> model? > > > > If you can also specify the channel mask for clearing each buffer, you'd > > probably want something like: > > > > clear(uint numSurfaces, pipe_surface **surfaces, const uint *masks) > > I see reasonable uses for clearing fullscreen color, depth and stencil > independently. There's also a case that we should be able to pass down > a list of fullscreen clears so that the driver can process them as > efficiently as possible. Yes, this is what I was after. The ability to clear some combination of colour/depth/stencil buffers in one operation, I don't care for the ability to clear R/G/B/A individually, was just mentioning that's how the hw implements clears :) > > I'm totally unconvinced that there is a need to provide an interface for > clearing eg. just the red channel of a color buffer. Agreed. Ben. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Gallium buffer clear interface.
I've been playing gallium on NV40 hardware a bit this week, so far it seems very nice. However... :) The hardware supports selective clearing of each channel of the primary render target, depth, and stencil buffers in a single operation. The current buffer clear interface is called with separate pipe_surface structs for each GL_x_BUFFER_BIT, which makes it difficult to use this functionality (which is somewhat faster when clearing both colour and depth/stencil buffers at the same time). Is there any plan for a pipe->fb_clear() (for example) interface, which would pass in a bit mask saying "clear these buffers that are currently bound to the framebuffer", similar to the interface in the "old" driver model? Cheers, Ben. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
