[Mesa3d-dev] user buffers, usage hints [was RE: Grab bag of random questions (whoo)]
Userbuffers get hit in the traditional GL vertex array paths, which is pretty common usage. I've been thinking about buffers and uploads a bit recently, and I'm pretty sure we can do better than the current mechanisms. Also, it makes sense to make the BUFFER_USAGE_ flags stronger - I think it's been a grey area whether they are hints or not. I've been (rightly or wrongly) thinking of them as guarantees for a while, so I certainly won't argue to keep them as hints. I'm pretty sure the SVGA driver treats them as guarantees, for instance, and uses malloc for constant buffers. Keith From: Corbin Simpson [mostawesomed...@gmail.com] Sent: Saturday, January 30, 2010 4:06 AM To: Mesa3D-Development Subject: [Mesa3d-dev] Grab bag of random questions (whoo) 4) user_buffer_create doesn't appear to see an incredible amount of usage. Would it be too horrible to make *all* buffer allocations delayed, transparently? I ask because apparently the PIPE_BUFFER_USAGE flags (PIXEL, CONSTANT, etc.) are optimization hints and not guarantees, which is very annoying since I need to prevent constantbufs from ever becoming BO-backed... -- 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] user buffers, usage hints [was RE: Grab bag of random questions (whoo)]
On Sun, 2010-01-31 at 04:31 -0800, Keith Whitwell wrote: Userbuffers get hit in the traditional GL vertex array paths, which is pretty common usage. I've been thinking about buffers and uploads a bit recently, and I'm pretty sure we can do better than the current mechanisms. Also, it makes sense to make the BUFFER_USAGE_ flags stronger - I think it's been a grey area whether they are hints or not. I've been (rightly or wrongly) thinking of them as guarantees for a while, so I certainly won't argue to keep them as hints. I'm pretty sure the SVGA driver treats them as guarantees, for instance, and uses malloc for constant buffers. Actually SVGA interprets them as hints. It just uses them to choose whether the initial storage should be in a malloc buffer or hardware buffer. If any buffer (user or not) is bound then a host surface and dma upload will happen automatically. This all happens in svga_buffer_handle(). From: Corbin Simpson [mostawesomed...@gmail.com] Sent: Saturday, January 30, 2010 4:06 AM To: Mesa3D-Development Subject: [Mesa3d-dev] Grab bag of random questions (whoo) 4) user_buffer_create doesn't appear to see an incredible amount of usage. user_buffer_create is exposed by the APIs to the application. It is used as often as the apps use it. My understanding is that old GL and D3D apps use it a lot. Would it be too horrible to make *all* buffer allocations delayed, transparently? You mean, make the state tracker's responsibility to create a hardware pipe buffer and copy the contents when the buffer is about to be bound? What about software renderers or software vertex processing fallbacks done by the draw module? They would incur unnecessary extra copy, as they can read the user memory directly. Furthermore Thomas devised at some time the possibility to create DRM buffers from user memory on demand, so even real hardware could potentially do similar things. In summary, yes it will be possible, but it would damage I ask because apparently the PIPE_BUFFER_USAGE flags (PIXEL, CONSTANT, etc.) are optimization hints and not guarantees, which is very annoying since I need to prevent constantbufs from ever becoming BO-backed... That's why pipe_screen::buffer_create should be != pipe_winsys::buffer_create and pipe_winsys should die. The winsys should worry only about DRM BOs. The pipe driver should implement user buffers internally, do whatever it needs to be done, and never pass them to the winsys. Jose -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Grab bag of random questions (whoo)
On Sat, 2010-01-30 at 04:06 -0800, Corbin Simpson wrote: Handful of random things bugging me. Bellow some answers for the things I know enough to comment. 1) Team Fortress 2 (and probably other Source games, haven't really checked) request some fairly large VBOs and indexbufs, beyond what I can provide. Is there any good example code on how to use translate/indices to slice up buffers for multiple render runs? Draw module has some code to break large VBOs. But I don't know how to set it up so that it does that without doing vertex processing though. Keith's might help you with that. 3) Is there still interest in the translate helper I proposed a couple weeks ago? It would take a list of safe formats, a list of VBO elements, and a list of VBOs (corresponding), and return a list of VBO elements and VBOs that only contain those safe formats. State trackers would call a pipe_screen (or pipe_context?) method with just the VBOs and elements, and it would fix them up without exposing the list of safe formats. I've missed that mail. I've read the thread and I agree with Keith's reply. In summary, there are more than one way to skin this cat but your proposed helper seems an useful thing to have. 5) How const is const for CSO? e.g. r300_state.c:498, we're not copying pipe_framebuffer_state but just the pointer. It appears to work, but is it actually safe? The const means the driver cannot change it. Not that it won't change. The long answer is depends on how the driver is implemented and commands batched. The next time the set_framebuffer_state is called the previous object may have been destroyed/modified, so if you have internal references to it they would cause segfault. But if by the time that happens you no longer have references to it -- e.g. you just have references to the BOs that hold the frambuffer storage -- then it would work fine. Short answer is -- it is better to just make a local copy. Also, on the topic of framebuffers, is it okay to refuse to render if no MRTs or Z buffer are present? Not really. At least not as it stands. If the hardware requires these then they'll need to be created internally by the pipe driver. We could add a caps for this but I see no point for it, since it's so easy to create a dummy framebuffer internally. I think that's it for now. Sorry for all the questions, but I'm really starting to get a good handle on the hardware and interface, and I'm ready to start beating the classic driver in serious benchmarks; I think that r300's probably the most mature driver alongside nv50 and maybe nv40. That's great to hear. It has been really nice to see gallium driver development lately on so many different hardware, and with that seeing gallium interface more polished to abstract well more hardware. I think you've been doing a great work not only with the driver development, but also making the right questions, and documenting interfaces. Jose -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 26317] glsl compiled wrong
http://bugs.freedesktop.org/show_bug.cgi?id=26317 --- Comment #6 from Brian Paul brian.e.p...@gmail.com 2010-01-31 08:41:13 PST --- Yes, the _mesa_find_free_register() function is returning the same register everytime. I've got fix nearly ready but it may be a day or two until I finish it... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Grab bag of random questions (whoo)
On 31.01.2010 01:37, Roland Scheidegger wrote: Marek Olšák wrote: 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in the fragment constants reads, Since Gallium doesn't support GL_ARB_shadow_ambient, this is always (0,0,0,0), right? I think the extension could be added to Gallium since the r300 compiler can generate code for it. It could. But generally, gallium doesn't implement features common hardware can't do (not only because most drivers except software based ones couldn't implement it, but those features also turn out to be rarely used, for obvious reasons). r300 is an exception here since it emulates ARB_shadow anyway. Though I think if you can make a case why this is really necessary it could be done, but that's not my call. Another comment reads, Gallium doesn't provide us with any information regarding this mode, so we are screwed. I'm setting 0 = LUMINANCE, above the texture compare modes. I don't really like that section of code, but it probably can't get cleaner, right? Even though this is a rarely used feature in OpenGL nowadays, it should get fixed if we want to be GL-compliant. That means adding depth texture modes in pipe_sampler_state and setting them in the Mesa state tracker. The R300 compiler can already generate code for these modes as well. Note R300 is again special a bit here. Actually, I realized my earlier answer doesn't make sense. Hardware which actually supports EXT_texture_swizzle (and native ARB_shadow) should be able to implement this easily. Hardware like i965 which doesn't support EXT_texture_swizzle could do it in the shader. Maybe it would make sense to add EXT_texture_swizzle capability in gallium (in the sampler state). That would solve this in a bit more generic way than some special bits for depth texture mode. From my point of view adding a swizzle in the sampler state is a bad idea. On nv50, this would make texture setup dependent on sampler state: we have an Image and Sampler configuration buffer containing entries that can be bound to texture and sampler units. The texture swizzle would be supported by setting a different format in the image entry, like BGRA instead of RGBA, just that it also supports RGRG or whatever you like. Well, the normalization bit seems to be stored in the TIC entries instead of the TSC ones already, I guess that comes from the rectangle texture type, but let's ignore that. I don't see texture swizzle in d3d10 (but then, I don't know d3d10 very well), and OpenGL doesn't separate textures and samplers anyway, so I'd put in in texture state. Keeping a bunch of shaders for texture swizzles doesn't sound nice either. Of course, if other hardware would prefer this in sampler state, then ... ah, I should probably let go of the illusion that gallium state will continue to nicely map to my hardware ... Christoph 7) Is there more information on the dual-source blend modes? I'm not sure if I can do them; might have to bug AMD for the register values. I bet R300 can't do these modes. It's only a Direct3D 10.0 feature, not present in Direct3D 10.1. MS must have a good reason to remove it. Where did you see that it's removed in 10.1? Here's a list of blend ops in d3d11: http://msdn.microsoft.com/en-us/library/ee416042(VS.85).aspx Note this feature can be present (via cap bits in some limited form) in D3D9Ex too, and I thought windows actually used it for (antialiased) text rendering (but don't quote me on that). BTW I looked at some of your patches and r3xx-r5xx cards don't even support separate blend enables, therefore the cap should be 0. Or are you going to emulate this using independent color channel masks and two rendering passes? That could be done in the state tracker. Also, I think the indep. color masks are r5xx-only. I also think even r500 shouldn't say this is supported. Just changing the colormasks isn't going to be very correct... Roland -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- 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
Re: [Mesa3d-dev] 7.7 VBO bug fix patches for review
On Thu, Jan 28, 2010 at 9:21 PM, Brian Paul bri...@vmware.com wrote: This patch series fixes some bugs in VBO state validation for variations of glDrawElements(). I've tested and haven't found any regressions but since these are non-trivial changes, I'm putting them up for review. I'll commit later if there's no concerns. I have one concern : it fixed warsow white screen, so I can actually play it now (at least on nv50 gallium) :) Thanks ! -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Grab bag of random questions (whoo)
On Sun, Jan 31, 2010 at 6:21 AM, José Fonseca jfons...@vmware.com wrote: On Sat, 2010-01-30 at 04:06 -0800, Corbin Simpson wrote: 5) How const is const for CSO? e.g. r300_state.c:498, we're not copying pipe_framebuffer_state but just the pointer. It appears to work, but is it actually safe? The const means the driver cannot change it. Not that it won't change. The long answer is depends on how the driver is implemented and commands batched. The next time the set_framebuffer_state is called the previous object may have been destroyed/modified, so if you have internal references to it they would cause segfault. But if by the time that happens you no longer have references to it -- e.g. you just have references to the BOs that hold the frambuffer storage -- then it would work fine. Short answer is -- it is better to just make a local copy. Alright, not hard to fix. Also, on the topic of framebuffers, is it okay to refuse to render if no MRTs or Z buffer are present? Not really. At least not as it stands. If the hardware requires these then they'll need to be created internally by the pipe driver. We could add a caps for this but I see no point for it, since it's so easy to create a dummy framebuffer internally. Again, I should have typed and. I was thinking in terms of sanity checks. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Grab bag of random questions (whoo)
In r300 we already have had to cross several states to get conformant rendering in some situations. It's not terribly fun, but it's necessary. IIRC textures and samplers were the first to be emitted together. On Sun, Jan 31, 2010 at 9:41 AM, Christoph Bumiller e0425...@student.tuwien.ac.at wrote: On 31.01.2010 01:37, Roland Scheidegger wrote: Marek Olšák wrote: 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in the fragment constants reads, Since Gallium doesn't support GL_ARB_shadow_ambient, this is always (0,0,0,0), right? I think the extension could be added to Gallium since the r300 compiler can generate code for it. It could. But generally, gallium doesn't implement features common hardware can't do (not only because most drivers except software based ones couldn't implement it, but those features also turn out to be rarely used, for obvious reasons). r300 is an exception here since it emulates ARB_shadow anyway. Though I think if you can make a case why this is really necessary it could be done, but that's not my call. Another comment reads, Gallium doesn't provide us with any information regarding this mode, so we are screwed. I'm setting 0 = LUMINANCE, above the texture compare modes. I don't really like that section of code, but it probably can't get cleaner, right? Even though this is a rarely used feature in OpenGL nowadays, it should get fixed if we want to be GL-compliant. That means adding depth texture modes in pipe_sampler_state and setting them in the Mesa state tracker. The R300 compiler can already generate code for these modes as well. Note R300 is again special a bit here. Actually, I realized my earlier answer doesn't make sense. Hardware which actually supports EXT_texture_swizzle (and native ARB_shadow) should be able to implement this easily. Hardware like i965 which doesn't support EXT_texture_swizzle could do it in the shader. Maybe it would make sense to add EXT_texture_swizzle capability in gallium (in the sampler state). That would solve this in a bit more generic way than some special bits for depth texture mode. From my point of view adding a swizzle in the sampler state is a bad idea. On nv50, this would make texture setup dependent on sampler state: we have an Image and Sampler configuration buffer containing entries that can be bound to texture and sampler units. The texture swizzle would be supported by setting a different format in the image entry, like BGRA instead of RGBA, just that it also supports RGRG or whatever you like. Well, the normalization bit seems to be stored in the TIC entries instead of the TSC ones already, I guess that comes from the rectangle texture type, but let's ignore that. I don't see texture swizzle in d3d10 (but then, I don't know d3d10 very well), and OpenGL doesn't separate textures and samplers anyway, so I'd put in in texture state. Keeping a bunch of shaders for texture swizzles doesn't sound nice either. Of course, if other hardware would prefer this in sampler state, then ... ah, I should probably let go of the illusion that gallium state will continue to nicely map to my hardware ... Christoph 7) Is there more information on the dual-source blend modes? I'm not sure if I can do them; might have to bug AMD for the register values. I bet R300 can't do these modes. It's only a Direct3D 10.0 feature, not present in Direct3D 10.1. MS must have a good reason to remove it. Where did you see that it's removed in 10.1? Here's a list of blend ops in d3d11: http://msdn.microsoft.com/en-us/library/ee416042(VS.85).aspx Note this feature can be present (via cap bits in some limited form) in D3D9Ex too, and I thought windows actually used it for (antialiased) text rendering (but don't quote me on that). BTW I looked at some of your patches and r3xx-r5xx cards don't even support separate blend enables, therefore the cap should be 0. Or are you going to emulate this using independent color channel masks and two rendering passes? That could be done in the state tracker. Also, I think the indep. color masks are r5xx-only. I also think even r500 shouldn't say this is supported. Just changing the colormasks isn't going to be very correct... Roland -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- The
Re: [Mesa3d-dev] Grab bag of random questions (whoo)
On Sun, Jan 31, 2010 at 3:21 PM, José Fonseca jfons...@vmware.com wrote: On Sat, 2010-01-30 at 04:06 -0800, Corbin Simpson wrote: Handful of random things bugging me. Bellow some answers for the things I know enough to comment. 1) Team Fortress 2 (and probably other Source games, haven't really checked) request some fairly large VBOs and indexbufs, beyond what I can provide. Is there any good example code on how to use translate/indices to slice up buffers for multiple render runs? Draw module has some code to break large VBOs. But I don't know how to set it up so that it does that without doing vertex processing though. Keith's might help you with that. If you want to do Gallium primitive splitting, I've just written some code for Nouveau to do that, which is however not dependent on Nouveau at all and could be moved to auxilliary. See util_split_primitive in http://repo.or.cz/w/mesa/mesa-lb.git/blob/da684bbc089083f90a3625f9ad2173e91872f848:/src/gallium/drivers/nouveau/nouveau_util.h and its usage in http://repo.or.cz/w/mesa/mesa-lb.git/blob/da684bbc089083f90a3625f9ad2173e91872f848:/src/gallium/drivers/nv40/nv40_vbo.c -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 26317] glsl compiled wrong
http://bugs.freedesktop.org/show_bug.cgi?id=26317 --- Comment #7 from Brian Paul brian.e.p...@gmail.com 2010-01-31 16:46:39 PST --- Created an attachment (id=32956) -- (http://bugs.freedesktop.org/attachment.cgi?id=32956) patch to find multiple free temp regs Here's a patch that should fix this problem. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Honor LD_LIBRARY_PATH getting EGL drivers
The changes to load EGL drivers by pattern matching had the side effect of not
looking in the directories specified by LD_LIBRARY_PATH or -rpath or ldconfig.
This patch changes the search to first look in the directories listed in
LD_LIBRARY_PATH. To do that it moves the possible addition of a path prefix
from make_library_path() into open_library().
This patch doesn't add searches in the -rpath or ldconfig directories.
Those would be more difficult (or impossible) to determine in a portable manner.
The patch also tightens up the library suffix test with a specific
match for the suffix
at the end of the EGL_DRIVER name.
--
Mike Stroyan - Software Architect
LunarG, Inc. - The Graphics Experts
Cell: (970) 219-7905
Email: m...@lunarg.com
Website: http://www.lunarg.com
From 59b7ddbe02fa75045c8037768127a2cfe87a7c8f Mon Sep 17 00:00:00 2001
From: Mike Stroyan m...@eclipse.(none)
Date: Sun, 31 Jan 2010 17:58:41 -0700
Subject: [PATCH] Make egl look in library search path for drivers. Use full suffix test.
---
src/egl/main/egldriver.c | 144 --
1 files changed, 100 insertions(+), 44 deletions(-)
diff --git a/src/egl/main/egldriver.c b/src/egl/main/egldriver.c
index df36369..a801fae 100644
--- a/src/egl/main/egldriver.c
+++ b/src/egl/main/egldriver.c
@@ -56,7 +56,7 @@ close_library(HMODULE lib)
static const char *
library_suffix(void)
{
- return dll;
+ return .dll;
}
@@ -64,10 +64,18 @@ static EGLBoolean
make_library_path(char *buf, unsigned int size, const char *name)
{
EGLBoolean need_suffix;
- const char *suffix = .dll;
+ const char *suffix = library_suffix();
int ret;
- need_suffix = (strchr(name, '.') == NULL);
+ /* match the suffix */
+ if (suffix) {
+ size_t name_len = strlen(name);
+ size_t suffix_len = strlen(suffix);
+ need_suffix = (name_len suffix_len
+ || strcmp(name + name_len - suffix_len, suffix) != 0);
+ } else {
+ need_suffix = EGL_FALSE;
+ }
ret = snprintf(buf, size, %s%s, name, (need_suffix) ? suffix : );
return ((unsigned int) ret size);
@@ -84,7 +92,25 @@ typedef void * lib_handle;
static void *
open_library(const char *filename)
{
- return dlopen(filename, RTLD_LAZY);
+ void *handle;
+
+ /* first try opening without an explicit directory to allow search path */
+ handle = dlopen(filename, RTLD_LAZY);
+ if (handle) {
+ return handle;
+ }
+
+ /* if plain file unfound try adding _EGL_DRIVER_SEARCH_DIR directory */
+ if (strchr(filename, '/') == NULL) {
+ char path[1024];
+ int ret;
+ ret = snprintf(path, sizeof(path), %s%s,
+_EGL_DRIVER_SEARCH_DIR/, filename);
+ if ((unsigned int) ret sizeof(path)) {
+ return dlopen(path, RTLD_LAZY);
+ }
+ }
+ return NULL;
}
static void
@@ -97,23 +123,27 @@ close_library(void *lib)
static const char *
library_suffix(void)
{
- return so;
+ return .so;
}
static EGLBoolean
make_library_path(char *buf, unsigned int size, const char *name)
{
- EGLBoolean need_dir, need_suffix;
- const char *suffix = .so;
+ EGLBoolean need_suffix;
+ const char *suffix = library_suffix();
int ret;
- need_dir = (strchr(name, '/') == NULL);
- need_suffix = (strchr(name, '.') == NULL);
-
- ret = snprintf(buf, size, %s%s%s,
- (need_dir) ? _EGL_DRIVER_SEARCH_DIR/ : , name,
- (need_suffix) ? suffix : );
+ /* match the suffix */
+ if (suffix) {
+ size_t name_len = strlen(name);
+ size_t suffix_len = strlen(suffix);
+ need_suffix = (name_len suffix_len
+ || strcmp(name + name_len - suffix_len, suffix) != 0);
+ } else {
+ need_suffix = EGL_FALSE;
+ }
+ ret = snprintf(buf, size, %s%s, name, (need_suffix) ? suffix : );
return ((unsigned int) ret size);
}
@@ -333,6 +363,48 @@ _eglPreloadUserDriver(void)
#endif
}
+#if defined(_EGL_PLATFORM_POSIX)
+/**
+ * Preload display drivers found in a particular directory.
+ */
+static void
+_eglPreloadDisplayDriversFromDir(const char *prefix, const char *suffix, const char *dir)
+{
+ char path[1024];
+ DIR *dirp;
+ struct dirent *dirent;
+
+ dirp = opendir(dir);
+ if (!dirp)
+ return;
+
+ while ((dirent = readdir(dirp))) {
+ _EGLDriver *drv;
+
+ /* match the prefix */
+ if (strncmp(dirent-d_name, prefix, strlen(prefix)) != 0)
+ continue;
+
+ /* match the suffix */
+ if (suffix) {
+ size_t d_name_len = strlen(dirent-d_name);
+ size_t suffix_len = strlen(suffix);
+ if (d_name_len suffix_len)
+continue;
+ if (strcmp(dirent-d_name + d_name_len - suffix_len, suffix) != 0)
+continue;
+ }
+
+ snprintf(path, sizeof(path), %s/%s, dir, dirent-d_name);
+
+ drv = _eglLoadDriver(path, NULL);
+ if (drv)
+ _eglGlobal.Drivers[_eglGlobal.NumDrivers++] = drv;
+ }
+
+ closedir(dirp);
+}
+#endif
/**
* Preload display
[Mesa3d-dev] [Bug 26317] glsl compiled wrong
http://bugs.freedesktop.org/show_bug.cgi?id=26317 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #32956|application/octet-stream|text/plain mime type|| Attachment #32956|0 |1 is patch|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Honor LD_LIBRARY_PATH getting EGL drivers
On Mon, Feb 1, 2010 at 9:15 AM, Mike Stroyan m...@lunarg.com wrote: The changes to load EGL drivers by pattern matching had the side effect of not looking in the directories specified by LD_LIBRARY_PATH or -rpath or ldconfig. This patch changes the search to first look in the directories listed in LD_LIBRARY_PATH. To do that it moves the possible addition of a path prefix from make_library_path() into open_library(). This patch doesn't add searches in the -rpath or ldconfig directories. Those would be more difficult (or impossible) to determine in a portable manner. I am leaning toward something similar to how DRI drivers are loaded: Allow the users to specify the search directory through EGL_DRIVERS_PATH. It also seems EGL will need a check for setuid in both EGL_DRIVER (my fault) and the proposed EGL_DRIVERS_PATH. The patch also tightens up the library suffix test with a specific match for the suffix at the end of the EGL_DRIVER name. I want to avoid suffix matching somehow. Do you have a specific example why the change is needed? Or, will the following change suffice? p = strrchr(name, '.'); need_suffix = (!p || (strchr(p + 1, '/') != NULL)); -olv -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Honor LD_LIBRARY_PATH getting EGL drivers
On Sun, Jan 31, 2010 at 7:46 PM, Chia-I Wu olva...@gmail.com wrote: On Mon, Feb 1, 2010 at 9:15 AM, Mike Stroyan m...@lunarg.com wrote: The changes to load EGL drivers by pattern matching had the side effect of not looking in the directories specified by LD_LIBRARY_PATH or -rpath or ldconfig. This patch changes the search to first look in the directories listed in LD_LIBRARY_PATH. To do that it moves the possible addition of a path prefix from make_library_path() into open_library(). This patch doesn't add searches in the -rpath or ldconfig directories. Those would be more difficult (or impossible) to determine in a portable manner. I am leaning toward something similar to how DRI drivers are loaded: Allow the users to specify the search directory through EGL_DRIVERS_PATH. A specific environment variable may be the best option if -rpath and ldconfig cannot be used. (They should be added into docs/envvars.html .) It also seems EGL will need a check for setuid in both EGL_DRIVER (my fault) and the proposed EGL_DRIVERS_PATH. A setuid/setgid check is a very good idea for allowing both *PATH and EGL_DRIVER. (geteuid() == getuid()) getegid () == getgid ()) will test for that. The patch also tightens up the library suffix test with a specific match for the suffix at the end of the EGL_DRIVER name. I want to avoid suffix matching somehow. Do you have a specific example why the change is needed? Or, will the following change suffice? p = strrchr(name, '.'); need_suffix = (!p || (strchr(p + 1, '/') != NULL)); I was thinking about future library names that might contain decimal points such as egl_x11_i999.5.so. Leaving the .so suffix off would not work as make_library_path would just check for any appearance of '.'. Of course, just setting EGL_DRIVER to include .so suffix would avoid the issue. -- Mike Stroyan - Software Architect LunarG, Inc. - The Graphics Experts Cell: (970) 219-7905 Email: m...@lunarg.com Website: http://www.lunarg.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Honor LD_LIBRARY_PATH getting EGL drivers
On Mon, Feb 1, 2010 at 11:19 AM, Mike Stroyan m...@lunarg.com wrote: On Sun, Jan 31, 2010 at 7:46 PM, Chia-I Wu olva...@gmail.com wrote: On Mon, Feb 1, 2010 at 9:15 AM, Mike Stroyan m...@lunarg.com wrote: The changes to load EGL drivers by pattern matching had the side effect of not looking in the directories specified by LD_LIBRARY_PATH or -rpath or ldconfig. This patch changes the search to first look in the directories listed in LD_LIBRARY_PATH. To do that it moves the possible addition of a path prefix from make_library_path() into open_library(). This patch doesn't add searches in the -rpath or ldconfig directories. Those would be more difficult (or impossible) to determine in a portable manner. I am leaning toward something similar to how DRI drivers are loaded: Allow the users to specify the search directory through EGL_DRIVERS_PATH. A specific environment variable may be the best option if -rpath and ldconfig cannot be used. (They should be added into docs/envvars.html .) docs/egl.html lists all environment variables EGL honors. A link from docs/envars.html to docs/egl.html for EGL specific variables might be the best. It also seems EGL will need a check for setuid in both EGL_DRIVER (my fault) and the proposed EGL_DRIVERS_PATH. A setuid/setgid check is a very good idea for allowing both *PATH and EGL_DRIVER. (geteuid() == getuid()) getegid () == getgid ()) will test for that. The patch also tightens up the library suffix test with a specific match for the suffix at the end of the EGL_DRIVER name. I want to avoid suffix matching somehow. Do you have a specific example why the change is needed? Or, will the following change suffice? p = strrchr(name, '.'); need_suffix = (!p || (strchr(p + 1, '/') != NULL)); I was thinking about future library names that might contain decimal points such as egl_x11_i999.5.so. Leaving the .so suffix off would not work as make_library_path would just check for any appearance of '.'. Of course, just setting EGL_DRIVER to include .so suffix would avoid the issue. I prefer leave it for the future. There should hopefully no driver with a dot in its name. -olv -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
