[Mesa3d-dev] call for testers: galllium-screen-context branch
We've had a couple of cleanups that we've wanted to do in gallium for as long as I can remember. One of which is to remove all the random context-creation calls and funnel them through something sensible like a context_create() call in pipe_screen. The gallium-screen-context branch does exactly that. The trouble is this change touches every driver and state-tracker in every combination. I can't even build half the drivers (what do I need to install to build nouveau?), let alone test them in any meaningful way. So, I really need people to take a look at this branch and make sure you can still at least build the driver, run some simple apps, etc. Keith -- 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
Re: [Mesa3d-dev] [RFC] gallium-cylindrical-wrap branch
Brian Paul wrote on 2010-02-04 22:07: michal wrote: Brian Paul wrote on 2010-02-03 17:58: Keith Whitwell wrote: Michal, why do you need this for linear interpolator and not perspective? I think d3d mobile let you disable perspective correct texturing, but it is always enabled for normal d3d. I could not think of a use case that uses perspective and cylindrical interpolation at the same time. If you think it's valid, we can implement cylindrical wrapping for perspective interpolator, but then I am not sure how exactly it should be done, i.e. should we divide and then wrap or the opposite? Is there some way we can figure out what DX9 does here? Maybe a quick test? I suspect cylindrical wrapping would be done after the divide. A quick test shows it is legal to have perspective and cylindrical interpolation. In fact, I see no difference between projected and non-projected version with REF device -- both are perspective correct. I think I am stuck at this point and need further help. I am trying to modify tri_persp_coeff() in softpipe in a similar manner to tri_linear_coeff(), but all I get are lousy rendering artifacts. If we need do cylindrical wrapping after divide, it must be done as part of shader interpolator, but the only place where we have enough information to do wrapping is in primitive setup. Do you have a patch relative to gallium-cylindrical-wrap? I'll take a look. Brian, I have no half-working patch for you, sorry. I tried a few approaches, but they were nonsensical. The linear coeff calculation is simple: calculate distance between two coordinates, and if it's greater than 0.5, apply wrapping by adjusting the distance. However, for the perspective correct coeffs, we divide early by position.w before calculating the distance, and so my approach that worked for linear fails here. I am either not comprehending the math here (why do we divide the second time in interpolator, for instance?) or we need to put more information into struct tgsi_interp_coef so that the interpolator code has enough information to do wrapping on its own without help of primitive setup. -- 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
[Mesa3d-dev] Continue to allow building src/glx on current distros
Jesse,
Can you take a look at the attached patch? I'd really like to be able
to build mesa and the DRI drivers on current distros (eg Ubuntu 9.10)
without having to pull in heaps of dependencies. The patch adds
#ifdefs to protect against the newer DRI2 protocol changes, meaning I
can build-test linux-dri and related targets with just the
distro-supplied packages.
Keith
commit d7b57f4061b82322cbcae176125913d9f0dea6c1
Author: Keith Whitwell kei...@vmware.com
Date: Thu Feb 4 12:46:21 2010 +
glx: permit building with older protocol headers
I'd like to be able to build mesa on current distro releases without
having to upgrade from the standard dri2proto and glproto headers. With
this change I'm able to build on ancient releases such as Ubuntu 9-10...
In general, it would be nice to be able to build-test mesa to check for
unintended breakages without having to follow the external dependencies
of every group working on the codebase.
diff --git a/src/glx/x11/dri2.c b/src/glx/x11/dri2.c
index 832935a..91053d3 100644
--- a/src/glx/x11/dri2.c
+++ b/src/glx/x11/dri2.c
@@ -94,6 +94,8 @@ DRI2WireToEvent(Display *dpy, XEvent *event, xEvent *wire)
XextCheckExtension(dpy, info, dri2ExtensionName, False);
switch ((wire-u.u.type 0x7f) - info-codes-first_event) {
+
+#ifdef X_DRI2SwapBuffers
case DRI2_BufferSwapComplete:
{
GLXBufferSwapComplete *aevent = (GLXBufferSwapComplete *)event;
@@ -123,6 +125,8 @@ DRI2WireToEvent(Display *dpy, XEvent *event, xEvent *wire)
aevent-sbc = ((CARD64)awire-sbc_hi 32) | awire-sbc_lo;
return True;
}
+#endif
+
default:
/* client doesn't support server event */
break;
@@ -455,6 +459,7 @@ DRI2CopyRegion(Display * dpy, XID drawable, XserverRegion region,
SyncHandle();
}
+#ifdef X_DRI2SwapBuffers
static void
load_swap_req(xDRI2SwapBuffersReq *req, CARD64 target, CARD64 divisor,
CARD64 remainder)
@@ -496,7 +501,9 @@ void DRI2SwapBuffers(Display *dpy, XID drawable, CARD64 target_msc,
UnlockDisplay(dpy);
SyncHandle();
}
+#endif
+#ifdef X_DRI2GetMSC
Bool DRI2GetMSC(Display *dpy, XID drawable, CARD64 *ust, CARD64 *msc,
CARD64 *sbc)
{
@@ -527,7 +534,9 @@ Bool DRI2GetMSC(Display *dpy, XID drawable, CARD64 *ust, CARD64 *msc,
return True;
}
+#endif
+#ifdef X_DRI2WaitMSC
static void
load_msc_req(xDRI2WaitMSCReq *req, CARD64 target, CARD64 divisor,
CARD64 remainder)
@@ -571,7 +580,9 @@ Bool DRI2WaitMSC(Display *dpy, XID drawable, CARD64 target_msc, CARD64 divisor,
return True;
}
+#endif
+#ifdef X_DRI2WaitSBC
static void
load_sbc_req(xDRI2WaitSBCReq *req, CARD64 target)
{
@@ -610,7 +621,9 @@ Bool DRI2WaitSBC(Display *dpy, XID drawable, CARD64 target_sbc, CARD64 *ust,
return True;
}
+#endif
+#ifdef X_DRI2SwapInterval
void DRI2SwapInterval(Display *dpy, XID drawable, int interval)
{
XExtDisplayInfo *info = DRI2FindDisplay(dpy);
@@ -627,5 +640,6 @@ void DRI2SwapInterval(Display *dpy, XID drawable, int interval)
UnlockDisplay(dpy);
SyncHandle();
}
+#endif
#endif /* GLX_DIRECT_RENDERING */
diff --git a/src/glx/x11/dri2_glx.c b/src/glx/x11/dri2_glx.c
index 7a5740a..6200df9 100644
--- a/src/glx/x11/dri2_glx.c
+++ b/src/glx/x11/dri2_glx.c
@@ -380,8 +380,10 @@ dri2SwapBuffers(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor,
return 0;
}
+#ifdef X_DRI2SwapBuffers
DRI2SwapBuffers(pdraw-psc-dpy, pdraw-xDrawable, target_msc, divisor,
remainder, ret);
+#endif
#if __DRI2_FLUSH_VERSION = 2
if (pdraw-psc-f)
@@ -576,18 +578,24 @@ dri2CreateScreen(__GLXscreenConfigs * psc, int screen,
psp-swapBuffers = dri2SwapBuffers;
psp-waitGL = dri2WaitGL;
psp-waitX = dri2WaitX;
+ psp-getDrawableMSC = NULL;
+ psp-waitForMSC = NULL;
+ psp-waitForSBC = NULL;
+ psp-setSwapInterval = NULL;
+ psp-getSwapInterval = NULL;
+
if (pdp-driMinor = 2) {
+#ifdef X_DRI2GetMSC
psp-getDrawableMSC = dri2DrawableGetMSC;
+#endif
+#ifdef X_DRI2WaitMSC
psp-waitForMSC = dri2WaitForMSC;
psp-waitForSBC = dri2WaitForSBC;
+#endif
+#ifdef X_DRI2SwapInterval
psp-setSwapInterval = dri2SetSwapInterval;
psp-getSwapInterval = dri2GetSwapInterval;
- } else {
- psp-getDrawableMSC = NULL;
- psp-waitForMSC = NULL;
- psp-waitForSBC = NULL;
- psp-setSwapInterval = NULL;
- psp-getSwapInterval = NULL;
+#endif
}
/* DRI2 suports SubBuffer through DRI2CopyRegion, so it's always
@@ -643,8 +651,10 @@ dri2CreateDisplay(Display * dpy)
pdp-driPatch = 0;
pdp-swapAvailable = 0;
+#ifdef X_DRI2SwapBuffers
if (pdp-driMinor = 2)
pdp-swapAvailable = 1;
+#endif
pdp-base.destroyDisplay = dri2DestroyDisplay;
pdp-base.createScreen = dri2CreateScreen;
diff --git a/src/glx/x11/glxext.c b/src/glx/x11/glxext.c
index 1b4ab71..dde694b 100644
--- a/src/glx/x11/glxext.c
+++ b/src/glx/x11/glxext.c
@@ -158,6 +158,16 @@
Re: [Mesa3d-dev] st_api: a replacement for st_public.h
On Thu, 2010-02-04 at 21:23 -0800, Chia-I Wu wrote: Hi Keith, Thanks for having a closer look. On Thu, Feb 4, 2010 at 9:31 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: As st_api.h can be implemented parallelly with st_public.h, a possible route I would like to take is to (in this order) 1. implement st_api.h in OpenVG and OpenGL state trackers 2. convert st/egl to use st_api.h 3. convert st/glx and st/dri to use st_api.h 4. eliminate st_public.h and any use of it Probably the other major user is st/wgl. If you install mingw, this can be build-tested on linux machines, so you should at least be able to minimize the disruption in that component as well. Yeah, right. If there will still be concerns for st/wgl users, I can also postpone the elimination of st_public.h. WGL semantics are similar to GLX -- just different names --, so I don't expect any problem adapting st/wgl to st_api.h. Leaving it broken is not an option though, since it is a very important component for us. If you could do the initial rough conversion of st/wgl to st_api.h I'd gladly test it and polish it. I've looked at http://cgit.freedesktop.org/~olv/st_api/tree/st_api.h , and all looks very sensible. The only thing I don't understand, perhaps due to my EGL ignorance, is st_context::lock/unlock_resource(). What do they exactly accomplish? Is there some EGL visible APIs that map exactly to this? As Jakob drafted the first version of the interface, I believe he also wanted to remove screen-flush_front and screen-update_buffer. These two callbacks do become unnecessary because of the new st_framebuffer_iface, which I think is a step forward. screen-flush_front itself may still exist, but indeed the Mesa state tracker shouldn't call it directly -- it should be st/wgl, st/glx, and friends. I think st_api's st_framebuffer::flush_front accomplishes this nicely. BTW, I'd prefer the name present instead of flush_front. It's a more common and intuitive name for this operation. Jose -- 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
[Mesa3d-dev] empty vertex buffers
Let's assume I have an array of vertex elements that indicate position/color in vertex buffer #3. Let's also for the sake of argument say that there is nothing else in my vertex elements. No other buffers are being pointed to. Is it legal for me to pipe_context::set_vertex_buffers with an array size of 3 and set buffer 1 and 2 == NULL? -- 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
Re: [Mesa3d-dev] st_api: a replacement for st_public.h
On Fri, Feb 5, 2010 at 7:40 PM, José Fonseca jfons...@vmware.com wrote: On Thu, 2010-02-04 at 21:23 -0800, Chia-I Wu wrote: On Thu, Feb 4, 2010 at 9:31 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: As st_api.h can be implemented parallelly with st_public.h, a possible route I would like to take is to (in this order) 1. implement st_api.h in OpenVG and OpenGL state trackers 2. convert st/egl to use st_api.h 3. convert st/glx and st/dri to use st_api.h 4. eliminate st_public.h and any use of it Probably the other major user is st/wgl. If you install mingw, this can be build-tested on linux machines, so you should at least be able to minimize the disruption in that component as well. Yeah, right. If there will still be concerns for st/wgl users, I can also postpone the elimination of st_public.h. WGL semantics are similar to GLX -- just different names --, so I don't expect any problem adapting st/wgl to st_api.h. Leaving it broken is not an option though, since it is a very important component for us. If you could do the initial rough conversion of st/wgl to st_api.h I'd gladly test it and polish it. That would be great. It is also worth noting that a KHR-API state tracker can support both st_api.h and st_public.h at the same time. This is why window-system state trackers can be migrated to use st_api.h one by one without any breakage. It should hopefully also have less unexpected regressions. I've looked at http://cgit.freedesktop.org/~olv/st_api/tree/st_api.h , and all looks very sensible. The only thing I don't understand, perhaps due to my EGL ignorance, is st_context::lock/unlock_resource(). What do they exactly accomplish? Is there some EGL visible APIs that map exactly to this? There are OpenGL ES and OpenVG extensions that add functions taking EGLImageKHR as an argument. The KHR-API state trackers will need to validate and look up the underlying pipe_texture of EGLImageKHR. Conversely, a texture object (type GLuint) or VGImage may be passed to EGL to create an EGLImageKHR. EGL needs to ask the respective KHR-API state trackers to validate the name/handle and return the underlying pipe_texture. The callbacks (lock_resource/unlock_resource) may be simplified to a single reference_resouce (a reference must be added to avoid race). But there is one known use that require a VGImage to be locked. It will cause EGL to return EGL_BAD_ACCESS or OpenVG to return VG_IMAGE_IN_USE_ERROR. As Jakob drafted the first version of the interface, I believe he also wanted to remove screen-flush_front and screen-update_buffer. These two callbacks do become unnecessary because of the new st_framebuffer_iface, which I think is a step forward. screen-flush_front itself may still exist, but indeed the Mesa state tracker shouldn't call it directly -- it should be st/wgl, st/glx, and friends. I think st_api's st_framebuffer::flush_front accomplishes this nicely. BTW, I'd prefer the name present instead of flush_front. It's a more common and intuitive name for this operation. I think the name follows how pipe_screen names it. I am quite open to the naming, but maybe we can keep it for a while until pipe_screen renames it, or removes it? -olv -- 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
Re: [Mesa3d-dev] [RFC] gallium-cylindrical-wrap branch
michal wrote on 2010-02-05 11:05: Brian Paul wrote on 2010-02-04 22:07: michal wrote: Brian Paul wrote on 2010-02-03 17:58: Keith Whitwell wrote: Michal, why do you need this for linear interpolator and not perspective? I think d3d mobile let you disable perspective correct texturing, but it is always enabled for normal d3d. I could not think of a use case that uses perspective and cylindrical interpolation at the same time. If you think it's valid, we can implement cylindrical wrapping for perspective interpolator, but then I am not sure how exactly it should be done, i.e. should we divide and then wrap or the opposite? Is there some way we can figure out what DX9 does here? Maybe a quick test? I suspect cylindrical wrapping would be done after the divide. A quick test shows it is legal to have perspective and cylindrical interpolation. In fact, I see no difference between projected and non-projected version with REF device -- both are perspective correct. I think I am stuck at this point and need further help. I am trying to modify tri_persp_coeff() in softpipe in a similar manner to tri_linear_coeff(), but all I get are lousy rendering artifacts. If we need do cylindrical wrapping after divide, it must be done as part of shader interpolator, but the only place where we have enough information to do wrapping is in primitive setup. Do you have a patch relative to gallium-cylindrical-wrap? I'll take a look. Brian, I have no half-working patch for you, sorry. I tried a few approaches, but they were nonsensical. The linear coeff calculation is simple: calculate distance between two coordinates, and if it's greater than 0.5, apply wrapping by adjusting the distance. However, for the perspective correct coeffs, we divide early by position.w before calculating the distance, and so my approach that worked for linear fails here. I am either not comprehending the math here (why do we divide the second time in interpolator, for instance?) or we need to put more information into struct tgsi_interp_coef so that the interpolator code has enough information to do wrapping on its own without help of primitive setup. OK, I managed to correctly implement cylindrical wrap in softpipe both for linear and perspective interpolation, both for lines and triangles. Tested with Brian's cylwrap test app -- it works. Please re-review. Thanks. -- 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
Re: [Mesa3d-dev] Continue to allow building src/glx on current distros
On Fri, 5 Feb 2010 10:08:44 + Keith Whitwell keith.whitw...@googlemail.com wrote: Jesse, Can you take a look at the attached patch? I'd really like to be able to build mesa and the DRI drivers on current distros (eg Ubuntu 9.10) without having to pull in heaps of dependencies. The patch adds #ifdefs to protect against the newer DRI2 protocol changes, meaning I can build-test linux-dri and related targets with just the distro-supplied packages. As much as I hate #ifdefs, I think this is probably a reasonable thing to do. Have you tested to confirm that it preserves both the old and new behavior when different proto headers are present? Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- 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
Re: [Mesa3d-dev] [RFC] gallium-cylindrical-wrap branch
michal wrote: michal wrote on 2010-02-05 11:05: Brian Paul wrote on 2010-02-04 22:07: michal wrote: Brian Paul wrote on 2010-02-03 17:58: Keith Whitwell wrote: Michal, why do you need this for linear interpolator and not perspective? I think d3d mobile let you disable perspective correct texturing, but it is always enabled for normal d3d. I could not think of a use case that uses perspective and cylindrical interpolation at the same time. If you think it's valid, we can implement cylindrical wrapping for perspective interpolator, but then I am not sure how exactly it should be done, i.e. should we divide and then wrap or the opposite? Is there some way we can figure out what DX9 does here? Maybe a quick test? I suspect cylindrical wrapping would be done after the divide. A quick test shows it is legal to have perspective and cylindrical interpolation. In fact, I see no difference between projected and non-projected version with REF device -- both are perspective correct. I think I am stuck at this point and need further help. I am trying to modify tri_persp_coeff() in softpipe in a similar manner to tri_linear_coeff(), but all I get are lousy rendering artifacts. If we need do cylindrical wrapping after divide, it must be done as part of shader interpolator, but the only place where we have enough information to do wrapping is in primitive setup. Do you have a patch relative to gallium-cylindrical-wrap? I'll take a look. Brian, I have no half-working patch for you, sorry. I tried a few approaches, but they were nonsensical. The linear coeff calculation is simple: calculate distance between two coordinates, and if it's greater than 0.5, apply wrapping by adjusting the distance. However, for the perspective correct coeffs, we divide early by position.w before calculating the distance, and so my approach that worked for linear fails here. I am either not comprehending the math here (why do we divide the second time in interpolator, for instance?) or we need to put more information into struct tgsi_interp_coef so that the interpolator code has enough information to do wrapping on its own without help of primitive setup. OK, I managed to correctly implement cylindrical wrap in softpipe both for linear and perspective interpolation, both for lines and triangles. Tested with Brian's cylwrap test app -- it works. Please re-review. Thanks. Seems to work as expected. The code looks good. Thanks. -Brian -- 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
[Mesa3d-dev] OSMesa symbol exports
A couple symbols are missing from the osmesa.def file. On Windows, this causes OSMesaGetProcAddress to be named _osmesagetprocaddr...@4, which breaks some of our code to dynamically load OpenGL. The attached patch fixes the symbol names, verified via depends.exe. It's against 7_7_branch but probably applies elsewhere. If there's a 7.6.2 planned, could this get applied there as well? Thanks, -tom From 170587484549958420d115904f74588be54792fc Mon Sep 17 00:00:00 2001 From: Tom Fogal tfo...@alumni.unh.edu Date: Fri, 5 Feb 2010 11:45:03 -0700 Subject: [PATCH] Add OSMesaColorClamp and OSMesaGetProcAddress to symbol defs. Without this patch, the two symbols get an underscore prepended and an @4 appended when compiling with VC8. --- src/mesa/drivers/osmesa/osmesa.def |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/osmesa/osmesa.def b/src/mesa/drivers/osmesa/osmesa.def index 71e9687..06afab7 100644 --- a/src/mesa/drivers/osmesa/osmesa.def +++ b/src/mesa/drivers/osmesa/osmesa.def @@ -2,6 +2,7 @@ VERSION 4.1 EXPORTS + OSMesaColorClamp OSMesaCreateContext OSMesaCreateContextExt OSMesaDestroyContext @@ -11,3 +12,4 @@ EXPORTS OSMesaGetIntegerv OSMesaGetDepthBuffer OSMesaGetColorBuffer + OSMesaGetProcAddress -- 1.6.5.1.msysgit.1 -- 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
[Mesa3d-dev] [PATCH] Fix a typo in mesa3d.org HTML
From 99fbfe43dad3efae04749ab9da164c0e849bd836 Mon Sep 17 00:00:00 2001 From: Tom Fogal tfo...@alumni.unh.edu Date: Fri, 5 Feb 2010 13:11:25 -0700 Subject: [PATCH] Fix a typo in mesa3d.org HTML. --- docs/repository.html |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/docs/repository.html b/docs/repository.html index ed38528..15621b7 100644 --- a/docs/repository.html +++ b/docs/repository.html @@ -1,6 +1,6 @@ HTML -TITLECocd Repository/TITLE +TITLECode Repository/TITLE link rel=stylesheet type=text/css href=mesa.css/head -- 1.6.3.3 -- 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
Re: [Mesa3d-dev] OSMesa symbol exports
tom fogal wrote: A couple symbols are missing from the osmesa.def file. On Windows, this causes OSMesaGetProcAddress to be named _osmesagetprocaddr...@4, which breaks some of our code to dynamically load OpenGL. The attached patch fixes the symbol names, verified via depends.exe. It's against 7_7_branch but probably applies elsewhere. If there's a 7.6.2 planned, could this get applied there as well? There won't be a 7.6.2 release. Committed to the 7.7 branch and master. Thanks. -Brian -- 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
Re: [Mesa3d-dev] [PATCH] Fix a typo in mesa3d.org HTML
Committed. Thanks. -Brian -- 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
[Mesa3d-dev] [RFC] reduce number of visuals exposed by Intel drivers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd like to remove a bunch of the visuals and fbconfigs exposed by the Intel drivers. There are several categories of visuals that are likely not useful to anyone. A couple of our test suites (e.g., glean) like to run over every possible visual. As a result, the test suites take an extraordinary amount of time to run. I propose removing: * All 24-bit depth / 0-bit stencil visuals. These are compatible with the default state of a 24-bit depth / 8-bit stencil visual and offer no memory savings. This will eliminate 24 (of 72) visuals by itself. * All but one of the visuals with accumulation buffer. Accumulation is a software path in the Intel drivers (though this could be fixed), so I don't see any utility in offering multiple, optimized buffer configuration choices. This will eliminate an additional 23 visuals. This will leave the 25 visuals and 37 fbconfigs that are likely to be useful. Anyone have a concerns with me doing this? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktshzkACgkQX1gOwKyEAw/aSgCeJ+vgWfSuCxGgLqN+FjiSaR82 0A4Anj3O9qK6bI5E92YLBewrpDFcYwmW =e0Qq -END PGP SIGNATURE- -- 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
Re: [Mesa3d-dev] [RFC] reduce number of visuals exposed by Intel drivers
I'm cool with that. There's actually a couple Gallium fbconfig things I wanna bring up, but I'll start another thread for those. On Fri, Feb 5, 2010 at 1:01 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd like to remove a bunch of the visuals and fbconfigs exposed by the Intel drivers. There are several categories of visuals that are likely not useful to anyone. A couple of our test suites (e.g., glean) like to run over every possible visual. As a result, the test suites take an extraordinary amount of time to run. I propose removing: * All 24-bit depth / 0-bit stencil visuals. These are compatible with the default state of a 24-bit depth / 8-bit stencil visual and offer no memory savings. This will eliminate 24 (of 72) visuals by itself. * All but one of the visuals with accumulation buffer. Accumulation is a software path in the Intel drivers (though this could be fixed), so I don't see any utility in offering multiple, optimized buffer configuration choices. This will eliminate an additional 23 visuals. This will leave the 25 visuals and 37 fbconfigs that are likely to be useful. Anyone have a concerns with me doing this? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktshzkACgkQX1gOwKyEAw/aSgCeJ+vgWfSuCxGgLqN+FjiSaR82 0A4Anj3O9qK6bI5E92YLBewrpDFcYwmW =e0Qq -END PGP SIGNATURE- -- 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 -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com -- 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
Re: [Mesa3d-dev] [Intel-gfx] [RFC] reduce number of visuals exposed by Intel drivers
On Fri, Feb 5, 2010 at 4:01 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd like to remove a bunch of the visuals and fbconfigs exposed by the Intel drivers. There are several categories of visuals that are likely not useful to anyone. A couple of our test suites (e.g., glean) like to run over every possible visual. As a result, the test suites take an extraordinary amount of time to run. I propose removing: * All 24-bit depth / 0-bit stencil visuals. These are compatible with the default state of a 24-bit depth / 8-bit stencil visual and offer no memory savings. This will eliminate 24 (of 72) visuals by itself. * All but one of the visuals with accumulation buffer. Accumulation is a software path in the Intel drivers (though this could be fixed), so I don't see any utility in offering multiple, optimized buffer configuration choices. This will eliminate an additional 23 visuals. This will leave the 25 visuals and 37 fbconfigs that are likely to be useful. Anyone have a concerns with me doing this? Nice idea, it all sounds good to me. Kristian -- 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
[Mesa3d-dev] Gallium DRI fbconfig/visual setup
Two things... Are accumbufs still slow in Gallium-land? Should we still mark them as slow? How many multisamples should we actually pretend/advertise? Should we have a cap to check the number of multisamples supported? Should we just say that four samples are done for the fbconfig/visual, and then replace pipe_texture::nr_samples with a multisample boolean flag? ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com -- 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
Re: [Mesa3d-dev] [RFC] reduce number of visuals exposed by Intel drivers
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd like to remove a bunch of the visuals and fbconfigs exposed by the Intel drivers. There are several categories of visuals that are likely not useful to anyone. A couple of our test suites (e.g., glean) like to run over every possible visual. As a result, the test suites take an extraordinary amount of time to run. I propose removing: * All 24-bit depth / 0-bit stencil visuals. These are compatible with the default state of a 24-bit depth / 8-bit stencil visual and offer no memory savings. This will eliminate 24 (of 72) visuals by itself. * All but one of the visuals with accumulation buffer. Accumulation is a software path in the Intel drivers (though this could be fixed), so I don't see any utility in offering multiple, optimized buffer configuration choices. This will eliminate an additional 23 visuals. This will leave the 25 visuals and 37 fbconfigs that are likely to be useful. Anyone have a concerns with me doing this? Sounds good. -Brian -- 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
[Mesa3d-dev] [Bug 25994] [i915][GLSL] 'return' statement in vertex shader may cause GPU hang
http://bugs.freedesktop.org/show_bug.cgi?id=25994 Jesse Barnes jbar...@virtuousgeek.org changed: What|Removed |Added AssignedTo|jbar...@virtuousgeek.org|i...@freedesktop.org -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
[Mesa3d-dev] [PATCH 1/2] libgl: Enable compiling libGL without GLX functions and X dependencies
This lets us link EGL apps with libGL without pulling in X dependencies. --- configs/autoconf.in |2 + configure.ac| 99 +++ src/gallium/state_trackers/egl/Makefile |1 + src/glx/x11/Makefile| 16 +++-- 4 files changed, 72 insertions(+), 46 deletions(-) diff --git a/configs/autoconf.in b/configs/autoconf.in index 3063787..5eb7770 100644 --- a/configs/autoconf.in +++ b/configs/autoconf.in @@ -41,6 +41,8 @@ INSTALL = @INSTALL@ PYTHON2 = python PYTHON_FLAGS = -t -O -O +WITH_GLX = @WITH_GLX@ + # Library names (base name) GL_LIB = GL GLU_LIB = GLU diff --git a/configure.ac b/configure.ac index b6c6535..8c17312 100644 --- a/configure.ac +++ b/configure.ac @@ -85,6 +85,7 @@ AC_SUBST([X11_INCLUDES]) dnl Compiler macros DEFINES= AC_SUBST([DEFINES]) +AC_SUBST([GLX_DEFINES]) case $host_os in linux*|*-gnu*|gnu*) DEFINES=$DEFINES -D_GNU_SOURCE -DPTHREADS @@ -486,12 +487,7 @@ dnl If $with_demos is yes, directories will be added as libs available PROGRAM_DIRS= case $with_demos in no) ;; -yes) -# If the driver isn't osmesa, we have libGL and can build xdemos -if test $mesa_driver != osmesa; then -PROGRAM_DIRS=xdemos -fi -;; +yes) ;; *) # verify the requested demos directories exist demos=`IFS=,; echo $with_demos` @@ -592,33 +588,34 @@ dri) DRI_PC_REQ_PRIV=libdrm = $LIBDRM_REQUIRED # find the DRI deps for libGL -if test $x11_pkgconfig = yes; then -# add xcb modules if necessary -dri_modules=x11 xext xxf86vm xdamage xfixes -if test $enable_xcb = yes; then -dri_modules=$dri_modules x11-xcb xcb-glx -fi - -PKG_CHECK_MODULES([DRIGL], [$dri_modules]) -GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV $dri_modules -X11_INCLUDES=$X11_INCLUDES $DRIGL_CFLAGS -GL_LIB_DEPS=$DRIGL_LIBS -else -# should check these... -X11_INCLUDES=$X11_INCLUDES $X_CFLAGS -GL_LIB_DEPS=$X_LIBS -lX11 -lXext -lXxf86vm -lXdamage -lXfixes -GL_PC_LIB_PRIV=$GL_LIB_DEPS -GL_PC_CFLAGS=$X11_INCLUDES +if test $enable_glx = yes; then +if test $x11_pkgconfig = yes; then + # add xcb modules if necessary +dri_modules=x11 xext xxf86vm xdamage xfixes +if test $enable_xcb = yes; then +dri_modules=$dri_modules x11-xcb xcb-glx +fi -# XCB can only be used from pkg-config -if test $enable_xcb = yes; then -PKG_CHECK_MODULES([XCB],[x11-xcb xcb-glx]) -GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV x11-xcb xcb-glx -X11_INCLUDES=$X11_INCLUDES $XCB_CFLAGS -GL_LIB_DEPS=$GL_LIB_DEPS $XCB_LIBS +PKG_CHECK_MODULES([DRIGL], [$dri_modules]) +GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV $dri_modules +X11_INCLUDES=$X11_INCLUDES $DRIGL_CFLAGS +GL_LIB_DEPS=$DRIGL_LIBS +else +# should check these... +X11_INCLUDES=$X11_INCLUDES $X_CFLAGS +GL_LIB_DEPS=$X_LIBS -lX11 -lXext -lXxf86vm -lXdamage -lXfixes +GL_PC_LIB_PRIV=$GL_LIB_DEPS +GL_PC_CFLAGS=$X11_INCLUDES + +# XCB can only be used from pkg-config +if test $enable_xcb = yes; then +PKG_CHECK_MODULES([XCB],[x11-xcb xcb-glx]) +GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV x11-xcb xcb-glx +X11_INCLUDES=$X11_INCLUDES $XCB_CFLAGS +GL_LIB_DEPS=$GL_LIB_DEPS $XCB_LIBS +fi fi -fi - +fi # need DRM libs, -lpthread, etc. GL_LIB_DEPS=$GL_LIB_DEPS $LIBDRM_LIBS -lm -lpthread $DLOPEN_LIBS GL_PC_LIB_PRIV=-lm -lpthread $DLOPEN_LIBS @@ -710,10 +707,11 @@ if test $mesa_driver = dri; then case $host_os in linux*) DEFINES=$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER + GLX_DEFINES=-DGLX_INDIRECT_RENDERING if test x$driglx_direct = xyes; then -DEFINES=$DEFINES -DGLX_DIRECT_RENDERING +GLX_DEFINES=$GLX_DEFINES -DGLX_DIRECT_RENDERING fi -DEFINES=$DEFINES -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS +DEFINES=$DEFINES -DHAVE_ALIAS case $host_cpu in x86_64) @@ -744,9 +742,9 @@ if test $mesa_driver = dri; then freebsd* | dragonfly*) DEFINES=$DEFINES -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 DEFINES=$DEFINES -DIN_DRI_DRIVER -DHAVE_ALIAS -DEFINES=$DEFINES -DGLX_INDIRECT_RENDERING + GLX_DEFINES=-DGLX_INDIRECT_RENDERING if test x$driglx_direct = xyes; then -DEFINES=$DEFINES -DGLX_DIRECT_RENDERING +GLX_DEFINES=$GLX_DEFINES -DGLX_DIRECT_RENDERING fi if test x$GXX = xyes; then CXXFLAGS=$CXXFLAGS -ansi -pedantic @@ -761,13 +759,14 @@ if test $mesa_driver = dri; then ;; gnu*) DEFINES=$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -
[Mesa3d-dev] [PATCH 0/2] Make GLX optional in libGL
These two patches move things around in GLX a bit. To make it possible to use libGL with EGL on framebuffer without pulling in X dependencies this patch make the GLX entry points and all the indirect API a ./configure time option. When disabled, libGL is essentially just glapi and needs libEGL to be useful. I had to go back to using a list of glapi object files instead of libglapi.a, since without the glx functions nothing is left to pull in the glapi files. The other patch renames glx to gl, now that it's no longer glx only, and moves the code up one level from src/glx/x11 to src/gl. The patch drops src/glx/mini; it's DRI1 only, not maintained and EGL on KMS is a better solution for the use cases where miniglx was useful. Kristian Høgsberg (2): libgl: Enable compiling libGL without GLX functions and X dependencies Move src/glx/x11 to src/gl, drop glx/mini Makefile |7 +- configs/autoconf.in |2 + configs/darwin |4 +- configs/freebsd-dri |2 +- configs/linux-dri|2 +- configs/linux-dri-xcb|2 +- configs/linux-indirect |2 +- configure.ac | 101 +- src/gallium/state_trackers/egl/Makefile |5 +- src/gallium/state_trackers/egl/x11/glxinit.c |2 +- src/gl/Makefile | 99 + src/gl/XF86dri.c | 637 ++ src/gl/clientattrib.c| 142 + src/gl/compsize.c| 189 + src/gl/dri2.c| 631 ++ src/gl/dri2.h| 106 + src/gl/dri2_glx.c| 655 ++ src/gl/dri_common.c | 450 ++ src/gl/dri_common.h | 63 + src/gl/dri_glx.c | 751 ++ src/gl/drisw_glx.c | 456 ++ src/gl/eval.c| 132 + src/gl/glcontextmodes.c | 544 ++ src/gl/glcontextmodes.h | 54 + src/gl/glx_pbuffer.c | 724 ++ src/gl/glx_query.c | 177 + src/gl/glxclient.h | 803 ++ src/gl/glxcmds.c | 3173 src/gl/glxcurrent.c | 513 ++ src/gl/glxext.c | 1048 +++ src/gl/glxextensions.c | 714 ++ src/gl/glxextensions.h | 292 + src/gl/glxhash.c | 473 ++ src/gl/glxhash.h | 20 + src/gl/indirect.c|10669 ++ src/gl/indirect.h| 721 ++ src/gl/indirect_init.c | 785 ++ src/gl/indirect_init.h | 41 + src/gl/indirect_size.c | 388 + src/gl/indirect_size.h | 88 + src/gl/indirect_texture_compression.c| 343 + src/gl/indirect_transpose_matrix.c | 85 + src/gl/indirect_vertex_array.c | 1985 + src/gl/indirect_vertex_array.h | 64 + src/gl/indirect_vertex_array_priv.h | 311 + src/gl/indirect_vertex_program.c | 293 + src/gl/indirect_window_pos.c | 112 + src/gl/packrender.h | 243 + src/gl/packsingle.h | 213 + src/gl/pixel.c | 461 ++ src/gl/pixelstore.c | 352 + src/gl/render2.c | 381 + src/gl/renderpix.c | 218 + src/gl/single2.c | 974 +++ src/gl/singlepix.c | 196 + src/gl/vertarr.c | 212 + src/gl/xf86dri.h | 124 + src/gl/xf86dristr.h | 367 + src/gl/xfont.c | 377 + src/glx/Makefile | 12 - src/glx/mini/Makefile| 89 - src/glx/mini/NOTES | 115 - src/glx/mini/dispatch.c | 64 - src/glx/mini/driver.h| 168 - src/glx/mini/example.miniglx.conf| 36 - src/glx/mini/miniglx.c | 2580 --- src/glx/mini/miniglxP.h | 205 - src/glx/mini/miniglx_events.c| 983 --- src/glx/x11/Makefile | 97 - src/glx/x11/XF86dri.c| 637 -- src/glx/x11/clientattrib.c | 142 - src/glx/x11/compsize.c | 189 - src/glx/x11/dri2.c | 631 -- src/glx/x11/dri2.h
Re: [Mesa3d-dev] Gallium DRI fbconfig/visual setup
On 05.02.2010 22:48, Corbin Simpson wrote: Two things... Are accumbufs still slow in Gallium-land? Should we still mark them as slow? How many multisamples should we actually pretend/advertise? Should we have a cap to check the number of multisamples supported? Should we just say that four samples are done for the fbconfig/visual, and then replace pipe_texture::nr_samples with a multisample boolean flag? I think it would be nice if we could support multiple MSAA levels. Sure hardware typically can do 4xMSAA, but maybe you'd really want max quality (with modern hw often offering 8x, and that's not taking specialties like csaa into account) or only 2x. Maybe cap should return a bitmask indicating what levels it supports. Roland -- 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
[Mesa3d-dev] [PATCH] Gallium: Add Solaris atomic function definitions to u_atomic.h
Signed-off-by: Alan Coopersmith alan.coopersm...@sun.com
---
src/gallium/auxiliary/util/u_atomic.h | 36 -
1 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_atomic.h
b/src/gallium/auxiliary/util/u_atomic.h
index 540112f..e4750c0 100644
--- a/src/gallium/auxiliary/util/u_atomic.h
+++ b/src/gallium/auxiliary/util/u_atomic.h
@@ -20,7 +20,9 @@
*/
#if (defined(PIPE_SUBSYSTEM_WINDOWS_DISPLAY) || \
defined(PIPE_SUBSYSTEM_WINDOWS_MINIPORT))
-#define PIPE_ATOMIC_OS_UNLOCKED
+#define PIPE_ATOMIC_OS_UNLOCKED
+#elif defined(PIPE_OS_SOLARIS)
+#define PIPE_ATOMIC_OS_SOLARIS
#elif defined(PIPE_CC_MSVC)
#define PIPE_ATOMIC_MSVC_INTRINSIC
#elif (defined(PIPE_CC_MSVC) defined(PIPE_ARCH_X86))
@@ -260,6 +262,38 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
#endif
+#if defined(PIPE_ATOMIC_OS_SOLARIS)
+
+#define PIPE_ATOMIC Solaris OS atomic functions
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+#include atomic.h
+
+#define p_atomic_set(_v, _i) (*(_v) = (_i))
+#define p_atomic_read(_v) (*(_v))
+
+static INLINE boolean
+p_atomic_dec_zero(int32_t *v)
+{
+ uint32_t n = atomic_dec_32_nv((uint32_t *) v);
+
+ return n != 0;
+}
+
+#define p_atomic_inc(_v) atomic_inc_32((uint32_t *) _v)
+#define p_atomic_dec(_v) atomic_dec_32((uint32_t *) _v)
+
+#define p_atomic_cmpxchg(_v, _old, _new) \
+ atomic_cas_32( (uint32_t *) _v, (uint32_t) _old, (uint32_t) _new)
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
#ifndef PIPE_ATOMIC
--
1.5.6.5
--
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
Re: [Mesa3d-dev] [PATCH] Gallium: Add Solaris atomic function definitions to u_atomic.h
From: Alan Coopersmith [alan.coopersm...@sun.com]
Sent: Saturday, February 06, 2010 3:37
To: mesa3d-dev@lists.sourceforge.net
Cc: Alan Coopersmith
Subject: [Mesa3d-dev] [PATCH] Gallium: Add Solaris atomic function
definitions to u_atomic.h
Signed-off-by: Alan Coopersmith alan.coopersm...@sun.com
---
src/gallium/auxiliary/util/u_atomic.h | 36 -
1 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_atomic.h
b/src/gallium/auxiliary/util/u_atomic.h
index 540112f..e4750c0 100644
--- a/src/gallium/auxiliary/util/u_atomic.h
+++ b/src/gallium/auxiliary/util/u_atomic.h
@@ -20,7 +20,9 @@
*/
#if (defined(PIPE_SUBSYSTEM_WINDOWS_DISPLAY) || \
defined(PIPE_SUBSYSTEM_WINDOWS_MINIPORT))
-#define PIPE_ATOMIC_OS_UNLOCKED
+#define PIPE_ATOMIC_OS_UNLOCKED
+#elif defined(PIPE_OS_SOLARIS)
+#define PIPE_ATOMIC_OS_SOLARIS
#elif defined(PIPE_CC_MSVC)
#define PIPE_ATOMIC_MSVC_INTRINSIC
#elif (defined(PIPE_CC_MSVC) defined(PIPE_ARCH_X86))
@@ -260,6 +262,38 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
#endif
+#if defined(PIPE_ATOMIC_OS_SOLARIS)
+
+#define PIPE_ATOMIC Solaris OS atomic functions
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+#include atomic.h
It's probably fine for Solaris, but putting OS includes inside extern C
sometimes causes problems -- it does with certain MS headers.
Other than that it looks fine.
Jose
+
+#define p_atomic_set(_v, _i) (*(_v) = (_i))
+#define p_atomic_read(_v) (*(_v))
+
+static INLINE boolean
+p_atomic_dec_zero(int32_t *v)
+{
+ uint32_t n = atomic_dec_32_nv((uint32_t *) v);
+
+ return n != 0;
+}
+
+#define p_atomic_inc(_v) atomic_inc_32((uint32_t *) _v)
+#define p_atomic_dec(_v) atomic_dec_32((uint32_t *) _v)
+
+#define p_atomic_cmpxchg(_v, _old, _new) \
+ atomic_cas_32( (uint32_t *) _v, (uint32_t) _old, (uint32_t) _new)
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
#ifndef PIPE_ATOMIC
--
1.5.6.5
--
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
--
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
Re: [Mesa3d-dev] [PATCH] Gallium: Add Solaris atomic function definitions to u_atomic.h
Jose Fonseca wrote:
+#ifdef __cplusplus
+extern C {
+#endif
+
+#include atomic.h
It's probably fine for Solaris, but putting OS includes inside extern C
sometimes causes problems -- it does with certain MS headers.
Other than that it looks fine.
Hmm, hadn't thought about it - do C++ compilers get upset if you have nested
extern C blocks? The entire atomic.h header is already inside one so could
move out without issue:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/atomic.h
--
-Alan Coopersmith- alan.coopersm...@sun.com
Sun Microsystems, Inc. - X Window System Engineering
--
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
Re: [Mesa3d-dev] [PATCH] Gallium: Add Solaris atomic function definitions to u_atomic.h
I think nested extern C is alright. The problem I hit was that the header
provided some optional C++ interfaces, and the compiler barfed at having C++
inside extern C { .. }.
Jose
From: alan.coopersm...@sun.com [alan.coopersm...@sun.com]
Sent: Saturday, February 06, 2010 6:00
To: Jose Fonseca
Cc: mesa3d-dev@lists.sourceforge.net
Subject: Re: [Mesa3d-dev] [PATCH] Gallium: Add Solaris atomic function
definitions to u_atomic.h
Jose Fonseca wrote:
+#ifdef __cplusplus
+extern C {
+#endif
+
+#include atomic.h
It's probably fine for Solaris, but putting OS includes inside extern C
sometimes causes problems -- it does with certain MS headers.
Other than that it looks fine.
Hmm, hadn't thought about it - do C++ compilers get upset if you have nested
extern C blocks? The entire atomic.h header is already inside one so could
move out without issue:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/atomic.h
--
-Alan Coopersmith- alan.coopersm...@sun.com
Sun Microsystems, Inc. - X Window System Engineering
--
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
