Re: [Mesa-dev] How MESA display image in case of use full software rendering?
On 2019-12-23 6:01 a.m., Oleg Gavrilchenko wrote: > I can ask. How MESA display image in case of use full software > rendering? What does interface it use? > It use /dev/fbX, drm or otherwise method? [Disclaimer: I have very limited experience with this, but hope some hint is better than none.] The software renderers obviously output to internal system memory buffers. You need to pick a mechanism to blit those bits to your own output buffer for scanout (or otherwise display). As one example, look at the X server's glx/glxdriswrast.c:__glXDRIscreenProbe() where you can trace down how the DRI mechanism connects swrast output images to X drawable memory. (It is quite convoluted, likely there are better examples than that mechanism, but I don't know them.) -Nathan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Can I build mesa swrast on system without GPU? And how I should do it?
On 2019-12-17 3:07 a.m., Oleg Gavrilchenko wrote: > Can I build mesa swrast for my device and how can I do it? > ... > ninja -C build/ > > build fail with errors: > > [84/882] Linking target src/mapi/es1api/libGLESv1_CM.so.1.1.0. > FAILED: src/mapi/es1api/libGLESv1_CM.so.1.1.0 > arm-linux-gnueabihf-gcc -o src/mapi/es1api/libGLESv1_CM.so.1.1.0 > 'src/mapi/es1api/ffa5f0c@@GLESv1_CM@sha/.._entry.c.o' -Wl,--as-needed > -Wl,--no-undefined -shared -fPIC -Wl,--start-group > -Wl,-soname,libGLESv1_CM.so.1 src/mapi/shared-glapi/libglapi.so.0.0.0 > -Wl,--gc-sections -pthread -L/home/oleg/work/z-turn-dvi/sysroot/usr/lib > -ldrm -lm -ldl -Wl,--end-group '-Wl,-rpath,$ORIGIN/../shared-glapi' > -Wl,-rpath-link,/home/oleg/src/mesa-19.2.7/build/src/mapi/shared-glapi > /opt/Xilinx/SDK/2018.2/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/../../../../arm-linux-gnueabihf/bin/ld: > cannot find -ldrm > collect2: error: ld returned 1 exit status > > DRM option enable in Linux kernel, but I do not install libdrm on my > system. Should I do it? And how it will work with my fbdev? > Thank you for answers. And sorry for my English. I have no experience with connecting Mesa to a custom fbdev, but just want to note I don't use libdrm in my scenario either but successfully run builds with a minimal (--disable-) libdrm linked in just to avoid upstream diffs. And you'll need libexpat after that. -Nathan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is it time to stop using the mailing list for patch review?
On 2019-12-10 7:10 p.m., Jason Ekstrand wrote: > Quoting Zebediah Figura (2019-12-10 10:58:45) > > On 12/10/19 12:21 PM, Matt Turner wrote: > > > On Mon, Dec 9, 2019 at 6:07 PM Dylan Baker wrote: > > > > I think its time we discussed whether we're going to continue to do > > > > patch review > > > > on the mailing list, or if it it should all go through gitlab. I think > > > > we should > > > > stop using the mailing list, here are some reasons: > > > > > > > > 1) Most development is happening on gitlab at this point, patches on > > > > the mailing > > > > list are often overlooked > > > > 2) The mailing list bypasses CI which potentially breaks the build > > > > > > What concrete change would you propose? > > > > Removing mention of the mailing list from documentation would be nice. > > Also, currently the README implies that the mailing list is not only > > acceptable but preferred: "Note that Mesa uses email mailing-lists for > > patches submission, review and discussions." > > I think updating README type docs is sufficient and I think it's > probably time we did that. As a recent drive-by patch submitter, updating the web page and other docs to say "use GitLab" would have been sufficient for me. As they are now it wasn't clear which way is preferred, so I defaulted to using mesa-dev@ only to find that the dev focus seems to be in gitlab.fd.o and if it wasn't for Roland watching the mailing list my patch seemed likely to get missed. I also went through the work of subscribing to mesa-stable@ to nominate there, but again it feels like I missed the de-facto channel for suggesting a stable backport patch. Hint hint [1]. :) GitLab would have been preferred all round. -Nathan [1] llvmpipe: Check thread creation errors 9a80b7fd8f282d4b448f826ff88c8770c079fb72 Prevents a SEGV in situations where thread creation is restricted (cgroups, ulimit -u, /proc/sys/kernel/threads-max, etc.) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: no-op C99 _Pragma() with MSVC
On 2019-11-23 12:38 p.m., Brian Paul wrote: > BTW, With gcc 5.4.0, there's a lot of warnings about the pragma not > being understood: > > ../src/compiler/nir/nir_range_analysis.c:268:0: warning: ignoring > #pragma GCC unroll [-Wunknown-pragmas] > ASSERT_TABLE_IS_COMMUTATIVE(union_table); > ^ > ../src/compiler/nir/nir_range_analysis.c:268:0: warning: ignoring > #pragma GCC unroll [-Wunknown-pragmas] > ../src/compiler/nir/nir_range_analysis.c:269:0: warning: ignoring > #pragma GCC unroll [-Wunknown-pragmas] > > I'd have to dig to see what version of gcc added that to add more > preprocessor tests to silence it. #pragma GCC unroll is since GCC 8. "A new pragma GCC unroll has been implemented in the C family of languages, as well as Fortran and Ada, so as to make it possible for the user to have a finer-grained control over the loop unrolling optimization. " -- https://gcc.gnu.org/gcc-8/changes.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: Check thread creation errors
Thanks. I'll have to rely on someone with a commit bit to push this.
On 2019-11-10 4:55 p.m., Roland Scheidegger wrote:
> Looks great to me.
> Reviewed-by: Roland Scheidegger
>
> Am 08.11.19 um 23:05 schrieb Nathan Kidd:
>> In the case of glibc, pthread_t is internally a pointer. If
>> lp_rast_destroy() passes a 0-value pthread_t to pthread_join(), the
>> latter will SEGV dereferencing it.
>>
>> pthread_create() can fail if either the user's ulimit -u or Linux
>> kernel's /proc/sys/kernel/threads-max is reached.
>>
>> Choosing to continue, rather than fail, on theory that it is better to
>> run with the one main thread, than not run at all.
>>
>> Keeping as many threads as we got, since lack of threads severely
>> degrades llvmpipe performance.
>>
>> Signed-off-by: Nathan Kidd
>> ---
>> src/gallium/drivers/llvmpipe/lp_rast.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
>> b/src/gallium/drivers/llvmpipe/lp_rast.c
>> index d50e92b..ef783ea 100644
>> --- a/src/gallium/drivers/llvmpipe/lp_rast.c
>> +++ b/src/gallium/drivers/llvmpipe/lp_rast.c
>> @@ -867,6 +867,10 @@ create_rast_threads(struct lp_rasterizer *rast)
>>pipe_semaphore_init(&rast->tasks[i].work_done, 0);
>>rast->threads[i] = u_thread_create(thread_function,
>> (void *) &rast->tasks[i]);
>> + if (!rast->threads[i]) {
>> + rast->num_threads = i; /* previous thread is max */
>> + break;
>> + }
>> }
>> }
>> -- 1.8.3.1
>>
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Csroland%40vmware.com%7C89a950ed76af42db159608d7649a0d7f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637088485136387009&sdata=NT1iuAGZTnoJErKVkS2RbobIj5ufzYI2n0j3FIYxxUY%3D&reserved=0
>>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] llvmpipe: Check thread creation errors
In the case of glibc, pthread_t is internally a pointer. If
lp_rast_destroy() passes a 0-value pthread_t to pthread_join(), the
latter will SEGV dereferencing it.
pthread_create() can fail if either the user's ulimit -u or Linux
kernel's /proc/sys/kernel/threads-max is reached.
Choosing to continue, rather than fail, on theory that it is better to
run with the one main thread, than not run at all.
Keeping as many threads as we got, since lack of threads severely
degrades llvmpipe performance.
Signed-off-by: Nathan Kidd
---
src/gallium/drivers/llvmpipe/lp_rast.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
b/src/gallium/drivers/llvmpipe/lp_rast.c
index d50e92b..ef783ea 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -867,6 +867,10 @@ create_rast_threads(struct lp_rasterizer *rast)
pipe_semaphore_init(&rast->tasks[i].work_done, 0);
rast->threads[i] = u_thread_create(thread_function,
(void *) &rast->tasks[i]);
+ if (!rast->threads[i]) {
+ rast->num_threads = i; /* previous thread is max */
+ break;
+ }
}
}
-- 1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glxgears_pixmap: destroy correct pixmap id
On 11/08/14 06:56 PM, Brian Paul wrote: On 08/11/2014 04:51 PM, Nathan Kidd wrote: Previously we'd get a GLXBadPixmap error. Signed-off-by: Nathan Kidd --- src/xdemos/glxgears_pixmap.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/xdemos/glxgears_pixmap.c b/src/xdemos/glxgears_pixmap.c index f2bb013..afd5828 100644 --- a/src/xdemos/glxgears_pixmap.c +++ b/src/xdemos/glxgears_pixmap.c @@ -540,7 +540,7 @@ main(int argc, char *argv[]) glXDestroyContext(dpy, gears.ctx); XDestroyWindow(dpy, gears.win); - glXDestroyPixmap(dpy, gears.pixmap); + glXDestroyPixmap(dpy, gears.glxpixmap); XFreePixmap(dpy, gears.pixmap); XCloseDisplay(dpy); Reviewed-by: Brian Paul Thanks. Do you need me to commit this for you? Please. I don't have push access. -Nathan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glxgears_pixmap: destroy correct pixmap id
Previously we'd get a GLXBadPixmap error. Signed-off-by: Nathan Kidd --- src/xdemos/glxgears_pixmap.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/xdemos/glxgears_pixmap.c b/src/xdemos/glxgears_pixmap.c index f2bb013..afd5828 100644 --- a/src/xdemos/glxgears_pixmap.c +++ b/src/xdemos/glxgears_pixmap.c @@ -540,7 +540,7 @@ main(int argc, char *argv[]) glXDestroyContext(dpy, gears.ctx); XDestroyWindow(dpy, gears.win); - glXDestroyPixmap(dpy, gears.pixmap); + glXDestroyPixmap(dpy, gears.glxpixmap); XFreePixmap(dpy, gears.pixmap); XCloseDisplay(dpy); -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] docs: gratuitous spelling pass
From: Nathan Kidd
Fixed what I noticed; no warranty for exhaustiveness.
Signed-off-by: Nathan Kidd
---
docs/conform.html|2 +-
docs/devinfo.html|2 +-
docs/dispatch.html | 10 +-
docs/egl.html|8
docs/envvars.html|6 +++---
docs/faq.html|8
docs/opengles.html |4 ++--
docs/openvg.html |2 +-
docs/repository.html |2 +-
docs/shading.html|2 +-
docs/sourcetree.html |2 +-
docs/thanks.html |2 +-
docs/xlibdriver.html |2 +-
13 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/docs/conform.html b/docs/conform.html
index c5f8ece..5593137 100644
--- a/docs/conform.html
+++ b/docs/conform.html
@@ -19,7 +19,7 @@
The SGI OpenGL conformance tests verify correct operation of OpenGL
implementations. I, Brian Paul, have been given a copy of the tests
-for testing Mesa. The tests are not publically available.
+for testing Mesa. The tests are not publicly available.
This file has the latest results of testing Mesa with the OpenGL 1.2
diff --git a/docs/devinfo.html b/docs/devinfo.html
index a9d8b4f..d4a6dfb 100644
--- a/docs/devinfo.html
+++ b/docs/devinfo.html
@@ -206,7 +206,7 @@ exclusively for the older branch.
This "CC" syntax for patch nomination will cause patches to automatically be
copied to the mesa-stable@ mailing list when you use "git send-email" to send
patches to the mesa-dev@ mailing list. Also, if you realize that a commit
-should be nominate for the stable branch after it has already been commited,
+should be nominated for the stable branch after it has already been committed,
you can send a note directly to the mesa-sta...@lists.freedesktop.org where
the Mesa stable-branch maintainers will receive it. Be sure to mention the
commit ID of the commit of interest (as it appears in the mesa master branch).
diff --git a/docs/dispatch.html b/docs/dispatch.html
index 4b529bc..aacd01e 100644
--- a/docs/dispatch.html
+++ b/docs/dispatch.html
@@ -25,7 +25,7 @@ href="#overview">overview of Mesa's implementation.
1. Complexity of GL Dispatch
Every GL application has at least one object called a GL context.
-This object, which is an implicit parameter to ever GL function, stores all
+This object, which is an implicit parameter to every GL function, stores all
of the GL related state for the application. Every texture, every buffer
object, every enable, and much, much more is stored in the context. Since
an application can have more than one context, the context to be used is
@@ -51,7 +51,7 @@ example, glFogCoordf may operate differently
depending on whether
or not fog is enabled.
In multi-threaded environments, it is possible for each thread to have a
-differnt GL context current. This means that poor old glVertex3fv
+different GL context current. This means that poor old glVertex3fv
has to know which GL context is current in the thread where it is being
called.
@@ -207,13 +207,13 @@ few preprocessor defines.
If GLX_USE_TLS is defined, method #4 is used.
If HAVE_PTHREAD is defined, method #3 is used.
If WIN32_THREADS is defined, method #2 is used.
-If none of the preceeding are defined, method #1 is used.
+If none of the preceding are defined, method #1 is used.
Two different techniques are used to handle the various different cases.
On x86 and SPARC, a macro called GL_STUB is used. In the preamble
of the assembly source file different implementations of the macro are
-selected based on the defined preprocessor variables. The assmebly code
+selected based on the defined preprocessor variables. The assembly code
then consists of a series of invocations of the macros such as:
@@ -242,7 +242,7 @@ first technique, is to insert #ifdef within the
assembly
implementation of each function. This makes the assembly file considerably
larger (e.g., 29,332 lines for glapi_x86-64.S versus 1,155 lines for
glapi_x86.S) and causes simple changes to the function
-implementation to generate many lines of diffs. Since the assmebly files
+implementation to generate many lines of diffs. Since the assembly files
are typically generated by scripts (see below), this
isn't a significant problem.
diff --git a/docs/egl.html b/docs/egl.html
index 240cec5..dc23241 100644
--- a/docs/egl.html
+++ b/docs/egl.html
@@ -88,7 +88,7 @@ drivers will be installed to ${libdir}/egl.
List the platforms (window systems) to support. Its argument is a comma
-seprated string such as --with-egl-platforms=x11,drm. It decides
+separated string such as --with-egl-platforms=x11,drm. It decides
the platforms a driver may support. The first listed platform is also used by
the main library to decide the native platform: the platform the EGL native
types such as EGLNativeDisplayType or
@@ -223,7 +223,7 @@ the X server directly using (XCB-)DRI2 protocol.
This driver is based on Gallium3D. It supports all
Re: [Mesa-dev] multiple versions in version string
On 11-06-20 01:22 PM, tom fogal wrote: I am trying to get some regression tests to run in Xvfb. On my workstation, the GL_VERSION string from this is: 1.4 (2.1 Mesa 7.7.1) according to glxinfo. The extensions fairly clearly show 2.x features. Is it perhaps the case that 2.1 features were available in 7.7.1, but not /all/ 2.1 features, and thus this was labelled incorrectly? The version string seems "fixed" in more modern versions. In any case, the above version string breaks projects like GLEW -- one application I have breaks because GLEW doesn't try to load glGenBuffers, thinking it will not be there. A string like the above suggests that GLEW should just try to load whatever it can, and just ignore the version string from the library. Thoughts? From section "3.3.2 GLX Versioning" of the GLX 1.4 spec: " The version string is laid out as follows: Both the major and minor portions of the version number are of arbitrary length. The vendor-specific information is optional. However, if it is present, the format and contents are implementation specific. " So any app that confuses the vendor-specific info for the version major.minor has a bug (though one I've seen before). In the context of debugging problems with indirect GLX those parenthetical versions are quite helpful. -Nathan -- OpenText Connectivity Solutions Group Nathan Kidd http://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 nk...@opentext.com Toll Free: 1 877 359 4866 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] multiple versions in version string
On 11-06-20 03:46 PM, tom fogal wrote: Nathan Kidd writes: On 11-06-20 02:55 PM, tom fogal wrote: Nathan Kidd writes: [snip] You are correct, rendering is indirect! I was unaware that direct vs. indirect limited *GL* features. Why is that the case, and what can be done? Of course, for indirect rendering every glFoo() function call needs to be mapped to (GL)X protocol. Protocol exists up to OpenGL 1.4. Ahh, I had mistakenly believed that the GLX wrapping was somehow generic/automatically specified. Sounds like each function has to be specified explicitly? Presumably by Khronos? Ouch. Yes, though I'm not sure any GLX protocol has been agreed on since the older ARB days. When the gl calls affect state it is harder to automatically generate thecode. (The X server is multiplexing potentially multiple GL clients into the same process and needs to keep switching contexts, etc..) -Nathan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] multiple versions in version string
On 11-06-20 02:55 PM, tom fogal wrote: Nathan Kidd writes: Both the major and minor portions of the version number are of arbitrary length. The vendor-specific information is optional. However, if it is present, the format and contents are implementation specific. " Yes, I know how the version string works in this regard. Side note, you quoted from the GLX spec, but I am actually discussing *GL* version here, not GLX; in any case, the rules are the same as far as I know. Meh, my bad. The "(...)" part of the version string is perhaps a red herring for what I'm trying to bring up: GLEW is telling applications that functionality is not available when it is. The GLEW methodology is based on the beginning (i.e. specified component) of the version string. At least for Mesa 7.7.1, such logic appears to be a bad idea. Any client that wants to push the limits of what's actually available need to query extensions if the version number itself doesn't give what you want. If GLEW is *only* looking at the version number it makes sense to me that it get expanded to also check specific features via extension string. In the context of debugging problems with indirect GLX those parenthetical versions are quite helpful. I did not mean to imply they should be removed (though they have been removed for other reasons in more recent versions of Mesa); I really don't care what's there after the initial version number (as I can't/shouldn't, as per the spec). However, with this version of Mesa, it seems at first glance that one should just ignore the version number /completely/. (quoting from your other mail) You are correct, rendering is indirect! I was unaware that direct vs. indirect limited *GL* features. Why is that the case, and what can be done? I'm just using swrast right now, maybe softpipe in the future; I'm obviously not concerned with speed, I just need something that supports some extensions for use in a regression testing system. Of course, for indirect rendering every glFoo() function call needs to be mapped to (GL)X protocol. Protocol exists up to OpenGL 1.4. There are some features after that that have protocol specified, I believe NVIDIA actually have unofficial protocol up till closer to OpenGL 2.0, but the bottom line is there is no official protocol agreed upon for later GL versions, therefore GLX clamps the GL version number to whatever it can handle. (Why the protocol doesn't exist is, to the best of my knowledge a matter of effort not being invested for features that are considered less useful in the lower-performance indirect context. I'm sure others on this list have a better knowledge of the history there.) -Nathan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] multiple versions in version string
On 11-06-20 01:22 PM, tom fogal wrote: I am trying to get some regression tests to run in Xvfb. On my workstation, the GL_VERSION string from this is: 1.4 (2.1 Mesa 7.7.1) according to glxinfo. The extensions fairly clearly show 2.x features. Is it perhaps the case that 2.1 features were available in 7.7.1, but not /all/ 2.1 features, and thus this was labelled incorrectly? The version string seems "fixed" in more modern versions. In any case, the above version string breaks projects like GLEW -- one application I have breaks because GLEW doesn't try to load glGenBuffers, thinking it will not be there. A string like the above suggests that GLEW should just try to load whatever it can, and just ignore the version string from the library. Thoughts? From section "3.3.2 GLX Versioning" of the GLX 1.4 spec: " The version string is laid out as follows: Both the major and minor portions of the version number are of arbitrary length. The vendor-specific information is optional. However, if it is present, the format and contents are implementation specific. " So any app that confuses the vendor-specific info for the version major.minor has a bug (though one I've seen before). In the context of debugging problems with indirect GLX those parenthetical versions are quite helpful. -Nathan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glapi: Make xserver location error more helpful
From: Nathan Kidd glx code hasn't lived under xserver/GL for a long time now. Signed-off-by: Nathan Kidd --- src/mapi/glapi/gen/Makefile |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/src/mapi/glapi/gen/Makefile b/src/mapi/glapi/gen/Makefile index 87b928c..c3829dc 100644 --- a/src/mapi/glapi/gen/Makefile +++ b/src/mapi/glapi/gen/Makefile @@ -128,7 +128,10 @@ xorg: check-xorg-source $(XORG_OUTPUTS) check-xorg-source: @if ! test -d $(XORG_GLX_DIR); then \ - echo "ERROR: Must specify path to xserver/GL/ checkout; set XORG_BASE env var."; \ + echo "ERROR: Must specify path to xserver/ checkout. Set XORG_BASE env var."; \ + if test x$(XORG_BASE) != x; then \ + echo "'$(XORG_GLX_DIR)' does not exist."; \ + fi; \ exit 1; \ fi -- 1.6.3.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Patch against glxinfo: one line per extension
On 11-01-20 02:35 PM, Alexandre Demers wrote: I'd like to propose a patch against glxinfo. Instead of separating the extensions by a comma, it creates a new line. It's visually easier to read through the extensions. Also, when doing a diff between supported extensions by classic driver and gallium driver, it's a lot simpler to compare the results. Neutral argument: These days there are so many visuals/fbconfigs that you have to pipe into less anyway. Argument against: The useful info like client/server glx versions, vendor, etc. are interspersed between these lists. It will make everyone have to page several times to get the particular lines they want. To me this is a deal-breaker. Being able to diff the extension lists is useful, however, so unless this were an (off by default) option, how about using the work around I use: glxinfo | sed -e 's/, G/\nG/g' -e 's/^ *//' -Nathan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Patch against glxinfo: one line per extension
On 11-01-20 02:35 PM, Alexandre Demers wrote: I'd like to propose a patch against glxinfo. Instead of separating the extensions by a comma, it creates a new line. It's visually easier to read through the extensions. Also, when doing a diff between supported extensions by classic driver and gallium driver, it's a lot simpler to compare the results. Neutral argument: These days there are so many visuals/fbconfigs that you have to pipe into less anyway. Argument against: The useful info like client/server glx versions, vendor, etc. are interspersed between these lists. It will make everyone have to page several times to get the particular lines they want. To me this is a deal-breaker. Being able to diff the extension lists is useful, however, so unless this were an (off by default) option, how about using the work around I use: glxinfo | sed -e 's/, G/\nG/g' -e 's/^ *//' -Nathan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
