Re: [Mesa3d-dev] Bug in mesa-master: Deadlock for multi-threaded glx apps inside __glXInitialize()
On Sun, Aug 1, 2010 at 11:19 PM, Mario Kleiner wrote: > Think i sent it to the wrong mailing list. Here we go again... > > Begin forwarded message: > >> From: Mario Kleiner >> Date: July 27, 2010 2:56:04 AM GMT+02:00 >> To: Kristian Hogsberg , xorg-de...@lists.x.org >> Subject: Bug: Deadlock for multi-threaded glx apps inside >> __glXInitialize() >> >> Hi Kristian >> >> Testing with current mesa master, my toolkit deadlocks on the first call >> to a glX function (glXChooseVisual()). >> >> The deadlock was probably introduced by your recent commit: >> >> "glx: Use _Xglobal_lock for protecting extension display list" >> >> ab434f6b7641a64d30725a9ac24929240362d466 >> >> The problem is that the _Xglobal_lock is locked twice inside the >> __glXInitialize() function of mesa/src/glx/glxext.c, once inside >> __glXInitialize(), and then as part of dri2CreateDisplay() -> ... -> >> XextFindDisplay. The 2nd locking call on the already held lock deadlocks. >> >> Attached a backtrace with the problem and a patch/hack that "fixes" it for >> me, but introduces a race-condition itself, so this is obviously not the >> correct solution. The race condition would trigger if two threads would >> simultaneously do their first call to a glX function for the same Display* >> dpy handle, rather unlikely to happen in practice? If so, then the patch >> might be an acceptable fix until a better solution is found? I changed the code to just drop the lock while we create and initialize the glx display. Once we're ready to add it to the list, we take the lock again. After making sure nobody beat us to initializing glx on the display, we add it to the global list. I think that should work. >> Other applications (glxgears, games etc.) work correctly. The difference >> is that my toolkit calls XInitThreads() at startup to use xlib >> multi-threaded and afaik the locking calls only get enabled if xlib is >> switched to thread-safe mode, otherwise they are no-ops? If i omit >> XInitThreads() everything works again. Yes, that makes sense, that's why I didn't see it. thanks, Kristian -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] egl_dri2: Checking for xcb/dri2.h and xcb/xfixes.h
On Fri, Jul 16, 2010 at 7:59 AM, Sedat Dilek wrote: > On Fri, Jul 16, 2010 at 1:43 PM, Chia-I Wu wrote: >> On Wed, Jul 14, 2010 at 1:53 AM, Sedat Dilek >> wrote: >>> On Tue, Jul 13, 2010 at 5:25 PM, Sedat Dilek >>> wrote: >>> [...] Shouldn't there be a more rough depend-checking on XCB_DRI2 (libxcb-1.6) in configure.ac? With "rough" I mean to stop immediately the build, so someone can check for the missing packages. >>> >>> Looking at [1] feom >>> >>> Commit 2168b87b51e70e8ad914e547c6c922fc33af3a89 >>> "egl_dri2: Support _EGL_PLATFORM_DRM" >>> >>> [configure.ac] >>> ... >>> # build egl_dri2 when xcb-dri2 is available >>> - PKG_CHECK_MODULES([EGL_DRI2], [x11-xcb xcb-dri2 xcb-xfixes libdrm], >>> + PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes], >>> [have_xcb_dri2=yes],[have_xcb_dri2=no]) >>> + PKG_CHECK_MODULES([LIBUDEV], [libudev > 150], >>> + [have_libudev=yes],[have_libudev=no]) >>> + >>> if test "$have_xcb_dri2" = yes; then >>> - EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS dri2" >>> + EGL_DRIVER_DRI2=dri2 >>> + DEFINES="$DEFINES -DHAVE_XCB_DRI2" >>> + fi >>> + >>> + if test "$have_libudev" = yes; then >>> + EGL_DRIVER_DRI2=dri2 >>> + DEFINES="$DEFINES -DHAVE_LIBUDEV" >>> fi >>> + >>> + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" >>> ... >>> >>> So if $have_xcb_dri2 is false, but $have_libudev true, >>> $EGL_DRIVER_DRI2 is set to "dri2" and the compilation of egl_dri2 will >>> be broken. >>> >>> What about...? >>> >>> - EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" >>> + if test "$have_xcb_dri2" = no; then >>> + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS" >>> + else >>> + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" >>> + fi >>> >>> - Sedat - >>> >>> [1] >>> http://cgit.freedesktop.org/mesa/mesa/diff/configure.ac?id=2168b87b51e70e8ad914e547c6c922fc33af3a89 >> I will commit a fix so that egl_dri2 is built only when xcb-dri2 is >> available. >> I believe Krisitian wants to make xcb-dri2 optional, but it does not seem to >> be >> the case right now. >> >> >> -- >> o...@lunarg.com >> > > Sounds good to me, thanks for your attention. Yup, sounds fine, thanks Chia-I. Kristian -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] GLES1/2 and DRI drivers
Hi, I've been looking into the GLES1/2 support in mesa and trying to figure out how to make it work for DRI drivers as well. The current approach only works for gallium, and it works by compiling mesa core as different state trackers. Each state tracker is just a thin filter on top of the public API and in the end, the result is essentially three copies of the mesa state tracker that all load the same gallium chipset driver to deal with the hardware. As far as I understand it, anyway. I would like to propose that we structure the code a bit differently, specifically I would like to see a way where we can load one DRI driver which can implement multiple GL APIs. I understand that gallium was designed to support mulitple APIs, however, in the case of gl/gles1/gles2, there is a big overlap, and we can support all three without different state trackers. Specifically, what I'm thinking of is - the dri driver gets a new entry point that lets us create a context for a specified API (along these lines: http://cgit.freedesktop.org/~krh/mesa/commit/?h=gles2&id=707ad2057e5a2ab2e5fa36be77de373ed98967c5) - mesa core becomes multi api aware, struct gl_context gets a new API field - move the es entry points from src/mesa/es into src/mesa/main - create src/gles1 and src/gles2 directories for compiling libGLESv1.so and libGLESv2.so; basically glapi-es2 as a shared object file. Obviously, we should keep the option to compile mesa state tracker as gles1 or gles2 only for example (to allow building a small gles2-only dri driver and to keep the current gallium setup working). This is all still work in progress for me, but I'm curious what people think of this approach. Thanks, Kristian -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] glx: Fix config chooser logic for 'mask' matching
2010/4/9 Ian Romanick : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Kristian Høgsberg wrote: >> When matching attributes using the 'mask' matching criteria, the spec >> says that >> >> "Only GLXFBConfigs for which the set bits of attribute include all >> the bits that are set in the requested value are >> considered. (Additional bits might be set in the attribute)." >> >> The current test returns true if the two bit masks have bits in >> common, specifically it matches even if the requested value has bits >> set that are not set in the fbconfig attribute. For example, an >> application asking for >> >> GLX_DRAWABLE_TYPE, GLX_PIXMAP_BIT | GLX_PBUFFER_BIT, >> >> as glxpbdemo does, will match fbconfigs that don't support pbuffer >> rendering, as long as they support pixmap rendering. > > Reviewed-by: Ian Romanick Thanks. > This should go into master, 7.8, and mesa_7_7_branch. Done. > Are there any > specific bugs associated with this? If so, those should be documented > in the commit message. Not that I know. I just ran into it when trying to run glxpbdemo. Kristian -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] glx: Fix config chooser logic for 'mask' matching
When matching attributes using the 'mask' matching criteria, the spec
says that
"Only GLXFBConfigs for which the set bits of attribute include all
the bits that are set in the requested value are
considered. (Additional bits might be set in the attribute)."
The current test returns true if the two bit masks have bits in
common, specifically it matches even if the requested value has bits
set that are not set in the fbconfig attribute. For example, an
application asking for
GLX_DRAWABLE_TYPE, GLX_PIXMAP_BIT | GLX_PBUFFER_BIT,
as glxpbdemo does, will match fbconfigs that don't support pbuffer
rendering, as long as they support pixmap rendering.
---
src/glx/glxcmds.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 7cdd42c..e256a07 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1110,6 +1110,13 @@ init_fbconfig_for_chooser(__GLcontextModes * config,
} \
} while ( 0 )
+/* Test that all bits from a are contained in b */
+#define MATCH_MASK(param) \
+ do { \
+if ((a->param & ~b->param) != 0) \
+ return False;\
+ } while (0);
+
/**
* Determine if two GLXFBConfigs are compatible.
*
@@ -1148,11 +1155,8 @@ fbconfigs_compatible(const __GLcontextModes * const a,
MATCH_DONT_CARE(stereoMode);
MATCH_EXACT(level);
- if (((a->drawableType & b->drawableType) == 0)
- || ((a->renderType & b->renderType) == 0)) {
- return False;
- }
-
+ MATCH_MASK(drawableType);
+ MATCH_MASK(renderType);
/* There is a bug in a few of the XFree86 DDX drivers. They contain
* visuals with a "transparent type" of 0 when they really mean GLX_NONE.
--
1.7.0.1
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [xserver patch v5 3/5] glx: Enforce a 1:1 correspondence between GLX and X11 windows.
2010/3/22 Ian Romanick : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Kristian Høgsberg wrote: >> 2010/2/8 Francisco Jerez : >>> The spec says (regarding glXCreateWindow): "If there is already a >>> GLXFBConfig associated with win (as a result of a previous >>> glXCreateWindow call), then a BadAlloc error is generated.". It will >>> also come useful to implement DRI2InvalidateBuffers for the indirect >>> case. >>> >>> Signed-off-by: Francisco Jerez > > I've put this version of this patch (with krh's R-b) in my GLX-fixes > tree. Are the all the rest in Kristian's dri2-invalidate tree? We dropped this one, and the rest is in my dri2-invalidate tree. Kristian -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Remove color index rendering?
On Fri, Feb 19, 2010 at 10:43 PM, Corbin Simpson wrote: > Can we doc it and comment it out? IME somebody will pop out and claim a use > for it. With git, which lets you search and query history fast and easily, there's never really and excuse for commenting/#ifdef'ing something out. If somebody wants to revive CI rendering, digging it out from git is going to be the least of his problems. Kristian > Posting from a mobile, pardon my terseness. ~ C. > > On Feb 19, 2010 5:19 PM, "Ian Romanick" wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > While we're on the topic of removing dead weight, can we remove support > for color index rendering? None of the hardware drivers support color > index rendering, and color index rendering is deprecated in OpenGL 3.0 > (and removed in 3.1). > > Can it please die in a fire? > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkt/Kd8ACgkQX1gOwKyEAw+zpQCgj+Yr0Bo3e6O3BijR5KYEds48 > DfIAniZibZEaXZsO0qYa9OW5745LM9xL > =tcrK > -END PGP SIGNATURE- > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa removals
On Mon, Feb 22, 2010 at 11:38 AM, Brian Paul wrote: > Starting a new thread on this... > > Here's a proposal of things to remove from the Mesa tree. > > GLU: > glu/mini > glu/mesa > > GLUT: > glut/fbdev > glut/ggi > glut/directfb > glut/dos > glut/mini > glut/os2 > > non-DRI drivers: > drivers/allegro > drivers/directfb > drivers/d3d > drivers/dos > drivers/ggi > drivers/glide > drivers/svga > > DRI drivers: > drivers/dri/fb > drivers/dri/ffb > drivers/dri/gamma > > progs/directfb > progs/ggi > progs/windml > progs/miniglx > > Comments? This was posted four days ago and I didn't hear any objections, only some nostalgia background noise. I've removed all the drivers and subdirectories mentioned above and posted the result in the mesa-cleanup branch in git://anongit.freedesktop.org/~krh/mesa Brian, if that looks ok to you, I can push that to the main mesa repo now Kristian -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 10/12] egl_dri2: Implement EGL_KHR_image and EGL_KHR_image_pixmap
2010/2/18 Chia-I Wu : > On Thu, Feb 18, 2010 at 12:04:14PM -0500, Kristian Høgsberg wrote: >> 2010/2/12 Ian Romanick : ... >> > Since applications call this function directly, should this give an >> > error if dri2_dpy->image is NULL, or is it okay to just segfault? >> If __DRIimage isn't available, eglInitializeDisplay fails. I suppose >> we should make that optional and just not advertise any EGLImage >> extensions instead. > It should be noted that eglapi.c does not check if an extension is > available before dispatching (while it probably should). > > BTW, it seems > > dri2_dpy->base.Extensions.KHR_image_base and > dri2_dpy->base.Extensions.KHR_image_pixmap > > are not set in the patch to advertise the extensions. Done. thanks, Kristian -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
2010/2/19 Brian Paul : > 2010/2/19 Kristian Høgsberg : >> 2010/2/19 Kristian Høgsberg : >>> 2010/2/19 Brian Paul : >>>> 2010/2/19 Kristian Høgsberg : >>>> >>>>> I applied the patches from Kenneth Graunke on the list for this. Can >>>>> we drop _mesa_malloc(), _mesa_calloc() and _mesa_free() and >>>>> _mesa_bzero() too? >>>> >>>> I've remove _mesa_bzero() just now, plus some other macro wrappers. >>>> >>>> We might as well remove the malloc/calloc() wrappers too, but that'll >>>> be a bit more work. >>> >>> I'm using: >>> >>> git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g >>> >>> which does most of the work. I'll do the same thing for _mesa_calloc >>> and _mesa_free, review the result and commit that. >> >> All done. I was looking at the MALLOC, CALLOC, MALLOC_STRUCT, >> CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the >> _mesa_align_* functions. Do we want to drop those too? I hesitated >> because src/gallium/README.portability says "Use MALLOC, CALLOC, FREE >> instead of the malloc, calloc, free functions." But as far as I can >> see, they're not redefined or anything for gallium and they just >> resolve to the standard malloc, calloc and free functions. Am I >> missing something? > > Let's keep the Gallium code as-is. > > But for Mesa: > > MALLOC_STRUCT and CALLOC_STRUCT should be kept. They save a lot of typing. > > MALLOC, CALLOC, and FREE can go. The ALIGN macros could probably go > too (just call the align functions). > > Years ago, some systems defined malloc() as returning char * instead > of void * so the Mesa wrappers helped with casting. Plus, back before > valgrind I'd often rig up my own malloc-debug code to track down > memory errors. The macros were handy for that. Ok, I droppped the ALIGN macros, but I'll leave the rest as is. Not sure what Jose has in mind, but I hope we can drop the MALLOC, CALLOC and FREE wrappers as well. At least on Linux today, we have valgrind and LD_PRELOAD tricks available to do malloc debugging that doesn't require malloc wrappers. Kristian -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
2010/2/19 Kristian Høgsberg : > 2010/2/19 Brian Paul : >> 2010/2/19 Kristian Høgsberg : >> >>> I applied the patches from Kenneth Graunke on the list for this. Can >>> we drop _mesa_malloc(), _mesa_calloc() and _mesa_free() and >>> _mesa_bzero() too? >> >> I've remove _mesa_bzero() just now, plus some other macro wrappers. >> >> We might as well remove the malloc/calloc() wrappers too, but that'll >> be a bit more work. > > I'm using: > > git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g > > which does most of the work. I'll do the same thing for _mesa_calloc > and _mesa_free, review the result and commit that. All done. I was looking at the MALLOC, CALLOC, MALLOC_STRUCT, CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the _mesa_align_* functions. Do we want to drop those too? I hesitated because src/gallium/README.portability says "Use MALLOC, CALLOC, FREE instead of the malloc, calloc, free functions." But as far as I can see, they're not redefined or anything for gallium and they just resolve to the standard malloc, calloc and free functions. Am I missing something? Kristian -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
2010/2/19 Brian Paul : > 2010/2/19 Kristian Høgsberg : > >> I applied the patches from Kenneth Graunke on the list for this. Can >> we drop _mesa_malloc(), _mesa_calloc() and _mesa_free() and >> _mesa_bzero() too? > > I've remove _mesa_bzero() just now, plus some other macro wrappers. > > We might as well remove the malloc/calloc() wrappers too, but that'll > be a bit more work. I'm using: git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g which does most of the work. I'll do the same thing for _mesa_calloc and _mesa_free, review the result and commit that. >> What about the _mesa_*printf() functions? It >> looks to me like they just wrap the platform *printf() functions and >> don't provide any fallbacks if the platform doesn't provide the >> function. > > That's probably fine too. I'll use the same sed line for the *printf functions. Kristian -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
On Thu, Feb 18, 2010 at 7:25 PM, Brian Paul wrote: > Ian Romanick wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Ian Romanick wrote: >>> All, >>> >>> It's time again to plan what version or versions of Mesa we want to >>> release in Q1 (end of March). It seems like 7.7.1 is a no-brainer. Do >>> we also want to release Mesa 7.8? I haven't been keeping track of >>> master, so I don't know what its state is. Is it pretty stable? Are >>> there any big branches waiting to land? >>> >>> Working backwards from a "last week of March" release, master would have >>> to branch to mesa_7_8_branch during the last week of February. That's >>> roughly 6 weeks away. >>> >>> Thoughts? Opinions? >> >> Assuming this plan still works for people, I'll make the mesa_7_8_branch >> on Friday, February 26th. > > I think we could get by with a shorter "beta" period. There's a few > more things that would be nice to do for 7.8 which I doubt I'd get to > before the 26th: > > 1. GL_APPLE_object_purgeable - I think the last round of patches > looked OK. Chris? > > 2. _mesa_memcpy() -> memcpy(), etc. replacement. There were patches > for this that haven't been applied yet. Maybe someone could pick > those up. I applied the patches from Kenneth Graunke on the list for this. Can we drop _mesa_malloc(), _mesa_calloc() and _mesa_free() and _mesa_bzero() too? What about the _mesa_*printf() functions? It looks to me like they just wrap the platform *printf() functions and don't provide any fallbacks if the platform doesn't provide the function. > 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx, > allegro, ggi, dri/mga, dri/mach64. Maybe more. Any objections? Sounds great. As George suggests, maybe we can drop dri/fb and dri/ffb too? What about d3d? I don't know much about the driver, but I don't see a lot of commits there since 1999 except mechanical changes to keep it compiling. Finally, I'd like to land EGLImage support for the dri2 EGL driver, which I should be able to do next week. thanks, Kristian -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 08/12] intel: Implement DRI image extension
2010/2/18 Brian Paul :
> Kristian Høgsberg wrote:
>>
>> 2010/2/12 Ian Romanick :
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Kristian Høgsberg wrote:
>>>>
>>>> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
>>>> b/src/mesa/drivers/dri/intel/intel_screen.c
>>>> index f7ce87e..c2c8c6e 100644
>>>> --- a/src/mesa/drivers/dri/intel/intel_screen.c
>>>> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
>>>> @@ -41,6 +41,7 @@
>>>> #include "intel_fbo.h"
>>>> #include "intel_screen.h"
>>>> #include "intel_tex.h"
>>>> +#include "intel_regions.h"
>>>>
>>>> #include "i915_drm.h"
>>>>
>>>> @@ -141,11 +142,84 @@ static const struct __DRI2flushExtensionRec
>>>> intelFlushExtension = {
>>>> intelDRI2FlushInvalidate,
>>>> };
>>>>
>>>> +static __DRIimage *
>>>> +intel_create_image_internal(__DRIcontext *context,
>>>> + int width, int height, int internal_format,
>>>> + int name, int pitch, void *loaderPrivate)
>>>> +{
>>>> + __DRIimage *image;
>>>> + struct intel_context *intel = context->driverPrivate;
>>>> + int cpp;
>>>> +
>>>> + image = CALLOC(sizeof *image);
>>>> + image->internal_format = internal_format;
>>>> + switch (internal_format) {
>>>> + case GL_RGBA:
>>>> + image->format = MESA_FORMAT_ARGB;
>>>> + image->data_type = GL_UNSIGNED_BYTE;
>>>> + break;
>>>> + case GL_RGB:
>>>> + image->format = MESA_FORMAT_XRGB;
>>>> + image->data_type = GL_UNSIGNED_BYTE;
>>>> + break;
>>>> + }
>>>
>>> No love for 565 or pixmaps?
>>
>> Good question. What is a sufficient way to specify the pixel format?
>> Internal format + datatype? That's what glTexImage2D uses and should
>> be enough to describe the type of content and layout of the color
>> components, for example GL_RGB8 + GL_UNSIGNED_INT_8_8_8_8.
>
> That particular format/type combo is invalid for glTexImage, btw.
That was meant as an internalformat/type combo - that's valid right?
>> Alternatively we can expose the MESA_FORMAT_* values as __DRI_FORMAT_*
>> tokens and use that in the __DRIimage extension.
>
> I haven't followed this too closely... but FYI, there's no guarantee that
> the MESA_FORMAT_x token values won't change at any time. If you create some
> __DRI_FORMAT_x tokens they should probably have different values just to be
> safe.
Yeah, they would be different tokens, the idea was to specify color
components and layout with one token similar to how the MESA_FORMAT_*
defines work, not to expose the MESA_FORMAT_* values directly. But
I'm leaning aginst not going for this idea.
I'm trying to figure out if it's appropriate to assume that all
drivers for a given chipset will choose the same pixel layout for, say
GL_RGBA8 or GL_RGB5. Then when we create an EGLImage from a GEM (or
TTM) handle we only need to pass GL_RGBA8 as the format value and the
driver will know how the components are laid out. Or do we need to
specify the pixel layout as well. Still not sure...
Kristian
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 10/12] egl_dri2: Implement EGL_KHR_image and EGL_KHR_image_pixmap
2010/2/12 Ian Romanick :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Kristian Høgsberg wrote:
>> diff --git a/src/egl/drivers/dri2/egl_dri2.c
>> b/src/egl/drivers/dri2/egl_dri2.c
>> index 5d36c49..1590190 100644
>> --- a/src/egl/drivers/dri2/egl_dri2.c
>> +++ b/src/egl/drivers/dri2/egl_dri2.c
>> @@ -42,7 +42,6 @@
>> #include
>>
>> #include
>> -#include "eglconfigutil.h"
>> #include "eglconfig.h"
>> #include "eglcontext.h"
>> #include "egldisplay.h"
>> @@ -50,6 +49,7 @@
>> #include "eglcurrent.h"
>> #include "egllog.h"
>> #include "eglsurface.h"
>> +#include "eglimage.h"
>>
>> struct dri2_egl_driver
>> {
>> @@ -67,10 +67,12 @@ struct dri2_egl_display
>> __DRIdri2Extension *dri2;
>> __DRI2flushExtension *flush;
>> __DRItexBufferExtension *tex_buffer;
>> + __DRIimageExtension *image;
>> int fd;
>>
>> __DRIdri2LoaderExtension loader_extension;
>> - const __DRIextension *extensions[2];
>> + __DRIimageLookupExtension image_lookup_extension;
>> + const __DRIextension *extensions[3];
>> };
>>
>> struct dri2_egl_context
>> @@ -93,12 +95,24 @@ struct dri2_egl_surface
>>
>> struct dri2_egl_config
>> {
>> - _EGLConfig base;
>> + _EGLConfig base;
>> const __DRIconfig *dri_config;
>> };
>>
>> +struct dri2_egl_image
>> +{
>> + _EGLImage base;
>> + __DRIimage *dri_image;
>> + int width;
>> + int height;
>> + int name;
>> + int pitch;
>> + int cpp;
>> +};
>> +
>> /* standard typecasts */
>> _EGL_DRIVER_STANDARD_TYPECASTS(dri2_egl)
>> +_EGL_DRIVER_TYPECAST(dri2_egl_image, _EGLImage, obj)
>>
>> EGLint dri2_to_egl_attribute_map[] = {
>> 0,
>> @@ -346,6 +360,25 @@ dri2_flush_front_buffer(__DRIdrawable * driDrawable,
>> void *loaderPrivate)
>> #endif
>> }
>>
>> +static __DRIimage *
>> +dri2_lookup_image(__DRIcontext *context, void *image, void *data)
>> +{
>> + struct dri2_egl_context *dri2_ctx = data;
>> + _EGLDisplay *disp = dri2_ctx->base.Resource.Display;
>> + struct dri2_egl_image *dri2_img;
>> + _EGLImage *img;
>> +
>> + img = _eglLookupImage(image, disp);
>> + if (img == NULL) {
>> + _eglError(EGL_BAD_PARAMETER, "dri2_lookup_image");
>> + return NULL;
>> + }
>> +
>> + dri2_img = dri2_egl_image(image);
>> +
>> + return dri2_img->dri_image;
>> +}
>> +
>
> If this function can only be called by a driver, I don't think it should
> log error messages.
The image pointer comes straight from the API entry point and we
haven't been able to validate it until now. The purpose of the lookup
function is to do the validation that would normally happen at the API
entry point, log any errors and if everything is OK, return the driver
specific type (__DRIimage). This is the validation that you were
asking about in the other patch.
>> static __DRIbuffer *
>> dri2_get_buffers_with_format(__DRIdrawable * driDrawable,
>> int *width, int *height,
>> @@ -405,6 +438,7 @@ static struct dri2_extension_match
>> dri2_driver_extensions[] = {
>> static struct dri2_extension_match dri2_core_extensions[] = {
>> { __DRI2_FLUSH, 1, offsetof(struct dri2_egl_display, flush) },
>> { __DRI_TEX_BUFFER, 2, offsetof(struct dri2_egl_display, tex_buffer) },
>> + { __DRI_IMAGE, 1, offsetof(struct dri2_egl_display, image) },
>> { NULL }
>> };
>>
>> @@ -609,8 +643,13 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp,
>> dri2_dpy->loader_extension.getBuffersWithFormat = NULL;
>> }
>>
>> + dri2_dpy->image_lookup_extension.base.name = __DRI_IMAGE_LOOKUP;
>> + dri2_dpy->image_lookup_extension.base.version = 1;
>> + dri2_dpy->image_lookup_extension.lookupImage = dri2_lookup_image;
>> +
>> dri2_dpy->extensions[0] = &dri2_dpy->loader_extension.base;
>> - dri2_dpy->extensions[1] = NULL;
>> + dri2_dpy->extensions[1] = &dri2_dpy->image_lookup_extension.base;
>> + dri2_dpy->extensions[2] = NULL;
>>
>> dri2_dpy->dri_screen =
>> dri2_dpy->dri2->createNewScreen(0, dri2_dpy->fd, dri2_dpy->extensions,
>> @@ -1064,6 +1103,80 @@ dri2_release_
Re: [Mesa3d-dev] [PATCH 08/12] intel: Implement DRI image extension
2010/2/12 Ian Romanick :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Kristian Høgsberg wrote:
>> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
>> b/src/mesa/drivers/dri/intel/intel_screen.c
>> index f7ce87e..c2c8c6e 100644
>> --- a/src/mesa/drivers/dri/intel/intel_screen.c
>> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
>> @@ -41,6 +41,7 @@
>> #include "intel_fbo.h"
>> #include "intel_screen.h"
>> #include "intel_tex.h"
>> +#include "intel_regions.h"
>>
>> #include "i915_drm.h"
>>
>> @@ -141,11 +142,84 @@ static const struct __DRI2flushExtensionRec
>> intelFlushExtension = {
>> intelDRI2FlushInvalidate,
>> };
>>
>> +static __DRIimage *
>> +intel_create_image_internal(__DRIcontext *context,
>> + int width, int height, int internal_format,
>> + int name, int pitch, void *loaderPrivate)
>> +{
>> + __DRIimage *image;
>> + struct intel_context *intel = context->driverPrivate;
>> + int cpp;
>> +
>> + image = CALLOC(sizeof *image);
>> + image->internal_format = internal_format;
>> + switch (internal_format) {
>> + case GL_RGBA:
>> + image->format = MESA_FORMAT_ARGB;
>> + image->data_type = GL_UNSIGNED_BYTE;
>> + break;
>> + case GL_RGB:
>> + image->format = MESA_FORMAT_XRGB;
>> + image->data_type = GL_UNSIGNED_BYTE;
>> + break;
>> + }
>
> No love for 565 or pixmaps?
Good question. What is a sufficient way to specify the pixel format?
Internal format + datatype? That's what glTexImage2D uses and should
be enough to describe the type of content and layout of the color
components, for example GL_RGB8 + GL_UNSIGNED_INT_8_8_8_8.
Alternatively we can expose the MESA_FORMAT_* values as __DRI_FORMAT_*
tokens and use that in the __DRIimage extension. That would be
client-api independent, but GL tokens and types are already a
dependency in the DRI driver interface, so reusing the glTexImage2D
arguments wouldn't introduce new dependencies. The problem with this
approach is that it requires the caller to know too much about the
pixel layout. We don't actually know the pixel layout for a pixmap,
so the EGL doesn't know which layout to tell the DRI driver to use.
For DRI2 drawables, we assert that the DDX and DRI drivers agree on
the detail layout of the color components and we just need to
communicated the bits per pixel. Can we keep do that for EGLImages
too? Note, we don't need to provide enough information that clients
can map and access the pixels in the EGLImage. The various client
APIs already provide mechanisms and detail information on pixel layout
for that. We just need enough information to make sure that when we
pass buffers around, client APIs (OpenGL/OpenVG/etc) and external
users (DDX, cairo-drm, KMS) agree on the format. As such, GL_RGBA8,
for example, is enough, since the drivers will all pick the same
underlying layout.
So... I think just using the internalFormat values will be fine. The
semantics will be "pick the driver preferred layout for the provided
internalFormat". Does that sounds feasible?
Kristian
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 06/12] core: Implement GL_OES_EGL_image entry points
2010/2/12 Ian Romanick :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Kristian Høgsberg wrote:
>> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
>> index 0e6f69f..475aeab 100644
>> --- a/src/mesa/main/fbobject.c
>> +++ b/src/mesa/main/fbobject.c
>> @@ -1008,6 +1008,30 @@ renderbuffer_storage(GLenum target, GLenum
>> internalFormat,
>> */
>> }
>>
>> +#if FEATURE_OES_EGL_image
>> +void GLAPIENTRY
>> +_mesa_EGLImageTargetRenderbufferStorageOES (GLenum target, GLeglImageOES
>> image)
>> +{
>> + GET_CURRENT_CONTEXT(ctx);
>> + ASSERT_OUTSIDE_BEGIN_END(ctx);
>> + struct gl_renderbuffer *rb;
>> +
>> + if (target != GL_RENDERBUFFER_EXT) {
>
> New uses of these enums should use the undecorated versions.
That means GL_RENDERBUFFER, right?
>> + _mesa_error(ctx, GL_INVALID_ENUM,
>> "EGLImageTargetRenderbufferStorageOES");
>> + return;
>> + }
>> +
>> + rb = ctx->CurrentRenderbuffer;
>> + if (!rb) {
>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>> "EGLImageTargetRenderbufferStorageOES");
>> + return;
>> + }
>> +
>
> Is there any sort of generic validation of the image that could be done
> here? I suspect not, but I'd hate to see the same validation code
> duplicated in every driver. Maybe that would better belong in a utility
> function in src/mesa/drivers/dri/common. Hmm...
I know what you're saying, but there isn't. The EGLImage is an EGL
type and in our implementation it's a struct _egl_image, but we don't
know anything about that here. However, when the driver looks up the
EGLImage to get the __DRIimage, we do some basic validation in the
lookup function. When the driver finally gets the __DRIimage in hand,
there isn't a lot of checking to do; it's just a struct intel_region.
I don't worry that this will lead to a lot of code duplication.
>> + FLUSH_VERTICES(ctx, _NEW_BUFFERS);
>> +
>> + ctx->Driver.EGLImageTargetRenderbufferStorage(ctx, rb, image);
>> +}
>> +#endif
>>
>> /**
>> * Helper function for _mesa_GetRenderbufferParameterivEXT() and
>> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
>> index da3c6f9..6b15c40 100644
>> --- a/src/mesa/main/teximage.c
>> +++ b/src/mesa/main/teximage.c
>> @@ -2448,6 +2448,47 @@ _mesa_TexImage3DEXT( GLenum target, GLint level,
>> GLenum internalFormat,
>> }
>>
>>
>> +#if FEATURE_OES_EGL_image
>> +void GLAPIENTRY
>> +_mesa_EGLImageTargetTexture2DOES (GLenum target, GLeglImageOES image)
>> +{
>> + GET_CURRENT_CONTEXT(ctx);
>> + ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH(ctx);
>> + struct gl_texture_object *texObj;
>> + struct gl_texture_image *texImage;
>> +
>> + if (target != GL_TEXTURE_2D) {
>> + _mesa_error(ctx, GL_INVALID_ENUM, "glCompressedTexImage1D(target)");
>
> That's probably the wrong error message. :) Cut-and-paste for the lose.
Oops, fiedx.
>> + return;
>> + }
>> +
>> + if (ctx->NewState & _MESA_NEW_TRANSFER_STATE)
>> + _mesa_update_state(ctx);
>> +
>> + texObj = _mesa_get_current_tex_object(ctx, target);
>> + _mesa_lock_texture(ctx, texObj);
>> +
>> + texImage = _mesa_get_tex_image(ctx, texObj, target, 0);
>> + if (!texImage) {
>> + _mesa_error(ctx, GL_OUT_OF_MEMORY, "glTexImage2D");
>
> That's probably the wrong error message. :) Cut-and-paste for the lose.
Oops, fiedx.
>> + } else {
>> + if (texImage->Data)
>> + ctx->Driver.FreeTexImageData( ctx, texImage );
>> +
>> + ASSERT(texImage->Data == NULL);
>> + //clear_teximage_fields(texImage); /* not really needed, but helpful
>> */
>> + ctx->Driver.EGLImageTargetTexture2D(ctx, target,
>> + texObj, texImage, image);
>> +
>> + /* state update */
>> + texObj->_Complete = GL_FALSE;
>> + ctx->NewState |= _NEW_TEXTURE;
>> + }
>> + _mesa_unlock_texture(ctx, texObj);
>> +
>> +}
>> +#endif
>> +
>>
>> void GLAPIENTRY
>> _mesa_TexSubImage1D( GLenum target, GLint level,
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkt191oACgkQX1gOwKyEAw9VdgCePyOrp2dqrYdU3l8Dgh+7/5YE
> mu4Amwd/D9vDVG+jEIoPt5EYRTPqgEXi
> =Hq4M
> -END PGP SIGNATURE-
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 02/12] intel: Track named regions and make sure we only have one region per named bo
2010/2/12 Ian Romanick : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Kristian Høgsberg wrote: > > It's not obvious why this is necessary. Is it to prevent multiple calls > to eglCreateImage from creating multiple regions for the same bo? Some > explanation in intel_region_alloc_for_handle would be helpful to people > like me that aren't as familiar with some of the inner workings. :) The problem that this fixes is the case where you create an EGLSurface and en EGLImage for a pixmap. In the first case, we end up creating a region for the gem handle through the intel_update_renderbuffers() path and in the second case the new intel_create_image_from_name() path. That will create different struct intel_regions for the same buffer, each with different drm_intel_bo's with different gem handles. That means that libdrm_intel can't properly track cache transitions for the buffer, since they will be associated with different drm_intel_bo's but it's the same underlying gem buffer. Also gem will either oops or return EINVAL (depending on how new your kernel is) if the same buffer appears several times with different handles in the execbuffer request. > Other than that and the trivial comment below, this looks good to me. > >> Signed-off-by: Kristian Høgsberg > > Reviewed-by: Ian Romanick > >> --- >> src/mesa/drivers/dri/intel/intel_regions.c | 24 +++- >> src/mesa/drivers/dri/intel/intel_regions.h | 3 +++ >> src/mesa/drivers/dri/intel/intel_screen.c | 14 ++ >> src/mesa/drivers/dri/intel/intel_screen.h | 1 + >> 4 files changed, 41 insertions(+), 1 deletions(-) >> >> diff --git a/src/mesa/drivers/dri/intel/intel_regions.c >> b/src/mesa/drivers/dri/intel/intel_regions.c >> index e2859e4..881653f 100644 >> --- a/src/mesa/drivers/dri/intel/intel_regions.c >> +++ b/src/mesa/drivers/dri/intel/intel_regions.c >> @@ -42,6 +42,7 @@ >> #include >> #include >> >> +#include > > You use "main/hash.h" intel_screen.c, and you should probably use the > same here. Yup, fixed. >> #include "intel_context.h" >> #include "intel_regions.h" >> #include "intel_blit.h" > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkt19xUACgkQX1gOwKyEAw93qACcCi2elsVlbMnzdpXJNxCMPHil > kGsAniguIshImur+LY2oQ0CY/snS3nIE > =0NG8 > -END PGP SIGNATURE- > thanks, Kristian -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 00/12] EGLImage patches
2010/2/12 Ian Romanick : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Kristian Høgsberg wrote: >> Hello, >> >> Here's a patch series to implement a handful of EGLImage extensions in >> the DRI2 EGL driver: >> >> EGL_KHR_image_base >> EGL_KHR_image_pixmap >> GL_OES_EGL_image >> >> The implementation is a little tricky, since the EGLImage is an EGL >> (binding layer) type, but it's passed to client API functions such as >> >> void glEGLImageTargetTexture2DOES (GLenum target, >> GLeglImageOES image); >> void glEGLImageTargetRenderbufferStorageOES (GLenum target, >> GLeglImageOES image); >> >> The image argument is an EGLImage and the binding agnostic GL >> implementation can't do anything with it. So what I've done is to >> pass the image argument all the way into the backend driver, which is >> then expected to have some interface provided from the loader to map >> the opaque EGLImage to a type the driver understands. >> >> In the DRI case, I make this work with two new DRI extensions: DRI >> image and DRI imageLookup. The DRI image extensions is implemented by >> the driver and the loader (that is, src/egl/drivers/dri2) uses it to >> create a __DRIimage from the GEM/TTM handle for a pixmap, or possibly >> some other source. This is how EGL_KHR_image_pixmap is done. The DRI >> imageLookup extension is implemented by the loader and passed to the >> DRI driver at initialization time. The driver uses this extension to >> map the opaque EGLImage handles back to a __DRIimage struct. > > is this mechanism extensible to support creating EGLImages *from* GL > textures? It seems like it should in principle. I can see some utility > in implementing EGL_KHR_gl_texture_2D_image and friends. This would > probably be useful to glamor, for example. Yes, the plan is to add more entry points to the __DRIimage extension, along the lines of createImageForRenderbuffer, createImageForTexture2D etc. I want to do that before pushing the patches, but I wanted to get what I had now out to get some feedback. >> With this in place, I have implemented GL_OES_EGL_image. I added the >> glapi specification for it and I've added it as a GL extension as >> well. This is mostly boilerplate extension work, and it adds >> dd_function_table hooks for the driver to implement. There still some >> details I need to figure out here, for example, the extensions don't >> show up in the EGL extension string. >> >> Looking though the EGL_KHR_image_pixmap and GL_OES_EGL_image >> extensions, there seems to be no way to specify the format of the > > I think the intention is that it just uses the format of the pixmap. If > the pixmap is RGB, the image will be RGB. If the pixmap is RGBA, the > image will be RGBA. The ability to ignore the alpha component of RGBA > pixmaps is indeed missing. Well, the pixmap doesn't have a "format". A window has a visual we can look at, but a pixmap only has depth. As I wrote to Chia-I, I'll do that and infer the format (RGB or RGBA) based on whether the depth of the pixmap, and drop the extension for now. There's still the possibility that somebody will want to bind a depth 32 pixmap as an RGB texture, which won't be possible without this extension. Whether or not that's useful, I'm not sure, but it's worth noting that the EGLBindTexImage() function allows a similar thing. You can pass an attribute/value pair to specify the texture format, so that a pbuffer EGLSurface with EGL_ALPHA_SIZE == 8 can still be bound with a texture format of RGB. Maybe it's something you can bring up with Khronos? >> pixmap. With GLX_EXT_texture_from_pixmap, we can specifiy the format >> as either RGB or RGBA through the attribute list passed to >> glXBindTexImageEXT(). In the EGLImage model, there's no way to >> specify this, so I've proposed an extension in patch 11: >> EGL_KHR_image_pixmap_format. This adds an eglCreateImageKHR > > Don't call it that. "KHR" is kind of like "ARB". It means that it was > voted on and approved by Khronos. Maybe call it > EGL_MESA_image_pixmap_format. Well I called it that because I'd like somebody (hint hint :) to propose it to Khronos and get it approved that way. Don't worry, I wont commit it with that name. > >> attribute, EGL_NATIVE_PIXMAP_FORMAT_KHR that takes two values: >> >> EGL_NATIVE_PIXMAP_RGB_KHR >> EGL_NATIVE_PIXMAP_RGBA_KHR >> >> Pretty straightforward. >> >&
Re: [Mesa3d-dev] [PATCH 02/12] intel: Track named regions and make sure we only have one region per named bo
On Fri, Feb 12, 2010 at 4:05 PM, Eric Anholt wrote: > On Thu, 11 Feb 2010 20:48:01 -0500, Kristian Høgsberg > wrote: >> Eric, I was hoping you could have a look at this one in particular. > > Looks OK to me. I guess the DeleteAll is in case there was something > that's (accidentally) still referenced at screen close time? Yes, if the application doesn't destroy its EGLSurfaces or EGLImages, there will still be live struct intel_regions at the time we shut down the struct intel_screen. By the way, the reason for introducing this hash is the case where you have, for example, a pixmap EGLSurface and an EGLImage for the same pixmap, we end up using different GEM handles for the buffer. thanks, Kristian -- 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 00/12] EGLImage patches
2010/2/11 Chia-I Wu : > Great work! > > 2010/2/12 Kristian Høgsberg : >> Here's a patch series to implement a handful of EGLImage extensions in >> the DRI2 EGL driver: >> EGL_KHR_image_base >> EGL_KHR_image_pixmap >> GL_OES_EGL_image >> The implementation is a little tricky, since the EGLImage is an EGL >> (binding layer) type, but it's passed to client API functions such as >> void glEGLImageTargetTexture2DOES (GLenum target, >> GLeglImageOES image); >> void glEGLImageTargetRenderbufferStorageOES (GLenum target, >> GLeglImageOES image); >> The image argument is an EGLImage and the binding agnostic GL >> implementation can't do anything with it. So what I've done is to >> pass the image argument all the way into the backend driver, which is >> then expected to have some interface provided from the loader to map >> the opaque EGLImage to a type the driver understands. >> In the DRI case, I make this work with two new DRI extensions: DRI >> image and DRI imageLookup. The DRI image extensions is implemented by >> the driver and the loader (that is, src/egl/drivers/dri2) uses it to >> create a __DRIimage from the GEM/TTM handle for a pixmap, or possibly >> some other source. This is how EGL_KHR_image_pixmap is done. The DRI >> imageLookup extension is implemented by the loader and passed to the >> DRI driver at initialization time. The driver uses this extension to >> map the opaque EGLImage handles back to a __DRIimage struct. > Yeah, there is no other way around for this. st/egl will use lock_resource > and > unlock_resource in st_api for the same purpose, FWIW. I totally back this > approach. Good to hear. This was one of the more tricky things to piece together in this series. I'm pretty happy with how it worked out with the two DRI extensions, but this was something I was hoping to get a second opinion on. >> With this in place, I have implemented GL_OES_EGL_image. I added the >> glapi specification for it and I've added it as a GL extension as >> well. This is mostly boilerplate extension work, and it adds >> dd_function_table hooks for the driver to implement. There still some >> details I need to figure out here, for example, the extensions don't >> show up in the EGL extension string. > How come the GL extension needs to show up in EGL extension string? True, GL_OES_EGL_image should show up in the GL or GLES extension strings, but the EGL_KHR_image etc extensions should show up in the EGL extension string. I don't expect it's a big deal, I just need to enable the extensions somewhere. >> Looking though the EGL_KHR_image_pixmap and GL_OES_EGL_image >> extensions, there seems to be no way to specify the format of the >> pixmap. With GLX_EXT_texture_from_pixmap, we can specifiy the format >> as either RGB or RGBA through the attribute list passed to >> glXBindTexImageEXT(). In the EGLImage model, there's no way to >> specify this, so I've proposed an extension in patch 11: >> EGL_KHR_image_pixmap_format. This adds an eglCreateImageKHR >> attribute, EGL_NATIVE_PIXMAP_FORMAT_KHR that takes two values: >> EGL_NATIVE_PIXMAP_RGB_KHR >> EGL_NATIVE_PIXMAP_RGBA_KHR >> Pretty straightforward. > I don't quite understand this extension. egl_dri2 should be able to figure > out > the format of the pixmap (not entirely true with X pixmaps, but no entity has > better knowledge than egl_dri2 does). Or is it to specify the desired > internal > format of the pixmap when bound to a texture object? To bind an RGBA pixmap > as > an RGB texture? It's to know whether to bind it as RGB or RGBA when using the EGLImage as a texture. We can get the pixmap depth and make an educated guess; 15,16 or 24 -> RGB, 32 -> RGBA, and I think that should work. On the other hand eglBindTexImage() lets you specify whether to bind the pbuffer surface as RGB or RGBA by specifying the texture format using the EGL_TEXTURE_FORMAT create surface attribute. That way you can bind an RGBA pbuffer as an RGB texture. Also, we added a glXBindTexImage attribute to do the exact same thing, but I'm not sure why that was necessary... >> Finally I added a few new options to xeglgears: -pbuffer-texture, >> which renders to an EGL pbuffer surface and textures using >> eglBindTexImage() and -pixmap-texture, which renders to a EGL pixmap >> surface and textures from that by creating an EGLImage from the >> underlying X pixmap and binding that using GL_OES_EGL_image. >> >> Let me know what you think, > I only had a qui
Re: [Mesa3d-dev] [PATCH 00/12] EGLImage patches
2010/2/11 Kristian Høgsberg : > Hello, > > Here's a patch series to implement a handful of EGLImage extensions in > the DRI2 EGL driver: Oh, and obviously the path with the updated generated files is stuck in moderation, but there's not much to see there anyway. But just for reference, the series is available here: http://cgit.freedesktop.org/~krh/mesa/log/?h=eglimage cheers, Kristian -- 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 02/12] intel: Track named regions and make sure we only have one region per named bo
Eric, I was hoping you could have a look at this one in particular.
thanks,
Kristian
2010/2/11 Kristian Høgsberg :
>
> Signed-off-by: Kristian Høgsberg
> ---
> src/mesa/drivers/dri/intel/intel_regions.c | 24 +++-
> src/mesa/drivers/dri/intel/intel_regions.h | 3 +++
> src/mesa/drivers/dri/intel/intel_screen.c | 14 ++
> src/mesa/drivers/dri/intel/intel_screen.h | 1 +
> 4 files changed, 41 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_regions.c
> b/src/mesa/drivers/dri/intel/intel_regions.c
> index e2859e4..881653f 100644
> --- a/src/mesa/drivers/dri/intel/intel_regions.c
> +++ b/src/mesa/drivers/dri/intel/intel_regions.c
> @@ -42,6 +42,7 @@
> #include
> #include
>
> +#include
> #include "intel_context.h"
> #include "intel_regions.h"
> #include "intel_blit.h"
> @@ -228,10 +229,24 @@ intel_region_alloc_for_handle(struct intel_context
> *intel,
> GLuint width, GLuint height, GLuint pitch,
> GLuint handle, const char *name)
> {
> - struct intel_region *region;
> + struct intel_region *region, *dummy;
> dri_bo *buffer;
> int ret;
>
> + region = _mesa_HashLookup(intel->intelScreen->named_regions, handle);
> + if (region != NULL) {
> + dummy = NULL;
> + if (region->width != width || region->height != height ||
> + region->cpp != cpp || region->pitch != pitch) {
> + fprintf(stderr,
> + "Region for name %d already exists but is not compatible\n",
> + handle);
> + return NULL;
> + }
> + intel_region_reference(&dummy, region);
> + return dummy;
> + }
> +
> buffer = intel_bo_gem_create_from_name(intel->bufmgr, name, handle);
>
> region = intel_region_alloc_internal(intel, cpp,
> @@ -248,6 +263,10 @@ intel_region_alloc_for_handle(struct intel_context
> *intel,
> return NULL;
> }
>
> + region->name = handle;
> + region->screen = intel->intelScreen;
> + _mesa_HashInsert(intel->intelScreen->named_regions, handle, region);
> +
> return region;
> }
>
> @@ -287,6 +306,9 @@ intel_region_release(struct intel_region **region_handle)
> region->pbo = NULL;
> dri_bo_unreference(region->buffer);
>
> + if (region->name > 0)
> + _mesa_HashRemove(region->screen->named_regions, region->name);
> +
> free(region);
> }
> *region_handle = NULL;
> diff --git a/src/mesa/drivers/dri/intel/intel_regions.h
> b/src/mesa/drivers/dri/intel/intel_regions.h
> index 860ae11..6d36f3d 100644
> --- a/src/mesa/drivers/dri/intel/intel_regions.h
> +++ b/src/mesa/drivers/dri/intel/intel_regions.h
> @@ -67,6 +67,9 @@ struct intel_region
> uint32_t tiling; /**< Which tiling mode the region is in */
> uint32_t bit_6_swizzle; /**< GEM flag for address swizzling requirement */
> struct intel_buffer_object *pbo; /* zero-copy uploads */
> +
> + uint32_t name; /**< Global name for the bo */
> + struct intel_screen *screen;
> };
>
>
> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
> b/src/mesa/drivers/dri/intel/intel_screen.c
> index 6dc20d0..f7ce87e 100644
> --- a/src/mesa/drivers/dri/intel/intel_screen.c
> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
> @@ -29,6 +29,7 @@
> #include "main/context.h"
> #include "main/framebuffer.h"
> #include "main/renderbuffer.h"
> +#include "main/hash.h"
>
> #include "utils.h"
> #include "xmlpool.h"
> @@ -167,6 +168,11 @@ intel_get_param(__DRIscreen *psp, int param, int *value)
> }
>
> static void
> +nop_callback(GLuint key, void *data, void *userData)
> +{
> +}
> +
> +static void
> intelDestroyScreen(__DRIscreen * sPriv)
> {
> struct intel_screen *intelScreen = sPriv->private;
> @@ -174,6 +180,12 @@ intelDestroyScreen(__DRIscreen * sPriv)
> dri_bufmgr_destroy(intelScreen->bufmgr);
> driDestroyOptionInfo(&intelScreen->optionCache);
>
> + /* Some regions may still have references to them at this point, so
> + * flush the hash table to prevent _mesa_DeleteHashTable() from
> + * complaining about the hash not being empty; */
> + _mesa_HashDeleteAll(intelScreen->named_regions, nop_callback, NULL);
> + _mesa_DeleteHashTable(intelScreen->named_regions);
> +
> FREE(intelScreen);
> sPriv->private = NULL;
> }
> @@ -324,6 +336,8 @@ intel_init_bufmgr(struct intel_screen *intelScreen)
> else
> intel
[Mesa3d-dev] [PATCH 10/12] egl_dri2: Implement EGL_KHR_image and EGL_KHR_image_pixmap
Signed-off-by: Kristian Høgsberg
---
src/egl/drivers/dri2/egl_dri2.c | 123 +-
1 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 5d36c49..1590190 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -42,7 +42,6 @@
#include
#include
-#include "eglconfigutil.h"
#include "eglconfig.h"
#include "eglcontext.h"
#include "egldisplay.h"
@@ -50,6 +49,7 @@
#include "eglcurrent.h"
#include "egllog.h"
#include "eglsurface.h"
+#include "eglimage.h"
struct dri2_egl_driver
{
@@ -67,10 +67,12 @@ struct dri2_egl_display
__DRIdri2Extension *dri2;
__DRI2flushExtension *flush;
__DRItexBufferExtension *tex_buffer;
+ __DRIimageExtension *image;
int fd;
__DRIdri2LoaderExtension loader_extension;
- const __DRIextension *extensions[2];
+ __DRIimageLookupExtension image_lookup_extension;
+ const __DRIextension *extensions[3];
};
struct dri2_egl_context
@@ -93,12 +95,24 @@ struct dri2_egl_surface
struct dri2_egl_config
{
- _EGLConfig base;
+ _EGLConfig base;
const __DRIconfig *dri_config;
};
+struct dri2_egl_image
+{
+ _EGLImage base;
+ __DRIimage *dri_image;
+ int width;
+ int height;
+ int name;
+ int pitch;
+ int cpp;
+};
+
/* standard typecasts */
_EGL_DRIVER_STANDARD_TYPECASTS(dri2_egl)
+_EGL_DRIVER_TYPECAST(dri2_egl_image, _EGLImage, obj)
EGLint dri2_to_egl_attribute_map[] = {
0,
@@ -346,6 +360,25 @@ dri2_flush_front_buffer(__DRIdrawable * driDrawable, void
*loaderPrivate)
#endif
}
+static __DRIimage *
+dri2_lookup_image(__DRIcontext *context, void *image, void *data)
+{
+ struct dri2_egl_context *dri2_ctx = data;
+ _EGLDisplay *disp = dri2_ctx->base.Resource.Display;
+ struct dri2_egl_image *dri2_img;
+ _EGLImage *img;
+
+ img = _eglLookupImage(image, disp);
+ if (img == NULL) {
+ _eglError(EGL_BAD_PARAMETER, "dri2_lookup_image");
+ return NULL;
+ }
+
+ dri2_img = dri2_egl_image(image);
+
+ return dri2_img->dri_image;
+}
+
static __DRIbuffer *
dri2_get_buffers_with_format(__DRIdrawable * driDrawable,
int *width, int *height,
@@ -405,6 +438,7 @@ static struct dri2_extension_match dri2_driver_extensions[]
= {
static struct dri2_extension_match dri2_core_extensions[] = {
{ __DRI2_FLUSH, 1, offsetof(struct dri2_egl_display, flush) },
{ __DRI_TEX_BUFFER, 2, offsetof(struct dri2_egl_display, tex_buffer) },
+ { __DRI_IMAGE, 1, offsetof(struct dri2_egl_display, image) },
{ NULL }
};
@@ -609,8 +643,13 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp,
dri2_dpy->loader_extension.getBuffersWithFormat = NULL;
}
+ dri2_dpy->image_lookup_extension.base.name = __DRI_IMAGE_LOOKUP;
+ dri2_dpy->image_lookup_extension.base.version = 1;
+ dri2_dpy->image_lookup_extension.lookupImage = dri2_lookup_image;
+
dri2_dpy->extensions[0] = &dri2_dpy->loader_extension.base;
- dri2_dpy->extensions[1] = NULL;
+ dri2_dpy->extensions[1] = &dri2_dpy->image_lookup_extension.base;
+ dri2_dpy->extensions[2] = NULL;
dri2_dpy->dri_screen =
dri2_dpy->dri2->createNewScreen(0, dri2_dpy->fd, dri2_dpy->extensions,
@@ -1064,6 +1103,80 @@ dri2_release_tex_image(_EGLDriver *drv,
return EGL_TRUE;
}
+static _EGLImage *
+dri2_create_image_khr(_EGLDriver *drv, _EGLDisplay *disp,
+ _EGLContext *ctx, EGLenum target,
+ EGLClientBuffer buffer, const EGLint *attr_list)
+{
+ struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+ struct dri2_egl_context *dri2_ctx = dri2_egl_context(ctx);
+ struct dri2_egl_image *dri2_img;
+ unsigned int attachments[1];
+ xcb_drawable_t drawable;
+ xcb_dri2_get_buffers_cookie_t cookie;
+ xcb_dri2_dri2_buffer_t *buffers;
+ xcb_dri2_get_buffers_reply_t *reply;
+
+ dri2_img = malloc(sizeof *dri2_img);
+ if (!dri2_img) {
+ _eglError(EGL_BAD_ALLOC, "dri2_create_image_khr");
+ return EGL_NO_IMAGE_KHR;
+ }
+
+ if (!_eglInitImage(&dri2_img->base, disp, attr_list))
+ return EGL_NO_IMAGE_KHR;
+
+ switch (target) {
+ case EGL_NATIVE_PIXMAP_KHR:
+ drawable = (xcb_drawable_t) buffer;
+ xcb_dri2_create_drawable (dri2_dpy->conn, drawable);
+ attachments[0] = XCB_DRI2_ATTACHMENT_BUFFER_FRONT_LEFT;
+ cookie = xcb_dri2_get_buffers_unchecked (dri2_dpy->conn,
+ drawable, 1, 1, attachments);
+ reply = xcb_dri2_get_buffers_reply (dri2_dpy->conn, cookie, NULL);
+ buffers = xcb_dri2_get_buffers_buffers (reply);
+ if (buffers == NULL) {
+free(dri2_
[Mesa3d-dev] [PATCH 03/12] intel: Avoid dri_bo_flink() in intel_update_renderbuffers()
Now that we track the global name in struct intel_region, we can just
look it up there.
Signed-off-by: Kristian Høgsberg
---
src/mesa/drivers/dri/intel/intel_context.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index e9315a5..f62f75c 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -324,11 +324,8 @@ intel_update_renderbuffers(__DRIcontext *context,
__DRIdrawable *drawable)
if (rb == NULL)
continue;
- if (rb->region) {
- dri_bo_flink(rb->region->buffer, &name);
- if (name == buffers[i].name)
+ if (rb->region && rb->region->name == buffers[i].name)
continue;
- }
if (INTEL_DEBUG & DEBUG_DRI)
fprintf(stderr,
@@ -360,11 +357,8 @@ intel_update_renderbuffers(__DRIcontext *context,
__DRIdrawable *drawable)
if (rb != NULL) {
struct intel_region *stencil_region = NULL;
-if (rb->region) {
- dri_bo_flink(rb->region->buffer, &name);
- if (name == buffers[i].name)
+if (rb->region && rb->region->name == buffers[i].name)
continue;
-}
intel_region_reference(&stencil_region, region);
intel_renderbuffer_set_region(rb, stencil_region);
--
1.6.5.rc2
--
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
[Mesa3d-dev] [PATCH 11/12] egl: Add proposed EGL_KHR_image_pixmap_format extension
This is a proposed extension to let EGL clients specify the format
of the pixmap that is used as a source for an EGLImage. This is
necessary when later using the EGLImage as a texture source, for example.
Signed-off-by: Kristian Høgsberg
---
include/EGL/eglext.h|8
src/egl/drivers/dri2/egl_dri2.c | 12 +++-
src/egl/main/eglimage.c | 10 ++
src/egl/main/eglimage.h |1 +
4 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
index a9e598d..c59fe7f 100644
--- a/include/EGL/eglext.h
+++ b/include/EGL/eglext.h
@@ -219,6 +219,14 @@ typedef EGLBoolean (EGLAPIENTRYP PFNEGLCOPYCONTEXTMESA)
(EGLDisplay dpy, EGLCont
/* Interfaces defined by EGL_KHR_image above */
#endif
+#ifndef EGL_KHR_image_pixmap_format
+#define EGL_KHR_image_pixmap_format 1
+/* Interfaces defined by EGL_KHR_image above */
+#define EGL_NATIVE_PIXMAP_FORMAT_KHR 0x30D3 /* eglCreateImageKHR
attribute */
+#define EGL_NATIVE_PIXMAP_RGB_KHR 0x30D4 /* eglCreateImageKHR
value */
+#define EGL_NATIVE_PIXMAP_RGBA_KHR 0x30D5 /* eglCreateImageKHR
value */
+#endif
+
#ifndef EGL_IMG_context_priority
#define EGL_IMG_context_priority 1
#define EGL_CONTEXT_PRIORITY_LEVEL_IMG 0x3100
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 1590190..a199531 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1116,6 +1116,7 @@ dri2_create_image_khr(_EGLDriver *drv, _EGLDisplay *disp,
xcb_dri2_get_buffers_cookie_t cookie;
xcb_dri2_dri2_buffer_t *buffers;
xcb_dri2_get_buffers_reply_t *reply;
+ int format;
dri2_img = malloc(sizeof *dri2_img);
if (!dri2_img) {
@@ -1154,11 +1155,20 @@ dri2_create_image_khr(_EGLDriver *drv, _EGLDisplay
*disp,
return EGL_NO_IMAGE_KHR;
}
+ switch (dri2_img->base.NativePixmapFormat) {
+ case EGL_NATIVE_PIXMAP_RGB_KHR:
+ format = GL_RGB;
+ break;
+ case EGL_NATIVE_PIXMAP_RGBA_KHR:
+ format = GL_RGBA;
+ break;
+ }
+
dri2_img->dri_image =
dri2_dpy->image->createImageFromName(dri2_ctx->dri_context,
dri2_img->width,
dri2_img->height,
- GL_RGBA,
+ format,
dri2_img->name,
dri2_img->pitch,
dri2_img);
diff --git a/src/egl/main/eglimage.c b/src/egl/main/eglimage.c
index 5732ef3..013057d 100644
--- a/src/egl/main/eglimage.c
+++ b/src/egl/main/eglimage.c
@@ -34,6 +34,15 @@ _eglParseImageAttribList(_EGLImage *img, const EGLint
*attrib_list)
case EGL_GL_TEXTURE_ZOFFSET_KHR:
img->GLTextureZOffset = val;
break;
+ case EGL_NATIVE_PIXMAP_FORMAT_KHR:
+if (val == EGL_NATIVE_PIXMAP_RGB_KHR ||
+val == EGL_NATIVE_PIXMAP_RGBA_KHR) {
+ img->NativePixmapFormat = val;
+} else {
+err = EGL_BAD_ATTRIBUTE;
+break;
+}
+ break;
default:
/* unknown attrs are ignored */
break;
@@ -60,6 +69,7 @@ _eglInitImage(_EGLImage *img, _EGLDisplay *dpy, const EGLint
*attrib_list)
img->Preserved = EGL_FALSE;
img->GLTextureLevel = 0;
img->GLTextureZOffset = 0;
+ img->NativePixmapFormat = EGL_NATIVE_PIXMAP_RGB_KHR;
err = _eglParseImageAttribList(img, attrib_list);
if (err != EGL_SUCCESS)
diff --git a/src/egl/main/eglimage.h b/src/egl/main/eglimage.h
index 2c0fb16..fa0a1f6 100644
--- a/src/egl/main/eglimage.h
+++ b/src/egl/main/eglimage.h
@@ -17,6 +17,7 @@ struct _egl_image
EGLBoolean Preserved;
EGLint GLTextureLevel;
EGLint GLTextureZOffset;
+ EGLint NativePixmapFormat;
};
--
1.6.5.rc2
--
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
[Mesa3d-dev] [PATCH 01/12] dri: Store the loader private passed in at dri context creation
We just threw it away before, but we haven't had a use for it yet.
Signed-off-by: Kristian Høgsberg
---
src/mesa/drivers/dri/common/dri_util.c |3 ++-
src/mesa/drivers/dri/common/dri_util.h |5 +
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index 3649c29..f5e7923 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -581,7 +581,8 @@ driCreateNewContext(__DRIscreen *psp, const __DRIconfig
*config,
pcp->driScreenPriv = psp;
pcp->driDrawablePriv = NULL;
-
+pcp->loaderPrivate = data;
+
/* When the first context is created for a screen, initialize a "dummy"
* context.
*/
diff --git a/src/mesa/drivers/dri/common/dri_util.h
b/src/mesa/drivers/dri/common/dri_util.h
index 95df702..e9d5a9d 100644
--- a/src/mesa/drivers/dri/common/dri_util.h
+++ b/src/mesa/drivers/dri/common/dri_util.h
@@ -413,6 +413,11 @@ struct __DRIcontextRec {
* Pointer to screen on which this context was created.
*/
__DRIscreen *driScreenPriv;
+
+/**
+ * The loaders's private context data. This structure is opaque.
+ */
+void *loaderPrivate;
};
/**
--
1.6.5.rc2
--
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
[Mesa3d-dev] [PATCH 12/12] xeglgears: Add test case for texturing from an EGLImage
Signed-off-by: Kristian Høgsberg
---
progs/egl/xeglgears.c | 95 +
1 files changed, 72 insertions(+), 23 deletions(-)
diff --git a/progs/egl/xeglgears.c b/progs/egl/xeglgears.c
index efb63ef..342d509 100644
--- a/progs/egl/xeglgears.c
+++ b/progs/egl/xeglgears.c
@@ -42,6 +42,9 @@
#include
#include
+#define EGL_EGLEXT_PROTOTYPES
+#include
+
#define BENCHMARK
@@ -335,6 +338,7 @@ struct egl_manager {
EGLSurface win;
EGLSurface pix;
EGLSurface pbuf;
+ EGLImageKHR image;
EGLBoolean verbose;
EGLint major, minor;
@@ -528,17 +532,26 @@ egl_manager_destroy(struct egl_manager *eman)
free(eman);
}
-enum { GEARS_WINDOW, GEARS_PIXMAP, GEARS_PBUFFER_COPY, GEARS_PBUFFER_TEXTURE };
+enum {
+ GEARS_WINDOW,
+ GEARS_PIXMAP,
+ GEARS_PIXMAP_TEXTURE,
+ GEARS_PBUFFER,
+ GEARS_PBUFFER_TEXTURE
+};
+
+typedef void* GLeglImageOES;
+GLAPI void GLAPIENTRY glEGLImageTargetTexture2DOES (GLenum target,
GLeglImageOES image);
+GLAPI void GLAPIENTRY glEGLImageTargetRenderbufferStorageOES (GLenum target,
GLeglImageOES image);
static void
-texture_gears(struct egl_manager *eman)
+texture_gears(struct egl_manager *eman, int surface_type)
{
static const GLint verts[12] =
{ -5, -6, -10, 5, -6, -10, -5, 4, 10, 5, 4, 10 };
static const GLint tex_coords[8] = { 0, 0, 1, 0, 0, 1, 1, 1 };
- static const GLuint indices[4] = { 0, 1, 2, 3 };
- eglMakeCurrent(eman->dpy, eman->pix, eman->pix, eman->ctx);
+ eglMakeCurrent(eman->dpy, eman->win, eman->win, eman->ctx);
glClearColor(0, 0, 0, 0);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
@@ -554,15 +567,19 @@ texture_gears(struct egl_manager *eman)
glVertexPointer(3, GL_INT, 0, verts);
glTexCoordPointer(2, GL_INT, 0, tex_coords);
- eglBindTexImage(eman->dpy, eman->pbuf, EGL_BACK_BUFFER);
+ if (surface_type == GEARS_PBUFFER_TEXTURE)
+ eglBindTexImage(eman->dpy, eman->pbuf, EGL_BACK_BUFFER);
- glDrawElements(GL_TRIANGLE_STRIP, 4, GL_UNSIGNED_INT, indices);
+ glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
glDisableClientState(GL_VERTEX_ARRAY);
glDisableClientState(GL_COLOR_ARRAY);
glDisable(GL_TEXTURE_2D);
- eglReleaseTexImage(eman->dpy, eman->pbuf, EGL_BACK_BUFFER);
+ if (surface_type == GEARS_PBUFFER_TEXTURE)
+ eglReleaseTexImage(eman->dpy, eman->pbuf, EGL_BACK_BUFFER);
+
+ eglSwapBuffers(eman->dpy, eman->win);
}
static void
@@ -633,8 +650,17 @@ event_loop(struct egl_manager *eman, EGLint surface_type,
EGLint w, EGLint h)
if (angle > 3600.0)
angle -= 3600.0;
-if (surface_type == GEARS_PBUFFER_TEXTURE)
+ switch (surface_type) {
+case GEARS_PBUFFER:
+case GEARS_PBUFFER_TEXTURE:
eglMakeCurrent(eman->dpy, eman->pbuf, eman->pbuf, eman->ctx);
+ break;
+
+case GEARS_PIXMAP:
+case GEARS_PIXMAP_TEXTURE:
+eglMakeCurrent(eman->dpy, eman->pix, eman->pix, eman->ctx);
+ break;
+}
draw();
switch (surface_type) {
@@ -642,13 +668,12 @@ event_loop(struct egl_manager *eman, EGLint surface_type,
EGLint w, EGLint h)
eglSwapBuffers(eman->dpy, eman->win);
break;
case GEARS_PBUFFER_TEXTURE:
- case GEARS_PBUFFER_COPY:
- if (surface_type == GEARS_PBUFFER_TEXTURE) {
- texture_gears(eman);
- } else {
- if (!eglCopyBuffers(eman->dpy, eman->pbuf, eman->xpix))
- break;
- }
+case GEARS_PIXMAP_TEXTURE:
+ texture_gears(eman, surface_type);
+ break;
+ case GEARS_PBUFFER:
+ if (!eglCopyBuffers(eman->dpy, eman->pbuf, eman->xpix))
+ break;
eglWaitClient();
/* fall through */
case GEARS_PIXMAP:
@@ -693,6 +718,9 @@ usage(void)
printf(" -pbuffer-textureuse pbuffer surface and
eglBindTexImage\n");
}
+static const char *names[] = {
+ "window", "pixmap", "pixmap_texture", "pbuffer", "pbuffer_texture"
+};
int
main(int argc, char *argv[])
@@ -715,6 +743,7 @@ main(int argc, char *argv[])
GLboolean printInfo = GL_FALSE;
GLboolean fullscreen = GL_FALSE;
EGLBoolean ret;
+ GLuint texture;
int i;
for (i = 1; i < argc; i++) {
@@ -732,8 +761,12 @@ main(int argc, char *argv[])
surface_type = GEARS_PIXMAP;
attribs[1] = EGL_PIXMAP_BIT;
}
- else if (strcmp(argv[i], "-pbuffer-copy") == 0) {
- surface_type = GEARS_PBUFFER_COPY;
+ else if (strcmp(argv[i], "-pixmap-texture") == 0) {
+ surface_type = GEARS_PIXMAP_TEXTURE;
+attribs[1] = EGL_PIXMAP_BIT;
+ }
+ else if (strcmp(argv[i], "-pbuffer") ==
[Mesa3d-dev] [PATCH 04/12] glapi: Add GL_OES_EGL_image
Signed-off-by: Kristian Høgsberg --- src/mesa/glapi/Makefile |5 - src/mesa/glapi/OES_EGL_image.xml | 20 src/mesa/glapi/gl_API.xml|2 ++ 3 files changed, 26 insertions(+), 1 deletions(-) create mode 100644 src/mesa/glapi/OES_EGL_image.xml diff --git a/src/mesa/glapi/Makefile b/src/mesa/glapi/Makefile index da67960..3f5103b 100644 --- a/src/mesa/glapi/Makefile +++ b/src/mesa/glapi/Makefile @@ -61,13 +61,16 @@ API_XML = gl_API.xml \ EXT_packed_depth_stencil.xml \ EXT_provoking_vertex.xml \ EXT_texture_array.xml \ - NV_conditional_render.xml + NV_conditional_render.xml \ + OES_EGL_image.xml COMMON = gl_XML.py glX_XML.py license.py $(API_XML) typeexpr.py COMMON_GLX = $(COMMON) glX_API.xml glX_XML.py glX_proto_common.py all: check-xorg-source $(OUTPUTS) $(SERVER_OUTPUTS) +local: $(OUTPUTS) + check-xorg-source: @if ! test -d $(GLX_DIR); then \ echo "ERROR: Must specify path to xserver checkout; set XORG_BASE."; \ diff --git a/src/mesa/glapi/OES_EGL_image.xml b/src/mesa/glapi/OES_EGL_image.xml new file mode 100644 index 000..1cb43d4 --- /dev/null +++ b/src/mesa/glapi/OES_EGL_image.xml @@ -0,0 +1,20 @@ + + + + + + + + + + + + + + + + + + + + diff --git a/src/mesa/glapi/gl_API.xml b/src/mesa/glapi/gl_API.xml index fbf8b0c..0b3d57b 100644 --- a/src/mesa/glapi/gl_API.xml +++ b/src/mesa/glapi/gl_API.xml @@ -12502,4 +12502,6 @@ +http://www.w3.org/2001/XInclude"/> + -- 1.6.5.rc2 -- 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
[Mesa3d-dev] [PATCH 07/12] dri_interface.h: Add DRI image and imageLookup extensions
These are used for implementing the various EGLImage extensions.
Signed-off-by: Kristian Høgsberg
---
include/GL/internal/dri_interface.h | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 58540d6..806f82c 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -753,4 +753,47 @@ struct __DRIdri2ExtensionRec {
};
+
+/**
+ * This extension provides functionality to enable various EGLImage
+ * extensions.
+ */
+#define __DRI_IMAGE "DRI_IMAGE"
+#define __DRI_IMAGE_VERSION 1
+
+typedef struct __DRIimageRec __DRIimage;
+typedef struct __DRIimageExtensionRec __DRIimageExtension;
+struct __DRIimageExtensionRec {
+__DRIextension base;
+
+/* FIXME: Scanout flag? */
+__DRIimage *(*createImage)(__DRIcontext *context,
+ int width, int height, int format,
+ void *loaderPrivate);
+
+__DRIimage *(*createImageFromName)(__DRIcontext *context,
+ int width, int height, int format,
+ int name, int pitch,
+ void *loaderPrivate);
+
+void (*destroyImage)(__DRIimage *image);
+};
+
+/**
+ * This extension must be implemented by the loader and passed to the
+ * driver at screen creation time. The EGLImage entry points in the
+ * various client APIs take opaque EGLImage handles and use this
+ * extension to map them to a __DRIimage.
+ */
+#define __DRI_IMAGE_LOOKUP "DRI_IMAGE_LOOKUP"
+#define __DRI_IMAGE_LOOKUP_VERSION 1
+
+typedef struct __DRIimageLookupExtensionRec __DRIimageLookupExtension;
+struct __DRIimageLookupExtensionRec {
+__DRIextension base;
+
+ __DRIimage *(*lookupImage)(__DRIcontext *context, void *image,
+ void *loaderPrivate);
+};
+
#endif
--
1.6.5.rc2
--
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
[Mesa3d-dev] [PATCH 02/12] intel: Track named regions and make sure we only have one region per named bo
Signed-off-by: Kristian Høgsberg
---
src/mesa/drivers/dri/intel/intel_regions.c | 24 +++-
src/mesa/drivers/dri/intel/intel_regions.h |3 +++
src/mesa/drivers/dri/intel/intel_screen.c | 14 ++
src/mesa/drivers/dri/intel/intel_screen.h |1 +
4 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_regions.c
b/src/mesa/drivers/dri/intel/intel_regions.c
index e2859e4..881653f 100644
--- a/src/mesa/drivers/dri/intel/intel_regions.c
+++ b/src/mesa/drivers/dri/intel/intel_regions.c
@@ -42,6 +42,7 @@
#include
#include
+#include
#include "intel_context.h"
#include "intel_regions.h"
#include "intel_blit.h"
@@ -228,10 +229,24 @@ intel_region_alloc_for_handle(struct intel_context *intel,
GLuint width, GLuint height, GLuint pitch,
GLuint handle, const char *name)
{
- struct intel_region *region;
+ struct intel_region *region, *dummy;
dri_bo *buffer;
int ret;
+ region = _mesa_HashLookup(intel->intelScreen->named_regions, handle);
+ if (region != NULL) {
+ dummy = NULL;
+ if (region->width != width || region->height != height ||
+ region->cpp != cpp || region->pitch != pitch) {
+fprintf(stderr,
+"Region for name %d already exists but is not compatible\n",
+handle);
+return NULL;
+ }
+ intel_region_reference(&dummy, region);
+ return dummy;
+ }
+
buffer = intel_bo_gem_create_from_name(intel->bufmgr, name, handle);
region = intel_region_alloc_internal(intel, cpp,
@@ -248,6 +263,10 @@ intel_region_alloc_for_handle(struct intel_context *intel,
return NULL;
}
+ region->name = handle;
+ region->screen = intel->intelScreen;
+ _mesa_HashInsert(intel->intelScreen->named_regions, handle, region);
+
return region;
}
@@ -287,6 +306,9 @@ intel_region_release(struct intel_region **region_handle)
region->pbo = NULL;
dri_bo_unreference(region->buffer);
+ if (region->name > 0)
+_mesa_HashRemove(region->screen->named_regions, region->name);
+
free(region);
}
*region_handle = NULL;
diff --git a/src/mesa/drivers/dri/intel/intel_regions.h
b/src/mesa/drivers/dri/intel/intel_regions.h
index 860ae11..6d36f3d 100644
--- a/src/mesa/drivers/dri/intel/intel_regions.h
+++ b/src/mesa/drivers/dri/intel/intel_regions.h
@@ -67,6 +67,9 @@ struct intel_region
uint32_t tiling; /**< Which tiling mode the region is in */
uint32_t bit_6_swizzle; /**< GEM flag for address swizzling requirement */
struct intel_buffer_object *pbo; /* zero-copy uploads */
+
+ uint32_t name; /**< Global name for the bo */
+ struct intel_screen *screen;
};
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 6dc20d0..f7ce87e 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -29,6 +29,7 @@
#include "main/context.h"
#include "main/framebuffer.h"
#include "main/renderbuffer.h"
+#include "main/hash.h"
#include "utils.h"
#include "xmlpool.h"
@@ -167,6 +168,11 @@ intel_get_param(__DRIscreen *psp, int param, int *value)
}
static void
+nop_callback(GLuint key, void *data, void *userData)
+{
+}
+
+static void
intelDestroyScreen(__DRIscreen * sPriv)
{
struct intel_screen *intelScreen = sPriv->private;
@@ -174,6 +180,12 @@ intelDestroyScreen(__DRIscreen * sPriv)
dri_bufmgr_destroy(intelScreen->bufmgr);
driDestroyOptionInfo(&intelScreen->optionCache);
+ /* Some regions may still have references to them at this point, so
+* flush the hash table to prevent _mesa_DeleteHashTable() from
+* complaining about the hash not being empty; */
+ _mesa_HashDeleteAll(intelScreen->named_regions, nop_callback, NULL);
+ _mesa_DeleteHashTable(intelScreen->named_regions);
+
FREE(intelScreen);
sPriv->private = NULL;
}
@@ -324,6 +336,8 @@ intel_init_bufmgr(struct intel_screen *intelScreen)
else
intelScreen->kernel_exec_fencing = GL_FALSE;
+ intelScreen->named_regions = _mesa_NewHashTable();
+
return GL_TRUE;
}
diff --git a/src/mesa/drivers/dri/intel/intel_screen.h
b/src/mesa/drivers/dri/intel/intel_screen.h
index c31b836..1ce476d 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.h
+++ b/src/mesa/drivers/dri/intel/intel_screen.h
@@ -47,6 +47,7 @@ struct intel_screen
GLboolean no_vbo;
dri_bufmgr *bufmgr;
GLboolean kernel_exec_fencing;
+ struct _mesa_HashTable *named_regions;
/**
* Configuration cache with default values for all contexts
--
1.6.5.rc2
[Mesa3d-dev] [PATCH 08/12] intel: Implement DRI image extension
Signed-off-by: Kristian Høgsberg
---
src/mesa/drivers/dri/common/dri_util.c |2 +
src/mesa/drivers/dri/common/dri_util.h |1 +
src/mesa/drivers/dri/intel/intel_regions.h |8 +++
src/mesa/drivers/dri/intel/intel_screen.c | 74
4 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index f5e7923..271232b 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -671,6 +671,8 @@ setupLoaderExtensions(__DRIscreen *psp,
psp->systemTime = (__DRIsystemTimeExtension *) extensions[i];
if (strcmp(extensions[i]->name, __DRI_DRI2_LOADER) == 0)
psp->dri2.loader = (__DRIdri2LoaderExtension *) extensions[i];
+ if (strcmp(extensions[i]->name, __DRI_IMAGE_LOOKUP) == 0)
+ psp->dri2.image = (__DRIimageLookupExtension *) extensions[i];
}
}
diff --git a/src/mesa/drivers/dri/common/dri_util.h
b/src/mesa/drivers/dri/common/dri_util.h
index e9d5a9d..9aa7c29 100644
--- a/src/mesa/drivers/dri/common/dri_util.h
+++ b/src/mesa/drivers/dri/common/dri_util.h
@@ -535,6 +535,7 @@ struct __DRIscreenRec {
* fields will not be valid or initializaed in that case. */
int enabled;
__DRIdri2LoaderExtension *loader;
+ __DRIimageLookupExtension *image;
} dri2;
/* The lock actually in use, old sarea or DRI2 */
diff --git a/src/mesa/drivers/dri/intel/intel_regions.h
b/src/mesa/drivers/dri/intel/intel_regions.h
index 6d36f3d..7ee6a98 100644
--- a/src/mesa/drivers/dri/intel/intel_regions.h
+++ b/src/mesa/drivers/dri/intel/intel_regions.h
@@ -148,4 +148,12 @@ void _mesa_copy_rect(GLubyte * dst,
const GLubyte * src,
GLuint src_pitch, GLuint src_x, GLuint src_y);
+struct __DRIimageRec {
+ struct intel_region *region;
+ GLenum internal_format;
+ GLuint format;
+ GLenum data_type;
+ void *data;
+};
+
#endif
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index f7ce87e..c2c8c6e 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -41,6 +41,7 @@
#include "intel_fbo.h"
#include "intel_screen.h"
#include "intel_tex.h"
+#include "intel_regions.h"
#include "i915_drm.h"
@@ -141,11 +142,84 @@ static const struct __DRI2flushExtensionRec
intelFlushExtension = {
intelDRI2FlushInvalidate,
};
+static __DRIimage *
+intel_create_image_internal(__DRIcontext *context,
+ int width, int height, int internal_format,
+ int name, int pitch, void *loaderPrivate)
+{
+__DRIimage *image;
+struct intel_context *intel = context->driverPrivate;
+int cpp;
+
+image = CALLOC(sizeof *image);
+image->internal_format = internal_format;
+switch (internal_format) {
+case GL_RGBA:
+ image->format = MESA_FORMAT_ARGB;
+ image->data_type = GL_UNSIGNED_BYTE;
+ break;
+case GL_RGB:
+ image->format = MESA_FORMAT_XRGB;
+ image->data_type = GL_UNSIGNED_BYTE;
+ break;
+}
+image->data = loaderPrivate;
+cpp = _mesa_get_format_bytes(image->format);
+
+if (name == 0) {
+ pitch = ((cpp * width + 63) & ~63) / cpp;
+ image->region = intel_region_alloc(intel, I915_TILING_NONE,
+ cpp, width, height, pitch, GL_TRUE);
+} else {
+ image->region = intel_region_alloc_for_handle(intel, cpp, width, height,
+pitch, name, "image");
+
+}
+if (image->region == NULL) {
+ FREE(image);
+ return NULL;
+}
+
+return image;
+}
+
+static __DRIimage *
+intel_create_image(__DRIcontext *context,
+ int width, int height, int format, void *private)
+{
+ return intel_create_image_internal(context, width, height, format,
+ 0, 0, private);
+}
+
+static __DRIimage *
+intel_create_image_from_name(__DRIcontext *context,
+int width, int height, int format,
+int name, int pitch, void *private)
+{
+ return intel_create_image_internal(context, width, height, format,
+ name, pitch, private);
+}
+
+static void
+intel_destroy_image(__DRIimage *image)
+{
+intel_region_release(&image->region);
+FREE(image);
+}
+
+static struct __DRIimageExtensionRec intelImageExtension = {
+{ __DRI_IMAGE, __DRI_IMAGE_VERSION },
+intel_create_image,
+intel_create_image_from_name,
+intel_destroy_image,
+};
+
static const __DRIextension *intelScreenExtensions[] = {
&driReadDrawableExtension,
&intelTexOffsetExtension.base,
[Mesa3d-dev] [PATCH 09/12] intel: Implement GL_OES_EGL_image entrypoints
Signed-off-by: Kristian Høgsberg
---
src/mesa/drivers/dri/intel/intel_fbo.c | 34 +
src/mesa/drivers/dri/intel/intel_tex_image.c | 51 ++
2 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index d58ffd9..f816d8c 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -200,6 +200,35 @@ intel_alloc_renderbuffer_storage(GLcontext * ctx, struct
gl_renderbuffer *rb,
}
+static void
+intel_image_target_renderbuffer_storage(GLcontext *ctx,
+ struct gl_renderbuffer *rb,
+ void *image_handle)
+{
+ struct intel_context *intel = intel_context(ctx);
+ struct intel_renderbuffer *irb;
+ __DRIscreen *screen;
+ __DRIimage *image;
+
+ screen = intel->intelScreen->driScrnPriv;
+ image = screen->dri2.image->lookupImage(intel->driContext, image_handle,
+ intel->driContext->loaderPrivate);
+ if (image == NULL)
+ return;
+
+ irb = intel_renderbuffer(rb);
+ if (irb->region)
+ intel_region_release(&irb->region);
+ intel_region_reference(&irb->region, image->region);
+
+ rb->Width = image->region->width;
+ rb->Height = image->region->height;
+ rb->Format = image->format;
+ rb->DataType = image->data_type;
+ rb->_BaseFormat = _mesa_base_fbo_format(&intel->ctx,
+ image->internal_format);
+}
+
/**
* Called for each hardware renderbuffer when a _window_ is resized.
* Just update fields.
@@ -651,4 +680,9 @@ intel_fbo_init(struct intel_context *intel)
intel->ctx.Driver.ResizeBuffers = intel_resize_buffers;
intel->ctx.Driver.ValidateFramebuffer = intel_validate_framebuffer;
intel->ctx.Driver.BlitFramebuffer = _mesa_meta_BlitFramebuffer;
+
+#if FEATURE_OES_EGL_image
+ intel->ctx.Driver.EGLImageTargetRenderbufferStorage =
+ intel_image_target_renderbuffer_storage;
+#endif
}
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/drivers/dri/intel/intel_tex_image.c
index d63292e..d9c5363 100644
--- a/src/mesa/drivers/dri/intel/intel_tex_image.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_image.c
@@ -812,6 +812,53 @@ intelSetTexBuffer(__DRIcontext *pDRICtx, GLint target,
__DRIdrawable *dPriv)
}
+static void
+intel_image_target_texture_2d(GLcontext *ctx, GLenum target,
+ struct gl_texture_object *texObj,
+ struct gl_texture_image *texImage,
+ GLeglImageOES image_handle)
+{
+ struct intel_context *intel = intel_context(ctx);
+ struct intel_texture_object *intelObj = intel_texture_object(texObj);
+ struct intel_texture_image *intelImage = intel_texture_image(texImage);
+ struct intel_mipmap_tree *mt;
+ __DRIscreen *screen;
+ __DRIimage *image;
+
+ screen = intel->intelScreen->driScrnPriv;
+ image = screen->dri2.image->lookupImage(intel->driContext, image_handle,
+ intel->driContext->loaderPrivate);
+ if (image == NULL)
+ return;
+
+ mt = intel_miptree_create_for_region(intel, target,
+ image->internal_format,
+ 0, 0, image->region, 1, 0);
+ if (mt == NULL)
+ return;
+
+ if (intelImage->mt) {
+ intel_miptree_release(intel, &intelImage->mt);
+ assert(!texImage->Data);
+ }
+ if (intelObj->mt)
+ intel_miptree_release(intel, &intelObj->mt);
+
+ intelObj->mt = mt;
+ _mesa_init_teximage_fields(&intel->ctx, target, texImage,
+ image->region->width, image->region->height, 1,
+ 0, image->internal_format);
+
+ intelImage->face = target_to_face(target);
+ intelImage->level = 0;
+ texImage->TexFormat = image->format;
+ texImage->RowStride = image->region->pitch;
+ intel_miptree_reference(&intelImage->mt, intelObj->mt);
+
+ if (!intel_miptree_match_image(intelObj->mt, &intelImage->base))
+ fprintf(stderr, "miptree doesn't match image\n");
+}
+
void
intelInitTextureImageFuncs(struct dd_function_table *functions)
{
@@ -822,4 +869,8 @@ intelInitTextureImageFuncs(struct dd_function_table
*functions)
functions->CompressedTexImage2D = intelCompressedTexImage2D;
functions->GetCompressedTexImage = intelGetCompressedTexImage;
+
+#if FEATURE_OES_EGL_image
+ functions->EGLImageTargetTexture2D = intel_image_target_texture_2d;
+#endif
}
--
1.6.5.rc2
--
SOLARIS 10 is the OS f
[Mesa3d-dev] [PATCH 00/12] EGLImage patches
Hello, Here's a patch series to implement a handful of EGLImage extensions in the DRI2 EGL driver: EGL_KHR_image_base EGL_KHR_image_pixmap GL_OES_EGL_image The implementation is a little tricky, since the EGLImage is an EGL (binding layer) type, but it's passed to client API functions such as void glEGLImageTargetTexture2DOES (GLenum target, GLeglImageOES image); void glEGLImageTargetRenderbufferStorageOES (GLenum target, GLeglImageOES image); The image argument is an EGLImage and the binding agnostic GL implementation can't do anything with it. So what I've done is to pass the image argument all the way into the backend driver, which is then expected to have some interface provided from the loader to map the opaque EGLImage to a type the driver understands. In the DRI case, I make this work with two new DRI extensions: DRI image and DRI imageLookup. The DRI image extensions is implemented by the driver and the loader (that is, src/egl/drivers/dri2) uses it to create a __DRIimage from the GEM/TTM handle for a pixmap, or possibly some other source. This is how EGL_KHR_image_pixmap is done. The DRI imageLookup extension is implemented by the loader and passed to the DRI driver at initialization time. The driver uses this extension to map the opaque EGLImage handles back to a __DRIimage struct. With this in place, I have implemented GL_OES_EGL_image. I added the glapi specification for it and I've added it as a GL extension as well. This is mostly boilerplate extension work, and it adds dd_function_table hooks for the driver to implement. There still some details I need to figure out here, for example, the extensions don't show up in the EGL extension string. Looking though the EGL_KHR_image_pixmap and GL_OES_EGL_image extensions, there seems to be no way to specify the format of the pixmap. With GLX_EXT_texture_from_pixmap, we can specifiy the format as either RGB or RGBA through the attribute list passed to glXBindTexImageEXT(). In the EGLImage model, there's no way to specify this, so I've proposed an extension in patch 11: EGL_KHR_image_pixmap_format. This adds an eglCreateImageKHR attribute, EGL_NATIVE_PIXMAP_FORMAT_KHR that takes two values: EGL_NATIVE_PIXMAP_RGB_KHR EGL_NATIVE_PIXMAP_RGBA_KHR Pretty straightforward. Finally I added a few new options to xeglgears: -pbuffer-texture, which renders to an EGL pbuffer surface and textures using eglBindTexImage() and -pixmap-texture, which renders to a EGL pixmap surface and textures from that by creating an EGLImage from the underlying X pixmap and binding that using GL_OES_EGL_image. Let me know what you think, Kristian Kristian Høgsberg (12): dri: Store the loader private passed in at dri context creation intel: Track named regions and make sure we only have one region per named bo intel: Avoid dri_bo_flink() in intel_update_renderbuffers() glapi: Add GL_OES_EGL_image glapi: GL_OES_EGL_image autogenerated files core: Implement GL_OES_EGL_image entry points dri_interface.h: Add DRI image and imageLookup extensions intel: Implement DRI image extension intel: Implement GL_OES_EGL_image entrypoints egl_dri2: Implement EGL_KHR_image and EGL_KHR_image_pixmap egl: Add proposed EGL_KHR_image_pixmap_format extension xeglgears: Add test case for texturing from an EGLImage include/EGL/eglext.h |8 + include/GL/internal/dri_interface.h | 43 + progs/egl/xeglgears.c| 95 +- src/egl/drivers/dri2/egl_dri2.c | 133 ++- src/egl/main/eglimage.c | 10 + src/egl/main/eglimage.h |1 + src/glx/indirect.c |3 +- src/mesa/drivers/dri/common/dri_util.c |5 +- src/mesa/drivers/dri/common/dri_util.h |6 + src/mesa/drivers/dri/intel/intel_context.c | 10 +- src/mesa/drivers/dri/intel/intel_fbo.c | 34 + src/mesa/drivers/dri/intel/intel_regions.c | 24 +- src/mesa/drivers/dri/intel/intel_regions.h | 11 + src/mesa/drivers/dri/intel/intel_screen.c| 88 + src/mesa/drivers/dri/intel/intel_screen.h|1 + src/mesa/drivers/dri/intel/intel_tex_image.c | 51 + src/mesa/glapi/Makefile |5 +- src/mesa/glapi/OES_EGL_image.xml | 20 + src/mesa/glapi/gl_API.xml|2 + src/mesa/glapi/glapidispatch.h | 16 +- src/mesa/glapi/glapioffsets.h|6 +- src/mesa/glapi/glapitable.h |2 + src/mesa/glapi/glapitemp.h | 12 + src/mesa/glapi/glprocs.h | 608 src/mesa/main/dd.h | 11 + src/mesa/main/fbobject.c | 24 + src/mesa/main/fbobject.h |3 + src/mesa/ma
[Mesa3d-dev] [PATCH 06/12] core: Implement GL_OES_EGL_image entry points
Signed-off-by: Kristian Høgsberg
---
src/mesa/main/dd.h| 11 +++
src/mesa/main/fbobject.c | 24
src/mesa/main/fbobject.h |3 +++
src/mesa/main/mfeatures.h |2 ++
src/mesa/main/teximage.c | 41 +
src/mesa/main/teximage.h |2 ++
6 files changed, 83 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index d98a14e..079e44b 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -1035,6 +1035,17 @@ struct dd_function_table {
GLfloat width, GLfloat height);
/*...@}*/
#endif
+
+#if FEATURE_OES_EGL_image
+ void (*EGLImageTargetTexture2D)(GLcontext *ctx, GLenum target,
+ struct gl_texture_object *texObj,
+ struct gl_texture_image *texImage,
+ GLeglImageOES image_handle);
+ void (*EGLImageTargetRenderbufferStorage)(GLcontext *ctx,
+struct gl_renderbuffer *rb,
+void *image_handle);
+#endif
+
};
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 0e6f69f..475aeab 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1008,6 +1008,30 @@ renderbuffer_storage(GLenum target, GLenum
internalFormat,
*/
}
+#if FEATURE_OES_EGL_image
+void GLAPIENTRY
+_mesa_EGLImageTargetRenderbufferStorageOES (GLenum target, GLeglImageOES image)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ ASSERT_OUTSIDE_BEGIN_END(ctx);
+ struct gl_renderbuffer *rb;
+
+ if (target != GL_RENDERBUFFER_EXT) {
+ _mesa_error(ctx, GL_INVALID_ENUM,
"EGLImageTargetRenderbufferStorageOES");
+ return;
+ }
+
+ rb = ctx->CurrentRenderbuffer;
+ if (!rb) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
"EGLImageTargetRenderbufferStorageOES");
+ return;
+ }
+
+ FLUSH_VERTICES(ctx, _NEW_BUFFERS);
+
+ ctx->Driver.EGLImageTargetRenderbufferStorage(ctx, rb, image);
+}
+#endif
/**
* Helper function for _mesa_GetRenderbufferParameterivEXT() and
diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
index 5409394..28f75df 100644
--- a/src/mesa/main/fbobject.h
+++ b/src/mesa/main/fbobject.h
@@ -89,6 +89,9 @@ _mesa_RenderbufferStorageMultisample(GLenum target, GLsizei
samples,
GLsizei width, GLsizei height);
extern void GLAPIENTRY
+_mesa_EGLImageTargetRenderbufferStorageOES(GLenum target, GLeglImageOES image);
+
+extern void GLAPIENTRY
_mesa_GetRenderbufferParameterivEXT(GLenum target, GLenum pname,
GLint *params);
diff --git a/src/mesa/main/mfeatures.h b/src/mesa/main/mfeatures.h
index 4e68bc1..f0896ee 100644
--- a/src/mesa/main/mfeatures.h
+++ b/src/mesa/main/mfeatures.h
@@ -122,5 +122,7 @@
#define FEATURE_NV_fragment_program _HAVE_FULL_GL
#define FEATURE_NV_vertex_program _HAVE_FULL_GL
+#define FEATURE_OES_EGL_image _HAVE_FULL_GL
+
#endif /* FEATURES_H */
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index da3c6f9..6b15c40 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -2448,6 +2448,47 @@ _mesa_TexImage3DEXT( GLenum target, GLint level, GLenum
internalFormat,
}
+#if FEATURE_OES_EGL_image
+void GLAPIENTRY
+_mesa_EGLImageTargetTexture2DOES (GLenum target, GLeglImageOES image)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH(ctx);
+ struct gl_texture_object *texObj;
+ struct gl_texture_image *texImage;
+
+ if (target != GL_TEXTURE_2D) {
+ _mesa_error(ctx, GL_INVALID_ENUM, "glCompressedTexImage1D(target)");
+ return;
+ }
+
+ if (ctx->NewState & _MESA_NEW_TRANSFER_STATE)
+ _mesa_update_state(ctx);
+
+ texObj = _mesa_get_current_tex_object(ctx, target);
+ _mesa_lock_texture(ctx, texObj);
+
+ texImage = _mesa_get_tex_image(ctx, texObj, target, 0);
+ if (!texImage) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glTexImage2D");
+ } else {
+ if (texImage->Data)
+ctx->Driver.FreeTexImageData( ctx, texImage );
+
+ ASSERT(texImage->Data == NULL);
+ //clear_teximage_fields(texImage); /* not really needed, but helpful */
+ ctx->Driver.EGLImageTargetTexture2D(ctx, target,
+ texObj, texImage, image);
+
+ /* state update */
+ texObj->_Complete = GL_FALSE;
+ ctx->NewState |= _NEW_TEXTURE;
+ }
+ _mesa_unlock_texture(ctx, texObj);
+
+}
+#endif
+
void GLAPIENTRY
_mesa_TexSubImage1D( GLenum target, GLint level,
diff --git a/src/mesa/main/teximage.h b/src/mesa/main/teximage.h
index 97c9018..d82cc98 100644
--- a/src/mesa/main/teximage.h
+++ b/src/mesa/main/teximage.h
@@ -165,6 +165,8 @@ _mesa_TexImage3DEXT( GLenum target, GLint level, GLenum
internalformat,
GLint border, GLenum format, GL
Re: [Mesa3d-dev] /src/mesa/drivers/dri/mach64 does not compile
This is fixed now. On Wed, Feb 10, 2010 at 4:48 PM, Johannes Obermayr wrote: > Please CC me... > > author Corbin Simpson 2010-02-10 09:39:21 > (GMT) > committer Corbin Simpson 2010-02-10 > 20:35:39 (GMT) > commit 412ffb7a3ab8c0174aa921a4a10af3eaa03648da > > > gmake[6]: Leaving directory > `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/i965' > gmake[5]: Leaving directory > `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/i965' > gmake[5]: Entering directory > `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/mach64' > running /usr/bin/makedepend > gmake[5]: Leaving directory > `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/mach64' > gmake[5]: Entering directory > `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/mach64' > gmake[6]: Entering directory > `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/mach64' > 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 mach64_context.c > -o mach64_context.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 mach64_ioctl.c -o > mach64_ioctl.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 mach64_screen.c -o > mach64_screen.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 mach64_span.c -o > mach64_span.o > mach64_screen.c: In function 'mach64FillInModes': > mach64_screen.c:122: error: 'TRUE' undeclared (first use in this function) > mach64_screen.c:122: error: (Each undeclared identifier is reported only once > mach64_screen.c:122: error: for each function it appears in.) > gmake[6]: *** [mach64_screen.o] Error 1 > gmake[6]: *** Waiting for unfinished jobs > gmake[6]: Leaving directory > `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/mach64' > gmake[5]: *** [lib] Error 2 > gmake[5]: Leaving directory > `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/mach64' > gmake[4]: *** [subdirs] Error 1 > gmake[4]: Leaving directory > `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri' > gmake[3]: *** [default] Error 1 > gmake[3]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/mesa/drivers' > gmake[2]: *** [driver_subdirs] Error 2 > gmake[2]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/mesa' > make[1]: *** [subdirs] Error 1 > make[1]: Leaving directory `/usr/src/packages/BUILD/Mesa/src' > make: *** [default] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.c6ZFty (%build) > > -- > 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
Re: [Mesa3d-dev] RFC: gallium-embedded
On Tue, Feb 9, 2010 at 9:49 AM, José Fonseca wrote: > On Tue, 2010-02-09 at 06:37 -0800, Kristian Høgsberg wrote: >> On Wed, Feb 3, 2010 at 1:41 PM, José Fonseca wrote: >> ... >> >> This reminds me there's a patch series from mesa3d-dev that removed a >> >> bunch of Mesa's std C wrappers (like _mesa_memcpy()). Mabye some of >> >> those could be applied after gallium-embedded but before the >> >> src/platform work. >> > >> > Great. It seems we have a plan then. >> >> What happened to the plan? Are we going to move the header files out >> to src/os or are they staying under src/gallium/auxillary/os? Is the >> idea that code under src/mesa can include the headers from >> src/gallium/auxillary/os? >> >> Kristian > > Kristian, > > Nothing happened to the plan -- I will move the header files out to > src/platform or src/os or whatever name people feel comfortable with. > > But I don't have time to do it this week or likely the next. > > It just not a matter of moving files -- it's also necessary to break the > dependency of the os stuff from p_config.h and p_compiler.h somehow. I > don't want gallium interfaces to depend on this new shared module nor > vice-versa. It's not very hard but getting it right needs more attention > and time than I can dispense at the moment. > > If you prefer getting a start at this yourself immediately then I'm fine > with you starting a feature branch to rehearse this. Ok, cool, I might do that, but mainly I just wanted to understand if the plan was to leave the headers under src/gallium or move them out, which is now clear. thanks, 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
Re: [Mesa3d-dev] RFC: gallium-embedded
On Wed, Feb 3, 2010 at 1:41 PM, José Fonseca wrote: ... >> This reminds me there's a patch series from mesa3d-dev that removed a >> bunch of Mesa's std C wrappers (like _mesa_memcpy()). Mabye some of >> those could be applied after gallium-embedded but before the >> src/platform work. > > Great. It seems we have a plan then. What happened to the plan? Are we going to move the header files out to src/os or are they staying under src/gallium/auxillary/os? Is the idea that code under src/mesa can include the headers from src/gallium/auxillary/os? 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
Re: [Mesa3d-dev] [PATCH 1/6] intel: Update comment in intelInitScreen2 to noting DRI2 protocol issues
On Mon, Feb 8, 2010 at 8:09 PM, Ian Romanick wrote:
> From: Ian Romanick
For the whole series:
Reviewed-by: Kristian Høgsberg
> ---
> src/mesa/drivers/dri/intel/intel_screen.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
> b/src/mesa/drivers/dri/intel/intel_screen.c
> index c9ef164..1acd7a5 100644
> --- a/src/mesa/drivers/dri/intel/intel_screen.c
> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
> @@ -401,9 +401,9 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
> __DRIconfig **new_configs;
> int depth_factor;
>
> - /* With DRI2 right now, GetBuffers always returns a depth/stencil
> buffer
> - * with the same cpp as the drawable. So we can't support depth cpp !=
> - * color cpp currently.
> + /* Starting with DRI2 protocol version 1.1 we can request a
> depth/stencil
> + * buffer that has a diffferent number of bits per pixel than the color
> + * buffer. This isn't yet supported here.
> */
> if (fb_type[color] == GL_UNSIGNED_SHORT_5_6_5) {
> depth_bits[1] = 16;
> --
> 1.6.6
>
>
> --
> 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] [xserver patch v5 3/5] glx: Enforce a 1:1 correspondence between GLX and X11 windows.
2010/2/8 Francisco Jerez :
> The spec says (regarding glXCreateWindow): "If there is already a
> GLXFBConfig associated with win (as a result of a previous
> glXCreateWindow call), then a BadAlloc error is generated.". It will
> also come useful to implement DRI2InvalidateBuffers for the indirect
> case.
>
> Signed-off-by: Francisco Jerez
Looks good,
Reviewed-by: Kristian Høgsberg
> ---
> v5: Simplification as suggested by Kristian.
>
> glx/glxcmds.c | 24 +++-
> glx/glxserver.h | 1 +
> 2 files changed, 24 insertions(+), 1 deletions(-)
>
> diff --git a/glx/glxcmds.c b/glx/glxcmds.c
> index 77afbf4..cac30e6 100644
> --- a/glx/glxcmds.c
> +++ b/glx/glxcmds.c
> @@ -51,6 +51,15 @@
> #include "indirect_table.h"
> #include "indirect_util.h"
>
> +static int glxWindowPrivateKeyIndex;
> +static DevPrivateKey glxWindowPrivateKey = &glxWindowPrivateKeyIndex;
> +
> +__GLXdrawable *
> +glxGetDrawableFromWindow(WindowPtr pWin)
> +{
> + return dixLookupPrivate(&pWin->devPrivates, glxWindowPrivateKey);
> +}
> +
> static int
> validGlxScreen(ClientPtr client, int screen, __GLXscreen **pGlxScreen, int
> *err)
> {
> @@ -519,6 +528,9 @@ __glXGetDrawable(__GLXcontext *glxc, GLXDrawable drawId,
> ClientPtr client,
> return NULL;
> }
>
> + dixSetPrivate(&((WindowPtr)pDraw)->devPrivates, glxWindowPrivateKey,
> + pGlxDraw);
> +
> return pGlxDraw;
> }
>
> @@ -1107,7 +1119,7 @@ __glXDrawableRelease(__GLXdrawable *drawable)
> }
> }
>
> -static int
> +static int
> DoCreateGLXDrawable(ClientPtr client, __GLXscreen *pGlxScreen, __GLXconfig
> *config,
> DrawablePtr pDraw, XID glxDrawableId, int type)
> {
> @@ -1128,6 +1140,10 @@ DoCreateGLXDrawable(ClientPtr client, __GLXscreen
> *pGlxScreen, __GLXconfig *conf
> return BadAlloc;
> }
>
> + if (type == GLX_DRAWABLE_WINDOW)
> + dixSetPrivate(&((WindowPtr)pDraw)->devPrivates,
> + glxWindowPrivateKey, pGlxDraw);
> +
> return Success;
> }
>
> @@ -1422,6 +1438,12 @@ int __glXDisp_CreateWindow(__GLXclientState *cl,
> GLbyte *pc)
> return BadWindow;
> }
>
> + /* Make sure there're no already associated GLX drawables. */
> + if (glxGetDrawableFromWindow((WindowPtr)pDraw)) {
> + client->errorValue = req->window;
> + return BadAlloc;
> + }
> +
> if (!validGlxFBConfigForWindow(client, config, pDraw, &err))
> return err;
>
> diff --git a/glx/glxserver.h b/glx/glxserver.h
> index 1daf977..3c49b5e 100644
> --- a/glx/glxserver.h
> +++ b/glx/glxserver.h
> @@ -80,6 +80,7 @@ typedef struct __GLXcontext __GLXcontext;
>
> extern __GLXscreen *glxGetScreen(ScreenPtr pScreen);
> extern __GLXclientState *glxGetClient(ClientPtr pClient);
> +extern __GLXdrawable *glxGetDrawableFromWindow(WindowPtr pWin);
>
> //
>
> --
> 1.6.4.4
>
>
--
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] [xserver patch v4 3/5] glx: Enforce a 1:1 correspondence between GLX and X11 windows.
On Mon, Feb 8, 2010 at 1:25 PM, Francisco Jerez wrote:
> The spec says (regarding glXCreateWindow): "If there is already a
> GLXFBConfig associated with win (as a result of a previous
> glXCreateWindow call), then a BadAlloc error is generated.". It will
> also come useful to implement DRI2InvalidateBuffers for the indirect
> case.
(from elsewhere in the thread:)
>> Can you just use the existing __glXDrawableRes for tracking this?
>>
> I don't think so. To implement DRI2InvalidateBuffers we need a way to
> map an X11 window to its GLX window: In the GLX1.3 world the client
> decides the IDs of its GLX drawables so in general GLX and X11 drawable
> IDs aren't going to be the same.
Ah yes, you're right. A few comments below.
> Signed-off-by: Francisco Jerez
> ---
> glx/glxcmds.c | 51 +--
> glx/glxserver.h | 1 +
> 2 files changed, 46 insertions(+), 6 deletions(-)
>
> diff --git a/glx/glxcmds.c b/glx/glxcmds.c
> index 77afbf4..0e1c89c 100644
> --- a/glx/glxcmds.c
> +++ b/glx/glxcmds.c
> @@ -51,6 +51,15 @@
> #include "indirect_table.h"
> #include "indirect_util.h"
>
> +static int glxWindowPrivateKeyIndex;
> +static DevPrivateKey glxWindowPrivateKey = &glxWindowPrivateKeyIndex;
> +
> +__GLXdrawable *
> +glxGetDrawableFromWindow(WindowPtr pWin)
> +{
> + return dixLookupPrivate(&pWin->devPrivates, glxWindowPrivateKey);
> +}
> +
> static int
> validGlxScreen(ClientPtr client, int screen, __GLXscreen **pGlxScreen, int
> *err)
> {
> @@ -473,6 +482,7 @@ __glXGetDrawable(__GLXcontext *glxc, GLXDrawable drawId,
> ClientPtr client,
> int *error)
> {
> DrawablePtr pDraw;
> + WindowPtr pWin;
> __GLXdrawable *pGlxDraw;
> int rc;
>
> @@ -499,6 +509,12 @@ __glXGetDrawable(__GLXcontext *glxc, GLXDrawable drawId,
> ClientPtr client,
> return NULL;
> }
>
> + pWin = (WindowPtr)pDraw;
> +
> + pGlxDraw = glxGetDrawableFromWindow(pWin);
> + if (pGlxDraw)
> + return pGlxDraw;
If there already is a GLXWindow for the window, the validGlxDrawable()
call above should return the __GLXdrawable for it, so this hunk
shouldn't be necessary.
> if (pDraw->pScreen != glxc->pGlxScreen->pScreen) {
> client->errorValue = pDraw->pScreen->myNum;
> *error = BadMatch;
> @@ -519,6 +535,8 @@ __glXGetDrawable(__GLXcontext *glxc, GLXDrawable drawId,
> ClientPtr client,
> return NULL;
> }
>
> + dixSetPrivate(&pWin->devPrivates, glxWindowPrivateKey, pGlxDraw);
> +
> return pGlxDraw;
> }
>
> @@ -1107,9 +1125,10 @@ __glXDrawableRelease(__GLXdrawable *drawable)
> }
> }
>
> -static int
> +static int
> DoCreateGLXDrawable(ClientPtr client, __GLXscreen *pGlxScreen, __GLXconfig
> *config,
> - DrawablePtr pDraw, XID glxDrawableId, int type)
> + DrawablePtr pDraw, XID glxDrawableId, int type,
> + __GLXdrawable **ret)
> {
> __GLXdrawable *pGlxDraw;
>
> @@ -1128,6 +1147,9 @@ DoCreateGLXDrawable(ClientPtr client, __GLXscreen
> *pGlxScreen, __GLXconfig *conf
> return BadAlloc;
> }
>
> + if (ret)
> + *ret = pGlxDraw;
> +
I would just see if type is GLX_DRAWABLE_WINDOW and set the window
private in DoCreateGLXDrawable() if it is. Less code churn.
The rest looks good.
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
Re: [Mesa3d-dev] [xserver patch v4 3/5] glx: Enforce a 1:1 correspondence between GLX and X11 windows.
On Mon, Feb 8, 2010 at 1:25 PM, Francisco Jerez wrote: > The spec says (regarding glXCreateWindow): "If there is already a > GLXFBConfig associated with win (as a result of a previous > glXCreateWindow call), then a BadAlloc error is generated.". It will > also come useful to implement DRI2InvalidateBuffers for the indirect > case. Can you just use the existing __glXDrawableRes for tracking this? cheers, 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
Re: [Mesa3d-dev] [PATCH 0/2] Make GLX optional in libGL
2010/2/6 Chia-I Wu : > On Fri, Feb 05, 2010 at 07:24:00PM -0500, Kristian Høgsberg wrote: >> 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. > Do we have to list the glapi object files? Is -Wl,--whole-archive > enough? I don't think that works on other platforms. > I think something like "ABI breakage for Linux/X11" should also be added > to the description of --disable-glx. libGL.so is required to have both > GL and GLX entries on Linux/X11. Incidentally, there is an implementers > guide on Khronos website that you might find interesting Is that really necessary? The option defaults to off, and anybody passing --disable-glx shouldn't be surprised when glx symbols are not no longer present in libGL. It's pretty self-explanatory. > I've also been thinking how to design the configure options such that it > is possible to produce libraries for the target platform (libGL with or > without GLX, or maybe OpenGL ES DRI drivers) for normal users. > Addtionally, it should also be possible to enable everything so that any > build failure can be catched. We might be able to start with smaller > steps. What smaller step would you suggest? I don't see a way to break this patch into smaller pieces, and it's functionality we'll have to add to mesa at some point. >> 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. > I haven't tried this. But ideally, I think src/glx/x11/ can be moved up > one level to src/glx/. This directory will not be visited when > --disable-glx. But when visited, it will build libglx.a from the > sources. > > We can then build libGL.so with or without libglx.a depending on the > configure optins. Later, src/mesa/drivers/x11/ could be changed to > build libglxsw.a. We will be able to choose between 3 flavors of > libGL.so, or choose all of them (to catch build failure) I wanted to do something similar, but the problem is: where do you build libGL? And glx is part of libGL so it's consistent to call the directory src/gl. And I don't think it's worth the effort to make it possible to plug in different glx implementations, we already have the dri sw driver as well as server side sw fallback for glx. cheers, 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] [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/
[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_dri
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 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
Re: [Mesa3d-dev] RFC: gallium-embedded
On Wed, Feb 3, 2010 at 10:51 AM, José Fonseca wrote: > On Wed, 2010-02-03 at 07:38 -0800, Kristian Høgsberg wrote: >> On Wed, Feb 3, 2010 at 10:31 AM, Keith Whitwell wrote: >> > Historically we had a lot of helpers in gallium/include, which have been >> > incrementally moved out to gallium/auxiliary. >> >> Is there a way we can structure the code so that the atomic operations >> can be made available for core mesa (I guess I'm talking about the GL >> state tracker/implementation, either way, stuff like struct >> gl_framebuffer refcounts etc).? > > Yes. The [pu]_atomic.h header is pretty much self sufficient. If we > replace the PIPE_CC_xxx by the original predefined compiler macros it > would be completely self sufficient and could be shared between Mesa and > Gallium. Perhaps somewhere inside mesa/include. > > Another possibility would be to put the compiler and os abstraction > stuff in a shared component between Mesa and Gallium. Most of the stuff > has the same origin anyway. It requires a bit more of playing with the > build system but it's perfectly feasible, especially now that the os > abstraction stuff no longer depends on other gallium auxiliary modules. Either way sounds good to me - something like src/platform could work, but I don't have a strong preference. I can help out if you want, but it sounds like you're already moving things around so I would probably just step on your toes :-) cheers, 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
Re: [Mesa3d-dev] RFC: gallium-embedded
On Wed, Feb 3, 2010 at 10:31 AM, Keith Whitwell wrote: > Historically we had a lot of helpers in gallium/include, which have been > incrementally moved out to gallium/auxiliary. Is there a way we can structure the code so that the atomic operations can be made available for core mesa (I guess I'm talking about the GL state tracker/implementation, either way, stuff like struct gl_framebuffer refcounts etc).? cheers, 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] DRI2 driver for EGL in the works
Hi all, I'm working on a DRI2 driver for the mesa EGL, implementation. I have an egl-dri2 branch in my repo over here: http://cgit.freedesktop.org/~krh/mesa/commit/?h=egl-dri2 I know that the xdri driver also supports dri2 by including the glx source, but I don't think that's the best way to do it. The above branch has around 800 lines of code to interface the EGL stack to DRI2 and it's a nice, self-contained implementation., that mostly just forwards to the DRI2 driver entry points. Also, I'm going to add support for EGL with a DRI2 driver on the KMS framebuffer with this implementation, something that's hard to do if we try to share the sources with GLX. cheers, 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
Re: [Mesa3d-dev] Inter-StateTracker communication
On Mon, Jan 18, 2010 at 1:45 PM, Brian Paul wrote: > Chia-I Wu wrote: >> On Fri, Jan 15, 2010 at 08:44:27AM -0700, Brian Paul wrote: >>> Chia-I Wu wrote: 2010/1/15 Michel Dänzer : Another question I have is, if depth/stencil should be shareable, how about other buffers like multisample buffer? (This is a real question that has bothered me for a while. I am eager for an answer here.) >>> Yes, I believe the GLX spec indicates that all ancillary buffers >>> associated with a window are to be sharable. >> Thanks. This helps a lot. >> >> This is a corner issue, but suppose two contexts are bound to the same >> drawable. One of them wants a depth buffer while the other doesn't (or >> wants a different depth size). There might be a race because one would >> destroy the depth buffer of the other. But this should probably be >> solved by making either of the context incompatible with the drawable. > > The GLX spec says something about framebuffer and context > compatibility in terms of RGB vs. CI and some other things. Both GLX > contexts and GLX drawables are generally created with the same GLX > visual (or FB config). But if a context created w/out Z were > successfully bound a window without a Z buffer, the Z buffer would not > be magically destroyed. > > Note that the issues of framebuffer/context compatibility is probably > much more lax nowadays since we have things like framebuffer objects > that may have any kind of combination of ancillary buffers. > > When we work on code in this area we should also consider the case of > using a rendering context that's bound to no window at all. That > could be useful for FBO rendering or just compiling shaders, etc. > Mesa would probably fail if this were attempted today, but that should > get fixed. I just implemented this for then intel DRI driver. It is indeed very useful and quite straight forward. My take on the MESA_screen_surface + EGL is that we shouldn't try to wrap the KMS API in a GL extension. It's a complicated API that is still evolving. Instead, being able to bind a native GEM/TTM buffer to a GL render buffer along with an extension to make a context current without requiring a surface/drawable is a perfect companion to the KMS API. I'm finishing up a branch with this work now and will post an announcement/description later. cheers, Kristian -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Event-based buffer validation for DRI2.
On Sun, Jan 17, 2010 at 11:18 PM, Francisco Jerez wrote: > Kristian Høgsberg writes: >> No, it sounds good, I'm happy that you're looking into this. I'll >> have a closer look tomorrow, but what I've had in mind for this kind >> of thing was that we could just allocate the new buffers up front in >> the X server. Then, instead of an invalidate event and a subsequent >> DRI2GetBuffers, we'll just have a "here are your new buffers event", >> so we avoid the round trip. > > Yeah that's sensible, the only problem I see with doing things that way > is that it doesn't give the driver an opportunity to flush its rendering > queues before swapping buffers, so some of it could be lost buried in > the old buffers. Right. Another option is to tell the client about new buffers in the DRI2SwapBuffer/DRI2CopyRegion reply instead - or to kill two birds with one stone, make DRI2SwapBuffers/DRI2CopyRegion one-way requests (that is, requests without a reply) and then send an event instead. This lets the client do other things while waiting for the server to reply, and we'll wait for the event to arrive in the GetBuffers callback from the driver if it hasn't already. The event will always be sent in response to either DRI2SwapBuffer or DRI2CopyRegion, which addresses your concern about sending the event to everybody. The client must wait for the event before it starts rendering the next frame since it could receive new buffers and in any case the server needs to submit the back->front blit first (which is the reason DRI2CopyRegion is a round-trip). That would be the ideal solution as far as I know, and if we're changing things, this is what we should go for. cheers, Kristian -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Event-based buffer validation for DRI2.
On Sat, Jan 16, 2010 at 4:58 PM, Francisco Jerez wrote: > The current buffer validation approach (AKA the DRI2 glViewport hack) > is both incorrect (because a compliant OpenGL application may opt for > the identity as viewport transform and work with window coordinates > directly) and inefficient (some programs have the habit of calling > glViewport several times per frame (e.g. OpenArena), causing many > unnecessary roundtrips). > > This changeset gives DRI2 the ability to report drawable changes in an > asynchronous way, but it's a bit intrusive so I expect all sorts of > complaints to come. No, it sounds good, I'm happy that you're looking into this. I'll have a closer look tomorrow, but what I've had in mind for this kind of thing was that we could just allocate the new buffers up front in the X server. Then, instead of an invalidate event and a subsequent DRI2GetBuffers, we'll just have a "here are your new buffers event", so we avoid the round trip. Thanks, Kristian -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] fix more -fvisibility=hidden breakages
2010/1/10 Chia-I Wu : > Hi Kristian, > > I found there are some more breakages after -fvisibility=hidden in > Gallium state trackers. This patch series marks 3 APIs public > > * OpenVG API (patch 1) > * st_public.h (patch 3) > * GLX API in GLX state tracker (patch 4) > > I am working on a new EGL driver and it works again with this patch > series. Thanks, applied. Kristian -- 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] [PATCH] Compile with -fvisibility-hidden by default
On Sun, Jan 3, 2010 at 3:24 PM, José Fonseca wrote:
> On Sun, 2010-01-03 at 08:45 -0800, Brian Paul wrote:
>> 2010/1/2 Chia-I Wu :
>> > On Sat, Jan 02, 2010 at 07:01:02PM -0500, Kristian Høgsberg wrote:
>> >> We have all functions that need to be visible marked with PUBLIC and
>> >> this is trimming around 4% off the DRI driver .so size.
>> > I love this change!
>> >
>> > It might require another patch, but would it be possible to stop marking
>> > functions like _mesa_GenTextures as GLAPIENTRY? I think they are not
>> > public either in normal build.
>>
>> This would have to be checked on Windows. I think the x86 dispatch
>> code is sensitive to the Windows calling conventions implied by
>> GLAPIENTRY.
>
> Brian is right.
>
> GLAPI controls symbol visibility, both on unices (i.e.,
> _attribute__((visibility("default" and windows (i.e.,
> _declspec(dllexport).
>
> GLAPIENTRY controls the calling convention (i.e., __stdcall presence or
> absence).
>
> This can be easily seen on top of GL/GL.h.
>
> So in summary, GLAPI can and probably should be removed for _mesa_*
> functions. GLAPIENTRY cannot.
Ok, from all this I didn't see anything against enabling
-fvisibility-hidden by default so I've committed the patch. Also, the
_mesa_* entrypoints are only GLAPIENTRY, not GLAPI, so they are
already hidden.
cheers,
Kristian
--
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] Dri2 swapbuffers,
2009/12/29 Thomas Hellstrom : > Kristian, > > I was looking at how Swapbuffers is done with DRI2 when a fake front is > present: > > The back buffer is copied to the real front, and then the real front is > copied back to the fake. > > This causes some problems in the vmwgfx drivers where reading from the real > front should be avoided if at all possible. > > Assuming that apps that really care about stuff X has rendered to the real > frontbuffer will explicitly call glxWaitX, could we perhaps change this > behavior to: > > 1) Copy back to fake front. > 2) Copy fake front to real front. > > Or would that break something? I think that should be fine, though I prefer copying the back to front and fake front, when present? Like the attached patch, which also avoids flushing and creating the region twice. cheers, Kristian diff --git a/src/glx/x11/dri2_glx.c b/src/glx/x11/dri2_glx.c index 89efe3a..0d3b1a2 100644 --- a/src/glx/x11/dri2_glx.c +++ b/src/glx/x11/dri2_glx.c @@ -83,8 +83,6 @@ struct __GLXDRIdrawablePrivateRec int have_fake_front; }; -static void dri2WaitX(__GLXDRIdrawable * pdraw); - static void dri2DestroyContext(__GLXDRIcontext * context, __GLXscreenConfigs * psc, Display * dpy) @@ -223,12 +221,10 @@ dri2CopySubBuffer(__GLXDRIdrawable * pdraw, /* should get a fence ID back from here at some point */ DRI2CopyRegion(pdraw->psc->dpy, pdraw->xDrawable, region, DRI2BufferFrontLeft, DRI2BufferBackLeft); + if (!priv->have_fake_front) + DRI2CopyRegion(pdraw->psc->dpy, pdraw->xDrawable, region, + DRI2BufferFakerontLeft, DRI2BufferBackLeft); XFixesDestroyRegion(pdraw->psc->dpy, region); - - /* Refresh the fake front (if present) after we just damaged the real -* front. -*/ - dri2WaitX(pdraw); } static void -- 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
[Mesa3d-dev] [PATCH] Compile with -fvisibility-hidden by default
We have all functions that need to be visible marked with PUBLIC and this is trimming around 4% off the DRI driver .so size. --- Is there a reason this isn't on by default? cheers, Kristian configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 8504c3c..a0aaba9 100644 --- a/configure.ac +++ b/configure.ac @@ -95,7 +95,7 @@ esac dnl Add flags for gcc and g++ if test "x$GCC" = xyes; then -CFLAGS="$CFLAGS -Wall -Wmissing-prototypes -std=c99 -ffast-math" +CFLAGS="$CFLAGS -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden" # Work around aliasing bugs - developers should comment this out CFLAGS="$CFLAGS -fno-strict-aliasing" -- 1.6.5.rc2 -- 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
[Mesa3d-dev] Removing DRI1 from Intel dri driver
Hi all,
I have a patch series here:
http://cgit.freedesktop.org/~krh/mesa/log/?h=remove-dri1
to remove DRI1 support from the Intel DRI driver. The Intel DDX no
longer supports DRI1 and it makes sense to remove DRI1 support from
the DRI driver as well. I split it up in a series of commits, with
the first one taking the DRI1 (legacy) extension out of the list of
Intel driver extensions. The remaining commits removed pieces of DRI1
only code bit by bit. It should be all dead code, but I did it
piecewise so we can bisect if something breaks in the DRI2 path.
There is also a big commit to rename the remaining
__DRI{screen,drawable,context}Private to
__DRI{screen,drawable,context}. It's a leftover from when I reworked
the DRI driver interface for DRI2. I merged the Private and
non-private structs (it's all private now) and I just left a typedef
in the code to avoid having to do a massive rename. That was probably
stupid and I decided to do the rename now - it turned out to be a
one-line find+sed job... It's straight forward and I don't expect it
to clash with anybodys outstanding work, but I figured I'd mention it
on the list before merging.
Any objections?
cheers,
Kristian
--
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] Importing "real" strtod code
On Thu, Oct 8, 2009 at 5:47 PM, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > The root cause of bug #23308 has been determined to be the use of strtod > in our assembly and GLSL parsers. When LANG is set to a locale that > changes the radix from "." to, say, ",", floating point numbers are not > parsed correctly. > > It seems that the correct fix is to have _mesa_strtod actually implement > strtod and ignore the locale setting. I considered writing my own, but > low-level floating point processing is one of those tricks best left to > experts. I've searched the net, and found an implementation. It is > extremely complex, and the code is quite archaic. > > What I found is David Gay's dtoa.c (http://www.netlib.org/fp/dtoa.c). > Should I use this, or does anyone know of a better implementation? GNU libc has strtod_l, which takes a locale_t as its last argument. Use newlocale() to create a locale_t to pass to strtod_l and freelocale() to free it. We could create the locale up front and store it in the context or probably even just as a global variable. That doesn't solve the problem for non-glibc platforms, of course, but pulling in a appropriately licensed strtod in that case is not a big problem. cheers, Kristian -- 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] Dispatch table in OpenGL ES state tracker
On Tue, Sep 1, 2009 at 6:08 AM, Chia-I Wu wrote: > On Thu, Aug 27, 2009 at 09:38:26AM -0600, Brian Paul wrote: >> >The current plan is to keep APIspec.txt and add a new es_API.xml. >> >es_API.xml defines the OpenGL ES API, as gl_API.xml does for OpenGL, and >> >is used to generate glapi sources under $(TOP)/src/mesa/es/glapi/. Mesa >> >and DRI drivers can then be compiled with -I$(TOP)/src/mesa/es so that >> >they find the es version of glapi. >> >I am still working on es_API.xml. In gl_API.xml, entries defined by >> >Linux OpenGL ABI have assigned offsets, and they are kept. I don't know >> >if this is feasible, but I am hoping that a DRI driver can support both >> >OpenGL and OpenGL ES in the end. >> I think that should be possible, but I wouldn't be suprised if >> there's a gotcha. > The work is still in process, but I am able to use glapi for dispatching > in es state tracker, with glapi generated by a new set of XMLs. The es1 > demos seem to work fine. > > Most of the time was spent on writing XMLs for OpenGL ES 1.x and 2.x. I > want to talk about how I did it. Feedbacks would be appreciated. Excellent work, I think this is the exact right approach. I think we should use this for the regular GL API as well, ie move your xml files up to src/mesa/glapi and generate the different tables into src/mesa/glapi/gl, src/mesa/glapi/es1 and src/mesa/glapi/es2. > I put all the XMLs are put under src/mesa/glapi/es/. Headers are > generated under src/mesa/glapi/es/es1/glapi/ and > src/mesa/glapi/es/es2/glapi/ for 1.x and 2.x respectively. Mesa can be > compiled with different sets of glapi headers by changing the include > path to, say, -I$(TOP)/src/mesa/glapi/es/es1. > > There are total 8 XMLs: > > base1_API.xml > base2_API.xml > > Base definitions that is common to OpenGL and OpenGL ES, for version > 1.x and 2.x respectively. The categories are named after OpenGL > versions. That is, "base1.5" corresponds to a subset of OpenGL 1.5. > It is the intersection of OpenGL 1.5, OpenGL ES 1.1, and OpenGL ES 2.0. The distinction between base1.0 and base1.0es only exists inside base1_API.xml, right? I mean, it's just for keeping track for which parts of the API come from where, the generated output won't have this distinction in any way, right? I'm not too familiar with the python tools... :) > es1_API.xml > es2_API.xml > > Definitions of OpenGL ES 1.x and 2.0. The categories defined are > "es1.0", "es1.1", and "es2.0", with "core" variants. > > Take "es2.0core" for example. "es2.0" inherits "es2.0core" to form > OpenGL ES 2.0. On the other hand, "base2.0" is inherited by > "es2.0core" which is the intersection of OpenGL 2.0 and OpenGL ES 2.0. > > es1_EXT.xml > > Definitions of OpenGL ES extensions, categoried by extension names. > They are es 1.x specific because, for example, ScalexOES is defined to > be an alias of Scalex, which is not defined in es 2.0. > > There should be es2_EXT.xml for es 2.0 specific extensions, and > es_EXT.xml for extensions that are common to es 1.x and 2.0. > > es_COMPAT.xml > es1_COMPAT.xml > es2_COMPAT.xml > > Definitions for Mesa compatibility. They define the functions needed > by mesa so that it compiles. It also defines stubs for OpenGL 1.0 to > 1.2 and GL_ARB_multitexture to maintain the ABI of glapi_table. > > With the XMLs ready, it is possible to compile mesa with different sets > of glapi. For example, one can compile libesv1gallium.a and > libesv1api.a for es 1.x. They are just like libmesagallium.a and > libglapi.a, except that a different set of glapi and only a subset of > mesa sources are used. I tried generating the files, but you use a -c option to gl_some of the python scripts that doesn't exist on master. I just removed it and it worked, but I don't know what you were trying to do there. cheers, Kristian >> >I am hand-editing es_API.xml. Is this also how gl_API.xml is written? >> I think Ian may have generated the first version of gl_API.xml from >> the previous python-based description file, but we edit it by hand >> now. > > -- > Regards, > olv > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___
Re: [Mesa3d-dev] Dispatch table in OpenGL ES state tracker
On Mon, Aug 24, 2009 at 12:02 AM, Chia-I Wu wrote: > On Fri, Aug 21, 2009 at 08:48:57AM -0600, Brian Paul wrote: >> >>Yes, the dispatch table should go back in at some point. Since ES >> >>doesn't have display lists, it wasn't essential to have a dispatch >> >>table. And since I was pressed for time, it was omitted. >> >Do you have any preference how it is done? >> I'd opt to re-use the existing glapi dispatcher. > I will spend some time studying glapi scripts and the build system. To > see if I can come up with a way to use it in es state tracker. I use the dispatch table in eagle, it's pretty easy to hook up. I put all the dispatch table related files under glapi/ and there's a makefile target (import-glapi) to import the files from mesa. > For me, I want to have accelerated OpenGL|ES on x86 laptops in the end. > >From the changelog, I think intel and amd still focus on the DRI > drivers, right? For my own purpose, it seems it is better to go > OpenGL|ES over DRI. But I am afraid that it may be against the switch > to gallium. Do you have any suggestion? DRI and OpenGL|ES are two different things and not mutually exclusive. The eagle project is a DRI driver based EGL stack, but of course it doesn't actually implement GLES. However, that can probably be fixed by providing a different dispatch table. I've been wanting to merge the DRI loader from eagle into the mesa EGL code for a while, which should let the mesa EGL code load the supported intel drivers. cheers, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] EGL driver API overhaul
2009/8/13 Brian Paul : > Kristian Høgsberg wrote: >> >> On Thu, Aug 13, 2009 at 3:01 AM, Chia-I Wu wrote: >>> >>> Hi all, >>> >>> While working on EGL and its drivers, I found that I always have to >>> perform a lookup to convert an EGL handle (EGLDisplay, EGLContext, etc.) >>> to its internal data structure (_EGLDisplay, _EGLContext, etc.). After >>> the lookup, I also have to error check the result and set proper error >>> code. >>> >>> Existing drivers sometime do not check the result, or do not to set the >>> error code. Even the default implementation in EGL core forgets to do >>> so here and there. I think it is a sign that lookup and error checking >>> is better to be done in EGL core, or more specifically, in the EGL API >>> entry points. >> >> Hi, >> >> I've been looking at the mesa egl implementation a bit too, with an >> eye to merge eagle[1] into it. I'm also not happy with the >> _EGLContext and the required lookups, but I'd like to take your idea >> one step further and eliminate the lookups and the hash table >> entirely. There is no need to do any lookups, the EGL types are >> defined as void pointers, so we can just cast back to a struct >> _EGLConfig or similar. That they're defined as void * instead of type >> safe opaque structs is beyond me, but I digress. The EGL API is >> defined like this so an implementation doesn't have to use hash >> tables or the like. I don't know why mesa EGL uses a hash table, but >> it's unecessary complexity that we should rather just get rid of. > > I seem to recall that an earlier version of EGL defined EGLContext, > EGLSurface, etc. as ints. But since they're pointers now, we should get rid > of the hash table/lookups. > > I wasn't aware of eagle. It would be great to merge that into Mesa's EGL. Great. Maybe Chia-I Wu can update his patch and I'll start merging the eagle dri2 bits over. cheers, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] EGL driver API overhaul
On Thu, Aug 13, 2009 at 3:01 AM, Chia-I Wu wrote: > Hi all, > > While working on EGL and its drivers, I found that I always have to > perform a lookup to convert an EGL handle (EGLDisplay, EGLContext, etc.) > to its internal data structure (_EGLDisplay, _EGLContext, etc.). After > the lookup, I also have to error check the result and set proper error > code. > > Existing drivers sometime do not check the result, or do not to set the > error code. Even the default implementation in EGL core forgets to do > so here and there. I think it is a sign that lookup and error checking > is better to be done in EGL core, or more specifically, in the EGL API > entry points. Hi, I've been looking at the mesa egl implementation a bit too, with an eye to merge eagle[1] into it. I'm also not happy with the _EGLContext and the required lookups, but I'd like to take your idea one step further and eliminate the lookups and the hash table entirely. There is no need to do any lookups, the EGL types are defined as void pointers, so we can just cast back to a struct _EGLConfig or similar. That they're defined as void * instead of type safe opaque structs is beyond me, but I digress. The EGL API is defined like this so an implementation doesn't have to use hash tables or the like. I don't know why mesa EGL uses a hash table, but it's unecessary complexity that we should rather just get rid of. cheers, Kristian [1] http://hoegsberg.blogspot.com/2009/07/eagle-egl-loader.html -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] intel: glXReleaseTexImageEXT should release reference to storage for the pixmap
2009/6/15 Michel Dänzer : > On Mon, 2009-06-15 at 15:34 +0800, Shuang He wrote: >> According to GLX_EXT_texture_from_pixmap spec, "The storage for the GLX >> pixmap >> will be freed when it is not current to any client and all color buffers that >> are bound to a texture object have been released." > > With this patch, I can easily trigger an assertion failure with compiz > (e.g. by using the scale plugin), see below. (With a driver built > without --enable-debug, this should be a segmentation fault instead due > to de-referencing a NULL pointer). > > Also, I'm not sure why this is necessary - the miptrees should get > released anyway as the texture objects / images are destroyed / > replaced? Yeah, that's why I didn't implement this in the first place. There's no harm in adding a release path though, it potentially lets us free up the pixmap earlier. cheers, Kristian -- 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] [PATCH] intel: Allocate both __DRI_BUFFER_FRONT_LEFT and __DRI_BUFFER_FAKE_FRONT_LEFT
2009/4/3 Michel Dänzer : > On Thu, 2009-04-02 at 16:28 -0400, Kristian Høgsberg wrote: >> >> Ok, yes, glDrawBuffer(GL_FRONT) has to work, but always allocating an >> extra color buffer that most apps won't ever use is not a good use of >> memory. So what about this: for a double buffered visual, the dri >> driver doesn't ask for the front at all, which the loader should >> handle just fine. Then if the app wants to draw to the front buffer, >> it will call getbuffers, but asking for the front buffer and not the >> back buffer, that is, identical to the request it would issue for a >> single buffered visual. And then it just works, since if the drawable >> is a window, we'll ask for the fake front instead and pass that to the >> driver. > > One problem with this is that the server side DRI2GetBuffers() currently > only re-allocates buffers from the driver if the drawable size changes; > it doesn't check if the buffer attachments or even the number of buffers > requested change. Yeah, the server side code may need to reviewed to make sure it allocates any buffers it doesn't already have for the current size. > Even assuming that can be solved, don't we still need both buffers for > things like glCopyPixels with glReadBuffer != glDrawBuffer? Yeah, true. But we'll just ask for both at the time the client sets the front buffer as either draw or read buffer. And it makes the logic more intuitive: if the client ever asks for the front buffer for a window, give it the fake front buffer. The choice to only ask for the back buffer for the normal, double buffered case is then just a dri driver side optimization. cheers, Kristian -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] intel: Allocate both __DRI_BUFFER_FRONT_LEFT and __DRI_BUFFER_FAKE_FRONT_LEFT
On Thu, Apr 2, 2009 at 8:01 PM, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Kristian Høgsberg wrote: > >> Ok, yes, glDrawBuffer(GL_FRONT) has to work, but always allocating an >> extra color buffer that most apps won't ever use is not a good use of >> memory. So what about this: for a double buffered visual, the dri >> driver doesn't ask for the front at all, which the loader should >> handle just fine. Then if the app wants to draw to the front buffer, >> it will call getbuffers, but asking for the front buffer and not the >> back buffer, that is, identical to the request it would issue for a >> single buffered visual. And then it just works, since if the drawable >> is a window, we'll ask for the fake front instead and pass that to the >> driver. It wont be fast, but we're mostly concerned with correctnes >> for front buffer rendering anyway. > > Almost. I believe a legal usage case is to call glXWaitX, then call > glDrawBuffer. Since the glXWaitX happens before the fake front buffer > is created, the fake front buffer will be empty. I guess we could do an > implicit glXWaitX in the loader whenever a GetBuffers call requests a > fake front buffer. Yup, sounds fine. cheers, Kristian -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] intel: Allocate both __DRI_BUFFER_FRONT_LEFT and __DRI_BUFFER_FAKE_FRONT_LEFT
2009/4/2 Ian Romanick :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Kristian Høgsberg wrote:
>> 2009/4/1 Ian Romanick :
>>> This is part of the fix for DRI2 front-buffer rendering.
>>>
>>> Signed-off-by: Ian Romanick
>>> ---
>>> src/mesa/drivers/dri/intel/intel_context.c | 10 --
>>> 1 files changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/intel/intel_context.c
>>> b/src/mesa/drivers/dri/intel/intel_context.c
>>> index 2e76e93..0aa1c18 100644
>>> --- a/src/mesa/drivers/dri/intel/intel_context.c
>>> +++ b/src/mesa/drivers/dri/intel/intel_context.c
>>> @@ -223,8 +223,10 @@ intel_update_renderbuffers(__DRIcontext *context,
>>> __DRIdrawable *drawable)
>>> screen = intel->intelScreen->driScrnPriv;
>>>
>>> i = 0;
>>> - if (intel_fb->color_rb[0])
>>> + if (intel_fb->color_rb[0]) {
>>> + attachments[i++] = __DRI_BUFFER_FAKE_FRONT_LEFT;
>>> attachments[i++] = __DRI_BUFFER_FRONT_LEFT;
>>> + }
>>
>> This will allocate an extra color buffer for double buffered rendering
>> where we don't need it. We need to ask for
>> __DRI_BUFFER_FAKE_FRONT_LEFT and __DRI_BUFFER_FRONT_LEFT when we're
>> single buffered and __DRI_BUFFER_FRONT_LEFT and __DRI_BUFFER_BACK_LEFT
>> when we're double buffered.
>
> So what happens when an application has a double buffered visual but is
> rendering to the front buffer? If I change glxgears to do a
> glDrawBuffer(GL_FRONT) during init and replace the glXSwapBuffers with
> glFlush, it should just work.
>
>>> if (intel_fb->color_rb[1])
>>> attachments[i++] = __DRI_BUFFER_BACK_LEFT;
>>> if (intel_get_renderbuffer(&intel_fb->Base, BUFFER_DEPTH))
>>> @@ -261,8 +263,12 @@ intel_update_renderbuffers(__DRIcontext *context,
>>> __DRIdrawable *drawable)
>>> for (i = 0; i < count; i++) {
>>> switch (buffers[i].attachment) {
>>> case __DRI_BUFFER_FRONT_LEFT:
>>> + rb = NULL;
>>> + break;
>>> +
>>> + case __DRI_BUFFER_FAKE_FRONT_LEFT:
>>> rb = intel_fb->color_rb[0];
>>> - region_name = "dri2 front buffer";
>>> + region_name = "dri2 fake front buffer";
>>> break;
>>
>> color_rb[0] should always correspond to __DRI_BUFFER_FRONT_LEFT so
>> GLX_tfp works. And uhm, I'm just realizing that we don't want the
>> fake front buffer for single buffered rendering to pixmaps (or
>> pbuffers), where we can render directly to the underlying pixmap. So
>> what I'm thinking is that we shouldn't ask for the fake frontbuffer in
>> the dri driver but handle it in the loader. The dri driver doesn't
>> know whether the drawable is a pixmap or a window, so it doesn't know
>> whether it should render the the real front or the fake front.
>>
>> So my suggestion is to handle this in glxdri2c:dri2GetBuffers(). If
>> the driver doesn't ask for a back buffer and we're rendering to a
>> window, ask the server for fake and real front buffers, store the real
>> front buffer data in the loader drawable private and pass the fake
>
> I think we always have to ask for the real and fake front buffers for
> windows. Other than that, those changes sound reasonable.
Ok, yes, glDrawBuffer(GL_FRONT) has to work, but always allocating an
extra color buffer that most apps won't ever use is not a good use of
memory. So what about this: for a double buffered visual, the dri
driver doesn't ask for the front at all, which the loader should
handle just fine. Then if the app wants to draw to the front buffer,
it will call getbuffers, but asking for the front buffer and not the
back buffer, that is, identical to the request it would issue for a
single buffered visual. And then it just works, since if the drawable
is a window, we'll ask for the fake front instead and pass that to the
driver. It wont be fast, but we're mostly concerned with correctnes
for front buffer rendering anyway.
cheers,
Kristian
--
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] DRI2: Provide an interface for drivers to flush front-buffer rendering
2009/4/1 Ian Romanick :
>
> Signed-off-by: Ian Romanick
> ---
> include/GL/internal/dri_interface.h | 15 ++-
> src/glx/x11/dri2_glx.c | 1 +
> 2 files changed, 15 insertions(+), 1 deletions(-)
>
> diff --git a/include/GL/internal/dri_interface.h
> b/include/GL/internal/dri_interface.h
> index 27cc1be..1af090f 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -636,7 +636,7 @@ struct __DRIbufferRec {
> };
>
> #define __DRI_DRI2_LOADER "DRI_DRI2Loader"
> -#define __DRI_DRI2_LOADER_VERSION 1
> +#define __DRI_DRI2_LOADER_VERSION 2
> struct __DRIdri2LoaderExtensionRec {
> __DRIextension base;
>
> @@ -644,6 +644,19 @@ struct __DRIdri2LoaderExtensionRec {
> int *width, int *height,
> unsigned int *attachments, int count,
> int *out_count, void *loaderPrivate);
> +
> + /**
> + * Flush pending front-buffer rendering
> + *
> + * Any rendering that has been performed to the
> + * \c __DRI_BUFFER_FAKE_FRONT_LEFT will be flushed to the
> + * \c __DRI_BUFFER_FRONT_LEFT.
> + *
> + * \param loaderDrawablePrivate Loader's private data that was
> previously
> + * passed into
> + *
> __DRIdri2ExtensionRec::createNewDrawable
> + */
> + void (*flushFrontBuffer)(void *loaderDrawablePrivate);
Looks good, though maybe we should call it markDirty instead. The
flushing will be done by the loader. Please add the __DRIdrawable * as
the first argument like the other dri drawable callbacks.
cheers,
Kristian
--
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] intel: Allocate both __DRI_BUFFER_FRONT_LEFT and __DRI_BUFFER_FAKE_FRONT_LEFT
2009/4/1 Ian Romanick :
> This is part of the fix for DRI2 front-buffer rendering.
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/drivers/dri/intel/intel_context.c | 10 --
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_context.c
> b/src/mesa/drivers/dri/intel/intel_context.c
> index 2e76e93..0aa1c18 100644
> --- a/src/mesa/drivers/dri/intel/intel_context.c
> +++ b/src/mesa/drivers/dri/intel/intel_context.c
> @@ -223,8 +223,10 @@ intel_update_renderbuffers(__DRIcontext *context,
> __DRIdrawable *drawable)
> screen = intel->intelScreen->driScrnPriv;
>
> i = 0;
> - if (intel_fb->color_rb[0])
> + if (intel_fb->color_rb[0]) {
> + attachments[i++] = __DRI_BUFFER_FAKE_FRONT_LEFT;
> attachments[i++] = __DRI_BUFFER_FRONT_LEFT;
> + }
This will allocate an extra color buffer for double buffered rendering
where we don't need it. We need to ask for
__DRI_BUFFER_FAKE_FRONT_LEFT and __DRI_BUFFER_FRONT_LEFT when we're
single buffered and __DRI_BUFFER_FRONT_LEFT and __DRI_BUFFER_BACK_LEFT
when we're double buffered.
> if (intel_fb->color_rb[1])
> attachments[i++] = __DRI_BUFFER_BACK_LEFT;
> if (intel_get_renderbuffer(&intel_fb->Base, BUFFER_DEPTH))
> @@ -261,8 +263,12 @@ intel_update_renderbuffers(__DRIcontext *context,
> __DRIdrawable *drawable)
> for (i = 0; i < count; i++) {
> switch (buffers[i].attachment) {
> case __DRI_BUFFER_FRONT_LEFT:
> + rb = NULL;
> + break;
> +
> + case __DRI_BUFFER_FAKE_FRONT_LEFT:
> rb = intel_fb->color_rb[0];
> - region_name = "dri2 front buffer";
> + region_name = "dri2 fake front buffer";
> break;
color_rb[0] should always correspond to __DRI_BUFFER_FRONT_LEFT so
GLX_tfp works. And uhm, I'm just realizing that we don't want the
fake front buffer for single buffered rendering to pixmaps (or
pbuffers), where we can render directly to the underlying pixmap. So
what I'm thinking is that we shouldn't ask for the fake frontbuffer in
the dri driver but handle it in the loader. The dri driver doesn't
know whether the drawable is a pixmap or a window, so it doesn't know
whether it should render the the real front or the fake front.
So my suggestion is to handle this in glxdri2c:dri2GetBuffers(). If
the driver doesn't ask for a back buffer and we're rendering to a
window, ask the server for fake and real front buffers, store the real
front buffer data in the loader drawable private and pass the fake
front buffer to the driver as the front buffer. In fact, it may make
sense to never pass the real front buffer to the driver except for
pixmaps, which would stop the driver from being able to scribble to
the front buffer.
cheers,
Kristian
--
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] dri glx fixes
On Mon, Mar 30, 2009 at 4:46 AM, Thomas Hellstrom wrote:
> Hi!
>
> Thomas Hellstrom wrote:
>> Hi!
>>
>> I've sent two glx dri patches for review. The first one does some minor
>> optimizations and propagates driver makeCurrent back.
>> The second one is intended to fix the makeContextCurrent(NULL, None,
>> None) call and to do some additional error checking. This was prompted
>> by the newly added sharedtex_mt demo.
>>
>> Most if not all mesa dri drivers are still broken w r t to the above
>> call, as it still does not get through to the driver makeCurrent hook.
>> Instead the correct functionality needs to be implemented in the driver
>> unbindContext hook, similar to the following:
>>
>> GLboolean
>> viaUnbindContext(__DRIcontextPrivate * driContextPriv)
>> {
>> if (driContextPriv) {
>> struct via_context *vmesa =
>> (struct via_context *)driContextPriv->driverPrivate;
>> GLcontext *ctx = vmesa->glCtx;
>>
>> GET_CURRENT_CONTEXT(oldctx);
>> if (ctx == oldctx)
>> VIA_FLUSH_DMA(vmesa);
>>
>> _mesa_make_current(NULL, NULL, NULL);
>> }
>>
>> return GL_TRUE;
>> }
>>
>>
> Actually, the above code doesn't work, as unbindContext is always called
> even if the new context and the old context are the same. Instead,
> contexts need to be refcounted in the driver.
>
> /Thomas
>
>
>> In addition, if the context is changed in the driver makeCurrent hook,
>> the driver needs to flush the old context first. That could
>> theoretically also be done unbindContext, but since unbindContext is
>> called on the old context _after_ makeCurrent, that may not be a good idea.
Do you have a new patch on the way or do you want me to look at the
ones you sent earlier?
cheers,
Kristian
--
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] DRI2 vs. ConfigureNotify events
2009/3/25 Michel Dänzer : > On Tue, 2009-03-24 at 16:31 -0700, Eric Anholt wrote: >> We can work around the cost by suppressing the getbuffers for internal >> glViewport calls (it was the plan before he came up with the clever >> hack). > > I'm not sure that's necessary; the patch I included limits the number of > GetBuffers round-trips to one per frame regardless of where they were > triggered from. Do you or anyone see any problem with this? > > OTOH I think the driver wouldn't need to update the buffers from > MakeCurrent. Do this from the flushExtension instead. Keep the cached flag inside the DRI driver and clear it when the flush entry point is called. That's exactly the semantics you want, and one of the things the flush extension was added for. cheers, Kristian -- 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] [RFC] fixing glxMakeCurrent and DRI.
2009/3/24 Thomas Hellstrom : > Hi! > > It looks like the dri implementation is quite broken for > makeContextCurrent(NULL, None, None). > Drivers expect this to get through to the driver makeCurrent hook to be able > to flush and to notify core mesa. I don't know that it's broken or that drivers expect this - it's never been reported to be an issue before. But it's certainly a behaviour we can change if we need to. > However the current glx code sends this request to the X server only, and > the dri bindContext() hooks can't take NULL as a context argument, because > they use the context argument to get function tables. > > I see two ways of fixing this: > 1) Extend dri_glx::driBindContext to take an extra (__GLXDRIcontextPrivate > *)argument which is never NULL, and similarly extend > dri_util::driBindContext to take an extra (__DRIcontext *) argument to > access the function tables. Can we do this? Any special care that needs to > be taken with extension versioning etc?? I'm not 100% sure, but I think > driBindContext used to let the (NULL, None, None) call through to the driver > MakeCurrent at some point. > > 2) Make sure all drivers implement the following driUnbindContext code: > (driUnbindContext is currently on the old context if any _after_ > driBindContext is called for the new context) > > if (current_context == context_to_unbind) > We call unbind context on the old context when switching to a new context, whether that's NULL or not. Is that not sufficient for the flushing you mention? cheers, Kristian -- 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] DRI2 flush extension
On Thu, Feb 19, 2009 at 8:46 PM, Alan Hourihane wrote:
> Attached is a new DRI2 flush extension that allows the driver to perform
> a "real flush" before dispatching a swap or Xserver copy operation.
>
> Currently we do this before a DRI2CopyRegion() call.
>
> This allows drivers a real "end of scene" flush to ensure rendering is
> complete prior to a swap.
>
> I've committed this already to the gallium-mesa-7.4 branch, but any
> comments appreciated before I push to the master branch?
Hi Alan,
A couple of comments below.
commit b163d4f9ee2ab4d54daf7c17c097cae51c9c6db2
Author: Alan Hourihane
Date: Thu Feb 19 18:39:08 2009 +
glx: add support for a reallyFlush() function before swap occurs.
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 27cc1be..a726b93 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -78,6 +78,7 @@ typedef struct __DRIswrastExtensionRec
__DRIswrastExtension;
typedef struct __DRIbufferRec __DRIbuffer;
typedef struct __DRIdri2ExtensionRec __DRIdri2Extension;
typedef struct __DRIdri2LoaderExtensionRec __DRIdri2LoaderExtension;
+typedef struct __DRI2flushExtensionRec __DRI2flushExtension;
/*...@}*/
@@ -245,6 +246,16 @@ struct __DRItexBufferExtensionRec {
__DRIdrawable *pDraw);
};
+/**
+ * Used by drivers that implement DRI2
+ */
+#define __DRI2_FLUSH "DRI2_Flush"
+#define __DRI2_FLUSH_VERSION 1
+struct __DRI2flushExtensionRec {
+__DRIextension base;
+void (*flush)(__DRIdrawable *drawable);
+};
+
/**
* XML document describing the configuration options supported by the
diff --git a/src/glx/x11/dri2_glx.c b/src/glx/x11/dri2_glx.c
index 639aa19..fdda852 100644
--- a/src/glx/x11/dri2_glx.c
+++ b/src/glx/x11/dri2_glx.c
@@ -207,7 +207,13 @@ static void dri2CopySubBuffer(__GLXDRIdrawable *pdraw,
xrect.width = width;
xrect.height = height;
+#ifdef __DRI2_FLUSH
+if (pdraw->psc->f)
+ (*pdraw->psc->f->flush)(pdraw->driDrawable);
+#endif
+
region = XFixesCreateRegion(pdraw->psc->dpy, &xrect, 1);
+/* should get a fence ID back from here at some point */
DRI2CopyRegion(pdraw->psc->dpy, pdraw->drawable, region,
DRI2BufferFrontLeft, DRI2BufferBackLeft);
XFixesDestroyRegion(pdraw->psc->dpy, region);
@@ -235,6 +241,11 @@ static void dri2WaitX(__GLXDRIdrawable *pdraw)
xrect.width = priv->width;
xrect.height = priv->height;
+#ifdef __DRI2_FLUSH
+if (pdraw->psc->f)
+ (*pdraw->psc->f->flush)(pdraw->driDrawable);
+#endif
+
This flush call isn't necessary - glXWaitX() is called to wait for X
rendering to the drawable to finish so there can't be any unflushed
DRI driver activity.
region = XFixesCreateRegion(pdraw->psc->dpy, &xrect, 1);
DRI2CopyRegion(pdraw->psc->dpy, pdraw->drawable, region,
DRI2BufferFakeFrontLeft, DRI2BufferFrontLeft);
@@ -255,6 +266,11 @@ static void dri2WaitGL(__GLXDRIdrawable *pdraw)
xrect.width = priv->width;
xrect.height = priv->height;
+#ifdef __DRI2_FLUSH
+if (pdraw->psc->f)
+ (*pdraw->psc->f->flush)(pdraw->driDrawable);
+#endif
+
region = XFixesCreateRegion(pdraw->psc->dpy, &xrect, 1);
DRI2CopyRegion(pdraw->psc->dpy, pdraw->drawable, region,
DRI2BufferFrontLeft, DRI2BufferFakeFrontLeft);
diff --git a/src/glx/x11/dri_common.c b/src/glx/x11/dri_common.c
index 4fda649..90c3d8c 100644
--- a/src/glx/x11/dri_common.c
+++ b/src/glx/x11/dri_common.c
@@ -392,6 +392,13 @@ driBindExtensions(__GLXscreenConfigs *psc, int dri2)
}
#endif
+#ifdef __DRI2_FLUSH
+ if ((strcmp(extensions[i]->name, __DRI2_FLUSH) == 0) && dri2) {
+ psc->f = (__DRI2flushExtension *) extensions[i];
+ /* internal driver extension, no GL extension exposed */
+ }
+#endif
The driver needs to know whether the loader is new enough that it
supports the flush extension so that it can enable the lazy glFlush()
optiomization. An older loader will just ignore the flush extension
and thus never call that entry point, in which case the driver must
flush on every glFlush() call. The only way to do this I can think of
right now is to add an 'enable()' entrypoint to the extension to tell
the driver that the loader will call ->flush() and it's ok to ignore
glFlush().
/* Ignore unknown extensions */
}
}
diff --git a/src/glx/x11/glxclient.h b/src/glx/x11/glxclient.h
index 3e70759..caf58bb 100644
--- a/src/glx/x11/glxclient.h
+++ b/src/glx/x11/glxclient.h
@@ -519,6 +519,10 @@ struct __GLXscreenConfigsRec {
const __DRItexBufferExtension *texBuffer;
#endif
+#ifdef __DRI2_FLUSH
+const __DRI2flushExtension *f;
+#endif
+
#endif
/**
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open so
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson wrote: > On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul wrote: >> >> In terms of the build system, we'll initially default to the non-gallium >> build. To build with gallium I'll add some new configs like >> 'linux-gallium'. > > I haven't tried building gallium at all, but is there interest in > adding support to the autoconf goo? I don't know how well it would fit > in with the current semantics (--enable-driver=...), but I could take > a look. I would definitely appreciate that. thanks, Kristian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] intel: Expose more FBconfigs in the 3D driver.
On Thu, Feb 5, 2009 at 4:46 PM, Peter Clifton wrote: > On Fri, 2009-01-30 at 11:51 -0500, Kristian Høgsberg wrote: >> On Thu, Jan 29, 2009 at 6:08 PM, Eric Anholt wrote: >> > We can support any combination of (a8r8g8b8, x8r8g8b8, r5g6b5) x >> > (z0,z24,z24s8) >> > on either class of chipsets. The only restriction is no mixing bpp when >> > also >> > mixing tiling. This shouldn't be occurring currently. >> >> Cool, that should fix it. Or at least let the compositing managers >> pick the right fbconfig. We should probably fix all drivers to report >> RGB visuals, and then we can yank the reset-alpha-channel hack in the >> tfp sw fallback. > > It doesn't fix it on its own.. certainly not for the intel driver. > > The setTexBuffer hook still explicitly sets the format of the texture to > be BGRA, and I assume it ought to be setting this information based on > the FBconfig (now hopefully correct) of the GLXPixmap the texture is > being mapped from. > > Does anyone have any hints how start fixing that? Something like the attached patch? Haven't tested it... cheers, Kristian tex-buffer-no-alpha.patch Description: application/mbox -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Trivial correction to intel_decode.c
On Wed, Feb 4, 2009 at 4:08 PM, Chris Wilson wrote: > Continuing the theme, this patch corrects the length mask for the > various MI opcodes. Committed, thanks, Kristian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] intel: Expose more FBconfigs in the 3D driver.
On Thu, Jan 29, 2009 at 6:08 PM, Eric Anholt wrote:
> We can support any combination of (a8r8g8b8, x8r8g8b8, r5g6b5) x
> (z0,z24,z24s8)
> on either class of chipsets. The only restriction is no mixing bpp when also
> mixing tiling. This shouldn't be occurring currently.
Cool, that should fix it. Or at least let the compositing managers
pick the right fbconfig. We should probably fix all drivers to report
RGB visuals, and then we can yank the reset-alpha-channel hack in the
tfp sw fallback.
Acked-by: Kristian Høgsberg
Thanks¸
Kristian
> ---
> src/mesa/drivers/dri/common/utils.c |3 +-
> src/mesa/drivers/dri/common/utils.h |3 +-
> src/mesa/drivers/dri/intel/intel_screen.c | 54 +++-
> src/mesa/drivers/dri/swrast/swrast.c |8 ++--
> 4 files changed, 60 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/common/utils.c
> b/src/mesa/drivers/dri/common/utils.c
> index 30c860b..10f7db8 100644
> --- a/src/mesa/drivers/dri/common/utils.c
> +++ b/src/mesa/drivers/dri/common/utils.c
> @@ -734,7 +734,8 @@ driCreateConfigs(GLenum fb_format, GLenum fb_type,
> return configs;
> }
>
> -const __DRIconfig **driConcatConfigs(__DRIconfig **a, __DRIconfig **b)
> +const __DRIconfig **driConcatConfigs(const __DRIconfig **a,
> +const __DRIconfig **b)
> {
> const __DRIconfig **all;
> int i, j, index;
> diff --git a/src/mesa/drivers/dri/common/utils.h
> b/src/mesa/drivers/dri/common/utils.h
> index 0c974db..b0908e5 100644
> --- a/src/mesa/drivers/dri/common/utils.h
> +++ b/src/mesa/drivers/dri/common/utils.h
> @@ -133,7 +133,8 @@ driCreateConfigs(GLenum fb_format, GLenum fb_type,
> unsigned num_depth_stencil_bits,
> const GLenum * db_modes, unsigned num_db_modes);
>
> -const __DRIconfig **driConcatConfigs(__DRIconfig **a, __DRIconfig **b);
> +const __DRIconfig **driConcatConfigs(const __DRIconfig **a,
> +const __DRIconfig **b);
>
> int
> driGetConfigAttrib(const __DRIconfig *config,
> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
> b/src/mesa/drivers/dri/intel/intel_screen.c
> index fe890c3..aad53fb 100644
> --- a/src/mesa/drivers/dri/intel/intel_screen.c
> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
> @@ -671,6 +671,17 @@ static const
> __DRIconfig **intelInitScreen2(__DRIscreenPrivate *psp)
> {
>intelScreenPrivate *intelScreen;
> + GLenum fb_format[3];
> + GLenum fb_type[3];
> + /* GLX_SWAP_COPY_OML is only supported because the Intel driver doesn't
> +* support pageflipping at all.
> +*/
> + static const GLenum back_buffer_modes[] = {
> + GLX_NONE, GLX_SWAP_UNDEFINED_OML, GLX_SWAP_COPY_OML
> + };
> + uint8_t depth_bits[4], stencil_bits[4];
> + int color;
> + const __DRIconfig **configs = NULL;
>
>/* Calling driInitExtensions here, with a NULL context pointer,
> * does not actually enable the extensions. It just makes sure
> @@ -710,8 +721,47 @@ __DRIconfig **intelInitScreen2(__DRIscreenPrivate *psp)
>intelScreen->irq_active = 1;
>psp->extensions = intelScreenExtensions;
>
> - return driConcatConfigs(intelFillInModes(psp, 16, 16, 0, 1),
> - intelFillInModes(psp, 32, 24, 8, 1));
> + depth_bits[0] = 0;
> + stencil_bits[0] = 0;
> + depth_bits[1] = 16;
> + stencil_bits[1] = 0;
> + depth_bits[2] = 24;
> + stencil_bits[2] = 0;
> + depth_bits[3] = 24;
> + stencil_bits[3] = 8;
> +
> + fb_format[0] = GL_RGB;
> + fb_type[0] = GL_UNSIGNED_SHORT_5_6_5;
> +
> + fb_format[1] = GL_RGB;
> + fb_type[1] = GL_UNSIGNED_INT_8_8_8_8_REV;
> +
> + fb_format[2] = GL_RGBA;
> + fb_type[2] = GL_UNSIGNED_INT_8_8_8_8_REV;
> +
> + for (color = 0; color < ARRAY_SIZE(fb_format); color++) {
> + const __DRIconfig **new_configs;
> +
> + new_configs = (const __DRIconfig **)
> +driCreateConfigs(fb_format[color], fb_type[color],
> + depth_bits,
> + stencil_bits,
> + ARRAY_SIZE(depth_bits),
> + back_buffer_modes,
> + ARRAY_SIZE(back_buffer_modes));
> + if (configs == NULL)
> +configs = new_configs;
> + else
> +configs = driConcatConfigs(configs, new_configs);
> + }
> +
> + if (configs == NULL) {
> + fprintf(stderr, "[%s:%u] Error creating FBConfig!\n", __func__,
> + __LINE__);
> + return NULL;
> + }
> +
> + return configs;
> }
>
> const struct __DriverAPIRec driDriverAPI = {
> diff
Re: [Mesa3d-dev] Texture from pixmap backed with 24 bit depth, DRI2 problems
On Thu, 2009-01-22 at 19:52 +, Peter Clifton wrote: > Hi, > > I've been looking into some texturing problems in compiz, seen when > compiz attempts to make a 24 bit depth window transparent. Once it wants > to make a window transparent, compiz's painting path switches on various > texture operations which are affected by a corrupt alpha channel in the > texture obtained using the texture from pixmap extension. (When backed > by a 24 bit pixmap). > > I've gone round and round trying to figure out the right way this ought > to be fixed, but I think we're missing some information. > > The GLXPixmap created to texture from seems to be lacking information > about the proper structure and depth of the underlying pixmap data. > Since the texture can be bound from a direct GLX rendering context, > there are two code-paths which call setTexBuffer, one in the GLX direct > rendering path, and another in the GLX routines of the X server. > > One could imagine using a hack like setTexOffset in the X server > code-path, since we're more able to grab at the underlying data, but > actually.. if setTexBuffer had the right information, we wouldn't need > to do that. Pixmaps don't associate a visual in the same way a Window does. Typically you'll know what kind of contents it has from the context; if it's a Pixmap backing a redirected Window, the Window's visual will tell you, if you rendered something to the Pixmap yourself, you know what visual to use. So in the case of compiz, you'll have to look at the visual for the redirected Window to know whether or not the Pixmap has an alpha channel. There may be a problem in that all the fbconfigs provided by the DRI driver advertise an 8 bit alpha channel and thus you can't pick an fbconfig when creating the GLXPixmap that correctly advertises the lack of an alpha channel. Can you just turn off GL_BLEND? Hmm, I guess I'm not sure what the problem is ;) cheers, Kristian -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] some client side GLX functionality xcbified
On Tue, Nov 4, 2008 at 12:05 PM, RALOVICH, Kristóf <[EMAIL PROTECTED]> wrote: > Hi, > > these patches are against mesa/master. > > The code paths were compile and run tested. Running glxgears with Mesa > built with --enable-xcb yields some 5% speedup when indirect rendering > (~1FPS -> ~10500FPS), however this is mostly meaningless. > > Comments are welcome! Sounds interesting - do you have a branch somewhere I can pull or can you send the patches inline so they're easier to review? thanks, Kristian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] EGL in Mesa
On Mon, Oct 6, 2008 at 1:09 PM, Brian Paul <[EMAIL PROTECTED]> wrote: > KwangYul Seo wrote: >> Hi, >> >> I want to know the current status of EGL in Mesa. Mesa in the git >> repository seems to have src/egl, but I can't find it in the stable >> releases of Mesa. Is this EGL implementation usable? > > Software rendering should work on the gallium-0.1/2 branches. Hardware > rendering may or may not work. It's in flux. That's why it's not > included in the Mesa releases yet. I'm jumping the gun here, but I've been working on an EGL implementation that works with the new standard DRI interface. It only works with intel dri driver and requires gem and modesetting, but I've got EGL gears running at this point: http://people.freedesktop.org/~krh/eglgears.png The code is here for now: git://people.freedesktop.org/~krh/eagle cheers, Kristian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Problem with commit acae6f06 "dri: fix crash in driGetConfigAttribIndex"
On Tue, 2008-08-26 at 14:19 -0600, Brian Paul wrote: > Kristian Høgsberg wrote: > > On Tue, 2008-08-26 at 12:43 +0100, Dave Airlie wrote: > >>> the following commit > >>> > >>> 1724334d7c82abe55b6506dfe369df4facae6f06 > >>> > >>> dri: fix crash in driGetConfigAttribIndex > >>> > >>> Accessing a GLboolean via an int pointer on big-endian == bad. > >>> > >>> breaks 3D stuff on my radeon r5xx card: GLX no longer reports visuals with > >>> double buffering. I've attached the different outputs from glxinfo: > >> I'm going to back this out, but it would be nice to fix properly, krh any > >> ideas? > > > > Hmm, not sure why DaveM's patch would break that for you, but I've just > > committed a different fix. We never sent the floatMode attribute over > > the wire anyway so I just took it out. If it's still broken, something > > else must be wrong on your side - let me know. > > > This issue doesn't depend on anything on the client side, right? > > I'm planning on releasing Mesa 7.1 in the next hour or two and just want > to be sure this issue isn't a dependency. I checked the mesa side of things when committing this and there shouldn't be anything there that needs fixing. thanks, Kristian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Problem with commit acae6f06 "dri: fix crash in driGetConfigAttribIndex"
On Tue, 2008-08-26 at 12:43 +0100, Dave Airlie wrote: > > the following commit > > > > 1724334d7c82abe55b6506dfe369df4facae6f06 > > > > dri: fix crash in driGetConfigAttribIndex > > > > Accessing a GLboolean via an int pointer on big-endian == bad. > > > > breaks 3D stuff on my radeon r5xx card: GLX no longer reports visuals with > > double buffering. I've attached the different outputs from glxinfo: > > I'm going to back this out, but it would be nice to fix properly, krh any > ideas? Hmm, not sure why DaveM's patch would break that for you, but I've just committed a different fix. We never sent the floatMode attribute over the wire anyway so I just took it out. If it's still broken, something else must be wrong on your side - let me know. thanks Kristian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] DRI-specific pkg-config file
On Fri, Jun 27, 2008 at 9:31 AM, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> Anyone have any problems with this?
I saw you already added this, but just wanted to say it looks good to me.
thanks,
Kristian
> On Thu, Jun 12, 2008 at 7:12 AM, Dan Nicholson <[EMAIL PROTECTED]> wrote:
>> Since the gl pkg-config file doesn't convey any specifics about the
>> backend in use, this adds a new pkg-config file for when DRI is in use.
>> This can be used by the xserver build to determine if the DRI extension
>> is appropriate.
>> ---
>> Dan
>>
>> I don't know if this makes anything a lot better, but I think it at
>> least helps differentiates the case of "user has non-DRI-GL". With it
>> we can change the xserver DRI check:
>>
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -880,7 +880,7 @@ if test "x$DRI" = xyes; then
>> AC_DEFINE(XF86DRI, 1, [Build DRI extension])
>> PKG_CHECK_MODULES([DRIPROTO], [xf86driproto])
>> PKG_CHECK_MODULES([LIBDRM], [libdrm >= 2.3.0])
>> - PKG_CHECK_MODULES([GL], [glproto >= 1.4.1 gl >= 7.1.0])
>> + PKG_CHECK_MODULES([GL], [glproto >= 1.4.1 dri >= 7.1.0])
>> PKG_CHECK_EXISTS(libdrm >= 2.2.0,
>> [AC_DEFINE([HAVE_LIBDRM_2_2], 1,
>> [Has version 2.2 (or newer) of the drm library])])
>>
>> It could also be used so that the xserver can sync with mesa on where
>> the DRI drivers are really installed:
>>
>> dridriverdir=`pkg-config --variable=dridriverdir dri`
>>
>> Makefile |1 +
>> src/mesa/drivers/dri/Makefile | 13 -
>> src/mesa/drivers/dri/dri.pc.in | 10 ++
>> 3 files changed, 23 insertions(+), 1 deletions(-)
>> create mode 100644 src/mesa/drivers/dri/dri.pc.in
>>
>> diff --git a/Makefile b/Makefile
>> index 0fa309b..21cf0b5 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -317,6 +317,7 @@ DRI_FILES = \
>>$(DIRECTORY)/src/glx/x11/*.[ch] \
>>$(DIRECTORY)/src/mesa/drivers/dri/Makefile \
>>$(DIRECTORY)/src/mesa/drivers/dri/Makefile.template \
>> + $(DIRECTORY)/src/mesa/drivers/dri/dri.pc.in \
>>$(DIRECTORY)/src/mesa/drivers/dri/common/xmlpool/*.[ch] \
>>$(DIRECTORY)/src/mesa/drivers/dri/common/xmlpool/*.po \
>>$(DIRECTORY)/src/mesa/drivers/dri/*/*.[chS] \
>> diff --git a/src/mesa/drivers/dri/Makefile b/src/mesa/drivers/dri/Makefile
>> index 41dfc67..3f87782 100644
>> --- a/src/mesa/drivers/dri/Makefile
>> +++ b/src/mesa/drivers/dri/Makefile
>> @@ -20,8 +20,17 @@ subdirs:
>>fi \
>>done
>>
>> +pcedit = sed \
>> + -e 's,@INSTALL_DIR@,$(INSTALL_DIR),' \
>> + -e 's,@LIB_DIR@,$(LIB_DIR),' \
>> + -e 's,@VERSION@,$(MESA_MAJOR).$(MESA_MINOR).$(MESA_TINY),' \
>> + -e 's,@DRI_DRIVER_DIR@,$(DRI_DRIVER_SEARCH_DIR),'
>>
>> -install:
>> +dri.pc: dri.pc.in
>> + $(pcedit) $< > $@
>> +
>> +
>> +install: dri.pc
>>@for dir in $(DRI_DIRS) ; do \
>>if [ -d $$dir ] ; then \
>>(cd $$dir && $(MAKE) install) || exit 1 ; \
>> @@ -30,6 +39,8 @@ install:
>>$(INSTALL) -d $(DESTDIR)$(INSTALL_DIR)/include/GL/internal
>>$(INSTALL) -m 0644 $(TOP)/include/GL/internal/dri_interface.h
>> $(DESTDIR)$(INSTALL_DIR)/include/GL/internal
>>$(INSTALL) -m 0644 $(TOP)/include/GL/internal/dri_sarea.h
>> $(DESTDIR)$(INSTALL_DIR)/include/GL/internal
>> + $(INSTALL) -d $(DESTDIR)$(INSTALL_DIR)/$(LIB_DIR)/pkgconfig
>> + $(INSTALL) -m 0644 dri.pc
>> $(DESTDIR)$(INSTALL_DIR)/$(LIB_DIR)/pkgconfig
>>
>>
>> clean:
>> diff --git a/src/mesa/drivers/dri/dri.pc.in b/src/mesa/drivers/dri/dri.pc.in
>> new file mode 100644
>> index 000..58d890d
>> --- /dev/null
>> +++ b/src/mesa/drivers/dri/dri.pc.in
>> @@ -0,0 +1,10 @@
>> [EMAIL PROTECTED]@
>> +exec_prefix=${prefix}
>> +libdir=${exec_prefix}/@LIB_DIR@
>> +includedir=${prefix}/include
>> [EMAIL PROTECTED]@
>> +
>> +Name: dri
>> +Description: Direct Rendering Infrastructure
>> +Version: @VERSION@
>> +Cflags: -I${includedir}
>> --
>> 1.5.3.2
>>
>> -
>> 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
>>
>
> -
> 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.sourcef
Re: [Mesa3d-dev] drixorg: software renderer with dri_interface.h
On Tue, May 13, 2008 at 9:38 PM, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > On Tue, May 13, 2008 at 5:04 AM, George - <[EMAIL PROTECTED]> wrote: >> >> > Date: Mon, 12 May 2008 12:25:26 -0400 >> > From: [EMAIL PROTECTED] >> > To: [EMAIL PROTECTED] >> > Subject: Re: [Mesa3d-dev] drixorg: software renderer with dri_interface.h >> > CC: mesa3d-dev@lists.sourceforge.net >> >> > >> > Wow, that's awesome work. My initial plan was to just wrap a dri >> > interface around the XMesa driver, but this is much better. You drop >> > the XMesa middle man and use the mesa internal API directly, which >> > avoids hooking into the X server internals from XMesa. This also >> > makes it much easier to load the sw dri driver from libGL. A few >> > comments on the patches: >> > >> > 1. Can we call it swdri instead of drixorg? There's nothing xorg >> > specific about it and the hw dri drivers also work with xorg. In >> > fact, this makes it easy to load the sw driver from a non-X loader >> > (say, EGL). >> > >> >> that is: >> drivers/dri/xorg -> drivers/dri/sw >> xorg_dri.so -> sw_dri.so >> glxdrixorg.c -> glxdrisw.c >> >> right ? > > I think what Keith suggested makes sense, so let's say > > drivers/dri/xorg -> drivers/dri/swrast > xorg_dri.so -> swrast_dri.so > glxdrixorg.c -> glxdriswrast.c > >> otherwise, we'll either have dri twice in the name (swdri_dri.so) or sw dri >> will not follow the hw dri naming conventions (swdri.so). >> >> I'll repost the patches and use the suggested names right from the >> beginning. >> >> >> > 2. Create the __DRIconfigs in the drixorg driver and share the >> > __DRIconfig conversion code in glxdri2.c in the xserver (and libGL). >> > That's what the hw drivers do, because they know exactly what >> > fbconfigs they can support. That's also true for the sw dri driver. >> > >> > 3. Just add a __DRISWExtension, along the lines of >> > __DRIlegacyExtension instead of reusing the >> > createScreen/createDrawable and createContext entry points from >> > __DRIcoreExtension. This lets you pass in exactly the parameters >> > required, and only those (instead of ignoring the unused fd and sarea >> > handle). >> > >> > 4. Add a resizeDrawable entry point to the __DRISWExtension interface >> > to be called when __glXDRIdrawableResize is called from the glx >> > module. Not sure how to handle this when you load the sw dri driver >> > on the client side, but you probably don't want to do that anyway... >> > >> >> ok! will do after reposting the patches, unless someone wants to help :-) > > I'm taking the next couple of days off, so I'll leave it to you :) If > the changes above work out alright, feel free to commit the patches. Ok, I'm back and working on implementing these suggestions so we can get it upstream. Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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
Re: [Mesa3d-dev] drixorg: software renderer with dri_interface.h
On Tue, May 13, 2008 at 5:04 AM, George - <[EMAIL PROTECTED]> wrote: > > > Date: Mon, 12 May 2008 12:25:26 -0400 > > From: [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > > Subject: Re: [Mesa3d-dev] drixorg: software renderer with dri_interface.h > > CC: mesa3d-dev@lists.sourceforge.net > > > > > Wow, that's awesome work. My initial plan was to just wrap a dri > > interface around the XMesa driver, but this is much better. You drop > > the XMesa middle man and use the mesa internal API directly, which > > avoids hooking into the X server internals from XMesa. This also > > makes it much easier to load the sw dri driver from libGL. A few > > comments on the patches: > > > > 1. Can we call it swdri instead of drixorg? There's nothing xorg > > specific about it and the hw dri drivers also work with xorg. In > > fact, this makes it easy to load the sw driver from a non-X loader > > (say, EGL). > > > > that is: > drivers/dri/xorg -> drivers/dri/sw > xorg_dri.so -> sw_dri.so > glxdrixorg.c -> glxdrisw.c > > right ? I think what Keith suggested makes sense, so let's say drivers/dri/xorg -> drivers/dri/swrast xorg_dri.so -> swrast_dri.so glxdrixorg.c -> glxdriswrast.c > otherwise, we'll either have dri twice in the name (swdri_dri.so) or sw dri > will not follow the hw dri naming conventions (swdri.so). > > I'll repost the patches and use the suggested names right from the > beginning. > > > > 2. Create the __DRIconfigs in the drixorg driver and share the > > __DRIconfig conversion code in glxdri2.c in the xserver (and libGL). > > That's what the hw drivers do, because they know exactly what > > fbconfigs they can support. That's also true for the sw dri driver. > > > > 3. Just add a __DRISWExtension, along the lines of > > __DRIlegacyExtension instead of reusing the > > createScreen/createDrawable and createContext entry points from > > __DRIcoreExtension. This lets you pass in exactly the parameters > > required, and only those (instead of ignoring the unused fd and sarea > > handle). > > > > 4. Add a resizeDrawable entry point to the __DRISWExtension interface > > to be called when __glXDRIdrawableResize is called from the glx > > module. Not sure how to handle this when you load the sw dri driver > > on the client side, but you probably don't want to do that anyway... > > > > ok! will do after reposting the patches, unless someone wants to help :-) I'm taking the next couple of days off, so I'll leave it to you :) If the changes above work out alright, feel free to commit the patches. thanks, Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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
Re: [Mesa3d-dev] drixorg: software renderer with dri_interface.h
On Tue, May 13, 2008 at 5:21 AM, Keith Whitwell <[EMAIL PROTECTED]> wrote: > > George, > > How about a slight tweak to Kristian's request -- would it be possible to > use "swrast" instead of just "sw"? > > This is the mesa swrast module packaged into a dri driver structure, and > maintaining that name helps keep this clear. I guess also using swrast > differentiates this slightly from swtnl or sw-something-else... I like that better and swrast_dri.so avoids the double dri in swdri_dri.so. Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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
Re: [Mesa3d-dev] drixorg: software renderer with dri_interface.h
On Sun, May 11, 2008 at 8:00 AM, George - <[EMAIL PROTECTED]> wrote: > > Hi, > > I did some cleanups and fixes and pushed the patches to: > > http://cgit.freedesktop.org/~gsap7/xserver/?h=drixorg > http://cgit.freedesktop.org/~gsap7/mesa/?h=drixorg > > I finally put the driver in drivers/dri/xorg. Note, however, that drixorg > implements the __DRIcoreExtension interface (as in drivers/dri/common), not > the > internal __DriverAPI interface ... > > I also documented some bugs I found by testing with some mesa demos > (see top of xorg.c), those happen in master also. > > The only stuff blocking merging should the configs extension and maybe > depth 8. Wow, that's awesome work. My initial plan was to just wrap a dri interface around the XMesa driver, but this is much better. You drop the XMesa middle man and use the mesa internal API directly, which avoids hooking into the X server internals from XMesa. This also makes it much easier to load the sw dri driver from libGL. A few comments on the patches: 1. Can we call it swdri instead of drixorg? There's nothing xorg specific about it and the hw dri drivers also work with xorg. In fact, this makes it easy to load the sw driver from a non-X loader (say, EGL). 2. Create the __DRIconfigs in the drixorg driver and share the __DRIconfig conversion code in glxdri2.c in the xserver (and libGL). That's what the hw drivers do, because they know exactly what fbconfigs they can support. That's also true for the sw dri driver. 3. Just add a __DRISWExtension, along the lines of __DRIlegacyExtension instead of reusing the createScreen/createDrawable and createContext entry points from __DRIcoreExtension. This lets you pass in exactly the parameters required, and only those (instead of ignoring the unused fd and sarea handle). 4. Add a resizeDrawable entry point to the __DRISWExtension interface to be called when __glXDRIdrawableResize is called from the glx module. Not sure how to handle this when you load the sw dri driver on the client side, but you probably don't want to do that anyway... 5. Add yourself as copyright holder on the files you've authored :) cheers, Kristian - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] regression: Initialize GLX_EXT_texture_from_pixmap attributes correctly.
On Thu, 2008-04-03 at 21:52 +0200, Markus Amsler wrote: > commit dc836edf49a08a7fd77fc1f127818b0550558581 > Author: Kristian Høgsberg <[EMAIL PROTECTED]> > Date: Wed Apr 2 19:04:57 2008 -0400 > > Initialize GLX_EXT_texture_from_pixmap attributes correctly. > > After this commit I get with glxinfo: > Error: couldn't find RGB GLX visual > > Any other opengl app gives a similar error message. Did you also update the X server? The bug was that the X server didn't send these attributes and so the client had to make up some stuff. The git xserver sends these values now and the client just goes with what the server sends it. Now, of course, libGL shouldn't fail to initialize any visuals if the server doesn't send the exact set of attributes the client wants. I'll take a look at that issue but try the git xserver in the meantime. cheers, Kristian - 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] Mesa crashing after exiting WoW, with a bad drawable
On Wed, Mar 26, 2008 at 1:00 PM, Chris Rankin <[EMAIL PROTECTED]> wrote:
> --- Markus Amsler <[EMAIL PROTECTED]> wrote:
> > No problem here. But I think I've seen this error before. Perhaps it's
> > an drm/mesa setup issue.
>
> Here is the useful part of the backtrace, when a drawable 0x71 first
> appears. The crash itself
> doesn't happen until the context is destroyed again (I think).
>
> 3 0x7e92d3ee filter_modes(server_modes=,
> driver_modes=)
> [/home/chris/Programs/mesa/src/glx/x11/dri_glx.c:301] in libgl.so.1
> (0x0034fa18)
> 4 0x7dce6ae1 __driUtilUpdateDrawableInfo+0x107(pdp=0x7c0d9a50)
>
> [/home/chris/Programs/mesa/src/mesa/drivers/dri/mach64/../common/dri_util.c:266]
> in r300_dri.so
> (0x0034fa78)
> 5 0x7dce750b driBindContext+0xd2(ctx=0x7c047b3c, pdraw=0x7c08b9a4,
> pread=0x7c08b9a4)
>
> [/home/chris/Programs/mesa/src/mesa/drivers/dri/mach64/../common/dri_util.c:204]
> in r300_dri.so
> (0x0034faa8)
> 6 0x7e92cd26 driBindContext+0x26(context=0x7c047b30, draw=0x7c08b998,
> read=0x7c08b998)
> [/home/chris/Programs/mesa/src/glx/x11/dri_glx.c:689] in libgl.so.1
> (0x0034fac8)
> 7 0x7e90fd67 MakeContextCurrent+0xc5(dpy=0x7c030590, draw=0x71, read=0x71,
> gc=0x7c0576f0)
> [/home/chris/Programs/mesa/src/glx/x11/glxext.c:1251] in libgl.so.1
> (0x0034fb38)
> 8 0x7e90fffa glXMakeCurrent+0x23(dpy=0x7c030590, draw=0x71, gc=0x7c0576f0)
> [/home/chris/Programs/mesa/src/glx/x11/glxext.c:1372] in libgl.so.1
> (0x0034fb58)
> 9 0x7e090401 has_opengl+0x721()
> [/home/chris/Programs/wine/dlls/winex11.drv/opengl.c:324] in
> winex11 (0x0034fbd8)
>
> What Wine is doing here is checking for OpenGL support:
>
> if (ctx) {
> pglXMakeCurrent(gdi_display, win, ctx); // <<< HERE
> } else {
> ERR(" couldn't initialize OpenGL, expect problems\n");
> wine_tsx11_unlock();
> return FALSE;
> }
>
> And 0x71 is presumably the value of "win". Does this seem reasonable, please?
Wine is passing it to GLX in the call to glXMakeCurrent(). It's just
an X ID, so 0x71 could certainly be a valid value... does wine use
glXCreateWindow()?
Kristian
-
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] [PATCH] Segfaults caused by DRI failing to initialize properly.
On Tue, Mar 11, 2008 at 11:32 PM, Chris Taylor <[EMAIL PROTECTED]> wrote: > I believe that the following patch should be added in addition to the > changes that Kristian Høgsberg <[EMAIL PROTECTED]> made in commit > 3731159ec6e1527655d91b3eb364d5c2d252ac60. > > This patch fixes another segfault caused when DRI fails to initialize > properly. Yup, fix is pushed, thanks. Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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
Re: [Mesa3d-dev] 47d563006de646b039c456ffc8379ca8ded3d5a5 breaks Xlib GL
On Mon, Mar 10, 2008 at 4:22 PM, Dan Nicholson <[EMAIL PROTECTED]> wrote: > > On Mon, Mar 10, 2008 at 2:15 PM, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > > > > On Mon, Mar 10, 2008 at 2:32 PM, Dan Nicholson <[EMAIL PROTECTED]> wrote: > > > Kristian, > > > > > > Unfortunately, moving the libGL install target to src/glx breaks all > > > the non-glx targets since libGL will never be installed in those > > > cases. Is there a particular problem you were trying to solve with > > > that? > > > > I don't it's unreasonable to expect make install in a directory such > > as src/glx/x11 to install the library built in there. That's what I > > was trying to fix. I guess there's nothing wrong in also installing > > libGL from src/mesa/Makefile as well, if something relies on that > > behavior. > > I fully agree, but the problem is that libGL is created in src/mesa in > all cases _except_ GLX. In that case, it jumps out to src/glx/x11 for > the build. You can try to make sense of src/mesa/Makefile, but it > ain't pretty. :) One way to make this "nicer" would be to split up the > install target in src/mesa/Makefile so that it logically follows the > build. I did just that. The subtargets (install-libgl, install-osmesa and install-drivers) don't have the right dependencies, to make install-libgl doesn't actually depend on libgl being built. So they're "internal-use" makefile targets, for now at least. > Also, if you move files around, check the file list in the top-level > Makefile that is used for "make tarballs". The equivalent "make dist" > for Mesa (Brian probably does this different, but this is how I got it > to work) is: Yeah, good point. I moved gl.pc.in back to src/mesa though. cheers, Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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
Re: [Mesa3d-dev] 47d563006de646b039c456ffc8379ca8ded3d5a5 breaks Xlib GL
On Mon, Mar 10, 2008 at 2:32 PM, Dan Nicholson <[EMAIL PROTECTED]> wrote: > Kristian, > > Unfortunately, moving the libGL install target to src/glx breaks all > the non-glx targets since libGL will never be installed in those > cases. Is there a particular problem you were trying to solve with > that? I don't it's unreasonable to expect make install in a directory such as src/glx/x11 to install the library built in there. That's what I was trying to fix. I guess there's nothing wrong in also installing libGL from src/mesa/Makefile as well, if something relies on that behavior. Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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
Re: [Mesa3d-dev] Xorg 7.4 release plan
On Wed, Feb 27, 2008 at 12:43 PM, Dan Nicholson <[EMAIL PROTECTED]> wrote: > On Wed, Feb 27, 2008 at 8:26 AM, Adam Jackson <[EMAIL PROTECTED]> wrote: > > Aah, the Mesa question. I love this part. > > > > DRI2, unlike pciaccess, is not a complete switchover. Both the DDX and > > the DRI driver can implement support for either or both of DRI1 and > > DRI2, so it's not blocking the release in the sense of "we can't ship > > until this works". > > Unfortunately, building DRI2 requires some parts of mesa master > (dri_sarea.h for sure). That's just the xserver DRI2 module, which is optional (pass --disable-dri2 to xserver ./configure). The biggest problem is that the AIGLX DRI loader is now using the DRI interface present in mesa master. It should be possible to add a glxdri-7.0.c file to GL/glx that loads the old-style interface, it's mostly a matter of resurrecting the old version of GL/glx/glxdri.c and making it compile conditional on the DRI interface version. > I have patches which kill off symlink-mesa.sh and all the > GL/mesa/Makefile.am's, removing a major source of the breakage, but I > haven't gotten far enough to build GLCore in Mesa. That might be > beyond my current abilities since I'm not familiar enough with the > necessary server interfaces. Unfortunately, you still need the mesa > source at xserver build time to build libglx since it pulls in sources > generated in mesa. Maybe there's a solution to that (libglxapi.so?), > but, again, that would take some more work. That would be libglapi.so, but yeah, something like that would be needed. Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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
Re: [Mesa3d-dev] Gallium code reorganization
On Thu, Feb 14, 2008 at 1:38 AM, José Fonseca <[EMAIL PROTECTED]> wrote: > I'll dedicate some time now to reorganize gallium's code & build process. > This is > stuff which has been discussed internally at TG several times, but this time > I > want to get it done. > > My objectives are: > - leaner and more easy to understand/navigate source tree I'm not sure what the scope of the work you're proposing here is, but to get to a leaner source tree, I would definitely recommend splitting out the libraries: glu, glut, glw. egl and even glx. Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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
Re: [Mesa3d-dev] [PATCH 0/10][RFC] Autoconf support for Mesa
On Dec 9, 2007 6:42 AM, José Fonseca <[EMAIL PROTECTED]> wrote: > On Sat, 08 Dec 2007 17:48:59 -0800, Dan Nicholson wrote: > > On Dec 8, 2007 12:48 PM, Alex Neundorf <[EMAIL PROTECTED]> > > wrote: ... > > Maybe the most important is that autoconf is really mature, well > > understood and supports tons of platforms. People will know how to work > > with it because it's used everywhere. > > By "tons of platforms" you mean tons of Unix variants. AFAIK, autotools > still require shell scripts. Mesa is built on more than those. No, I > don't think autoconf is even remotely close to being called cross- > platform. When I look into mesa/configs, all I see is config files for a ton of Unix variants anyway. Half of them are to cover the combinatorial explosion of Linux variants: different compilers, static/dynamic, debug/no-debug, etc. It's insane. It's nice that mesa is cross platform, but I don't see those non-shell capable platforms in mesa/configs. One of our (Red Hat) biggest time sinks when rebasing to a new mesa release is going through the bunch of patches we have to the mesa config files and making sure they apply and figure out where in the hierarchy of config files the DRI_LIBDIR or similar variable is hidden in this release. Dan's proposal to just use autoconf *is* very minimal and solves this problem in a nice standardized way. And support for platforms that doesn't like shell scripts can coexists with the autoconf config file in the same way that the 100 different unix configs currently coexist. From looking through the patches, it looks like a good solution. A few commets: - it would be nice if we didn't have to keep config.guess, config.sub and install-sh in git, but I guess there is no good way of autogenerating these when no using automake. - I think ./configure should create the configs/current link when it's run so the normal ./configure; make sequence works cheers, Kristian - 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
Re: [Mesa3d-dev] Possible fix for libGL.so.1.2 problem
On Sat, 2007-10-27 at 21:45 +0100, Chris Rankin wrote: > Hi, > > Recently, World of Warcraft has been crashing for me in OpenGL mode with an > X-protocol error. > Basically, an attempt to create a GLX context was returning an error from a > previous attempt to > destroy one. The following patch fixes the problem for me: Dang, good catch, and it's the exact right fix. Committed. thanks, Kristian > Cheers, > Chris > > diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c > index 707e398..9bdef98 100644 > --- a/src/glx/x11/glxcmds.c > +++ b/src/glx/x11/glxcmds.c > @@ -105,6 +105,7 @@ static void GarbageCollectDRIDrawables(Display *dpy, > __GLXsc > } > } while (__glxHashNext(sc->drawHash, &draw, (void *)&pdraw) == 1); > } > +XSync(dpy, GL_FALSE); > > XSetErrorHandler(oldXErrorHandler); > } > > > > ___ > Yahoo! Answers - Got a question? Someone out there knows the answer. Try it > now. > http://uk.answers.yahoo.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Handle fbconfigs and glx visuals separately. (was Re: mesa: Changes to 'master')
On 10/18/07, Ian Romanick <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Kristian HXXgsberg wrote: > > > New commits: > > commit 6c533ea2d1953152f7d95d6c984e0d287edb46c2 > > Author: Kristian Høgsberg <[EMAIL PROTECTED]> > > Date: Tue Oct 16 16:07:47 2007 -0400 > > > > Handle fbconfigs and glx visuals separately. > > > > The old implementation fetches fbconfigs or glx visuals once and > > assumes the list > > describes both fbconfigs and glx visuals. This patch splits it up and > > fetches > > visuals and fbconfigs in two steps and keep the two lists separate. A > > server > > could have no glx visuals or no glx fbconfigs and the old code wouldn't > > know the > > difference. > > A portion of this was intentional. By using visuals to create fbconfigs > we could cheat a bit and expose GLX_SGIX_fbconfig even if the server > didn't support it. I don't know if we care about that case any more, > but I though it was worth pointing out. I know, and the system has worked pretty well within the limitations of the old implementation. The assumption that glx visuals and fb configs are the same doesn't work well with other X servers, but I don't think that's been much of an issue in the past. The reason I did the above patch is that I'll be committing an X server patch that does untangle glx visuals and fb configs on the server side. I'm moving glx visual creation from the mi hook to glx screen init, and it will allow us to pick a small set of typically used fbconfigs that we expose as glx visuals. I'm planning an xorg.conf option that will let you specify "none", "typical" or "all" as the set of fbconfigs to expose. cheers, Kristian (Sorry for sending this twice, Ian, my redhat.com address got caught in the list filter) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] libGL exported __glX* symbols (Was: glucose and xgl progress)
On 9/20/07, José Fonseca <[EMAIL PROTECTED]> wrote: > On 9/19/07, Gabor Gombas <[EMAIL PROTECTED]> wrote: > > On Wed, Sep 19, 2007 at 10:20:49AM +, José Fonseca wrote: > > > However, when loaded, references to __glXFreeContext *inside* > > > libglxgext.so are linked to the external __glXFreeContext in libGL.so: > > > > If you have multiple definitions for a symbol it is completely random > > which a given reference will resolve to. > > > > Now, the two underscores are a good hint that these are internal symbols > > and they should not be exported at all or if they have to, one of them > > must be renamed. > > > > > libtool's -export-dynamic flag is not being used. Using libtool's -module > > > flag doesn't change anything. > > > > Does this symbol have to be exported? If no, you should use libtool's > > --export-symbol feature to explicitely declare which symbols should be > > visible and which should not. In fact, it is always wise to use > > --export-symbol when creating shared libraries to prevent ABI breakage > > by accidentally exporting private symbols. > > > > If __glXFreeContext should be exported, then it should be decided which > > library owns this symbol, and the other must be modified not to export > > it. > > > > If it is the case that libGL.so exports __glXFreeContext but > > libglxgext.so wants to locally override it, and for some reason you > > absolutely cannot rename it, then you must use gcc's > > __visibility__((__protected__)) attribute when declaring __glXFreeContext > > in libglgxext.so, but that is not portable to non-ELF platforms and > > other compilers and also has run-time performance costs IIRC. > > I agree in principle with your suggestions. But I'm not entitled to > decide if __glX* symbols > should or not be exported, nor to say what's the best way to accomplish it. > > I know that __glX* functions came originally from SGI code. From there > derived copies appear on mesa (for libGL), and more than once in > xserver code -- I suppose always for indirect rendering purposes (in > places such as AIGLX, DMX, and Xgl). It is likely that other vendors > also ship libGL exporting those symbols. > > But it would definitely make things simpler and less likely to break > if the __glX* symbols were not exported... Ok, big disclaimer here: I haven't looked into glucose or even glitz much, so what I'm suggesting here may not apply. But my take is that we shouldn't be loading libGL in the X server to begin with. If we want to use opengl in the X server we should call into the dispatch table directly (as for example the __glXDRIbindTexImage implementation in GL/glx/glxdri.c: CALL_GetIntegerv(GET_DISPATCH(), (glxPixmap->target == GL_TEXTURE_2D ? GL_TEXTURE_BINDING_2D : GL_TEXTURE_BINDING_RECTANGLE_NV, &texname)); and we may have to export some of the GLX code for use inside the X server (creating glx drawables and contexts etc) and separate out the protocol stuff. Basically if we have to hack around linking issues and fudge symbol resolution issues we're doing something wrong. cheers, Kristian - 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
Re: [Mesa3d-dev] DRI interface changes
On 5/18/07, Ian Romanick <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Kristian Høgsberg wrote:
> > Hi,
> >
> > I've been working on updating the DRI interface
> > (GL/internal/dri_interface.h) the last few days and I though I'd post
...
> > struct __DRIextensionRec {
> > const char *name;
> > };
>
> We've had a couple cases over the years where the interface for a
> particular bit of functionality has changed. It might be worthwhile to
> stick a version in here.
Yes, I think that's a good idea. I think what makes sense is to just
have a single integer counting the number of backwards compatible
bumps of an extension. It doesn't make sense to have a major verion
number to indicate backwards compatibility breaks, since we'd just
define a new extension instead. So the rule is that an extension can
grow new entry points over time, if it makes sense, but we never break
ABI. Also, I don't see a case for a patch-level version number, so I
think a simple, incrementing integer will suffice.
> > If the name matches that of an extension known to the loader, the
> > loader can cast the struct to a more specific extension struct that
> > has the function pointers that provide access to the functionality.
> > For example:
> >
> > #define __DRI_COPY_SUB_BUFFER "DRI_CopySubBuffer"
> > struct __DRIcopySubBufferExtensionRec {
> > __DRIextension base;
> > void (*copySubBuffer)(__DRIdrawable *drawable,
> > int x, int y, int w, int h);
> > };
> >
> > The presence of an extension means that the driver can provide some
> > extra functionality. Based of these extra hooks, the loader will be
> > able to implement and advertise a number of GLX extensions. The DRI
> > extension name space is private to the DRI interface, and is
> > orthogonal to the GLX extension name space. The logic here is that
> > one DRI extension can enable a number of GLX extensions, and the
> > loader, since it has to implement the entry points, will know exactly
> > which GLX extensions to enable. For example, the DRI_SwapControl
> > extension:
>
> Is the implication that drivers won't have to explicitly enable GLX
> extensions? I like that. Let the loader derive the information from
> the information provided by the driver.
Exactly, that's basically what I was trying to say. Here's an example
from glxextensions.c:
#ifdef __DRI_MEDIA_STREAM_COUNTER
if (strcmp(extensions[i]->name, __DRI_MEDIA_STREAM_COUNTER) == 0) {
psc->msc = (__DRImediaStreamCounterExtension *) extensions[i];
SET_BIT(psc->direct_support, SGI_video_sync_bit);
}
#endif
The media stream counter extension provide entry points that let us
implement the GLX_SGI_video_sync extension. The loader stores a
pointer to the extension struct so we don't have to look it up later
on and sets the bit that enables the GLX extension.
If the DRI drivers implemented a swap buffer counter extension, libGL
could implement GLX_OML_sync_control in terms of the msc extension and
the sbc extension.
Similarly, the changes Michel proposed to accelerate
GLX_texture_from_pixmap, should be exported as a DRI_TextureOffset
extension, which will let the X server implement tfp for now. Later
on, we can add a new extension that lets us do the same thing with a
memory manager handle, and phase out the DRI_TextureOffset extension.
So the DRI extensions provide small chunks of functionality with a
name and a version. How those extensions are used by the loader and
how they map the GLX extensions is up to the loader.
...
> > create/destroyContext, create/destroyDrawable (instead of calling back
> > from the DRI driver, just have the loader create the context first and
> > pass the drm_context_t into the driver).
>
> I'll have to look at the code. I'm not 100% sure how this would play out.
As far as I can see, the only reason to do this with callouts from the
DRI driver is that it used to implicitly create DRI drawables when you
bind an X window to a GLX context. With the changes I've done this
never happens: we always explicity create the DRI drawable in libGL or
AIGLX. Either when an X window is bound to a context or when the user
call glXGCreateWindow/Pixmap.
> > 4) Remove variables from the __DRI* structs except the private
> > pointer. We should never share state across the DRI driver boundary,
> > all access should go through functions.
>
> How well is that working out in practice?
Pretty well. The two fields I removed was DRIscreen::screenConfigs,
which you can get from the __DRIscreen pointer, and
DRIdrawable::swap_inte
[Mesa3d-dev] DRI interface changes
Hi,
I've been working on updating the DRI interface
(GL/internal/dri_interface.h) the last few days and I though I'd post
a heads up to the lists to get some feedback. The work I've been
doing starts out with the patches in bug 5714, implements Ians
suggestions in comment #20, and quite a bit more. I haven't added
Alans frontbuffer mapping patches yet; I wanted to get this work done
first before breaking DDX compatibility, but they're next.
The work is on the dri2 branch in git.freedesktop.org/~krh/mesa.git or
browsable here:
http://people.freedesktop.org/krh-cgi/cgit?r=_home_krh_mesa.git&p=log&h=dri2
The changes are mostly a series of cleanup as described below, but
there is a new concept in there: the DRI extension. Much of the churn
in the DRI interface structs is from adding and removing functions
pertaining to GLX extensions, most recently GLX_MESA_copy_sub_buffer
and probably soon GLX_EXT_texture_from_pixmap. The DRI extension
mechanism should allow us to add and remove support for extensions as
they come and go, in a way that doesn't break ABI or API.
The idea here is that only the core GLX 1.4 features should be part of
the __DRI{screen,context,drawable} structs and everything else must be
exposed as a __DRIextension. The list of __DRIextensions is available
using __DRIscreen::getExtensions;
const __DRIextension **(*getExtensions)(__DRIscreen *screen);
All extensions have a common "baseclass" that just is the name of the
extension (just a string):
struct __DRIextensionRec {
const char *name;
};
If the name matches that of an extension known to the loader, the
loader can cast the struct to a more specific extension struct that
has the function pointers that provide access to the functionality.
For example:
#define __DRI_COPY_SUB_BUFFER "DRI_CopySubBuffer"
struct __DRIcopySubBufferExtensionRec {
__DRIextension base;
void (*copySubBuffer)(__DRIdrawable *drawable,
int x, int y, int w, int h);
};
The presence of an extension means that the driver can provide some
extra functionality. Based of these extra hooks, the loader will be
able to implement and advertise a number of GLX extensions. The DRI
extension name space is private to the DRI interface, and is
orthogonal to the GLX extension name space. The logic here is that
one DRI extension can enable a number of GLX extensions, and the
loader, since it has to implement the entry points, will know exactly
which GLX extensions to enable. For example, the DRI_SwapControl
extension:
#define __DRI_SWAP_CONTROL "DRI_SwapControl"
struct __DRIswapControlExtensionRec {
__DRIextension base;
void (*setSwapInterval)(__DRIdrawable *drawable, unsigned int inteval);
unsigned int (*getSwapInterval)(__DRIdrawable *drawable);
};
enables the loader to implement both GLX_SGI_swap_control and
GLX_MESA_swap_control.
Aside from the new extension mechanism, the branch cleans up a number
of things in the DRI interface:
1) Move XIDs out of the interface and make libGL handle XID ->
__DRIdrawable etc mapping. I've pulled the hashtable from libdrm into
mesa to do this, which should allow us to drop the hashtable and the
skip list from drm eventually.
2) Drop the display notion from the interface. A DRI driver only
handles one screen and
3) Remove getProcAddress (only needed by the old extension mechanism),
create/destroyContext, create/destroyDrawable (instead of calling back
from the DRI driver, just have the loader create the context first and
pass the drm_context_t into the driver).
4) Remove variables from the __DRI* structs except the private
pointer. We should never share state across the DRI driver boundary,
all access should go through functions.
5) Misc cleanups: pull the createNewScreen out of the driver backends
and into dri/common (more code sharing, simpler interface between
dri/common and drivers), always use the __DRI* types instead of
private void pointers (type safety, interface is more
self-documenting), generate entry point name using macros instead of
duplication the version number in a few places, drop now unused
__DRIid typedef.
cheers,
Kristian
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] mesa: Branch 'master' - 2 commits
On 12/8/06, Michel Dänzer <[EMAIL PROTECTED]> wrote: > > Hi Haihao, > > > glad to see your write access is working. :) > > > fix bug#9237 > > It would be nice if you could make the commit messages a little more > verbose. As was mentioned on this list recently, the convention for git > is to write a single line summary ... But putting the bug number in the commit message for a commit that fixes a bug is of course also a great convention, thanks for doing that. And to link the other way, it's a great convention to also put the SHA-1 sum of the commit in the bugzilla it closes. This way it's easy to cherry-pick or revert specific fixes. Kristian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
