Re: [Mesa-dev] [PATCH 3/3] glx/dri3: Request non-vsynced Present for swapinterval zero.
On 12/16/2014 11:22 PM, Mathias Fröhlich wrote: Hi, On Tuesday, December 16, 2014 19:30:04 Mario Kleiner wrote: Hmm. For benchmarking i think i'd consider that a mild form of cheating. You get higher fps because you skip processing like the whole gpu blit overhead and host processing overhead for queuing / validating / processing the copy command in the command stream, so the benchmark numbers don't translate very well anymore in how the system would behave in a non-benchmark situation? Agree, sounds somehow like cheating. Nevertheless, I think I have observed the nvidia blob doing the same and probably even more under some circumstance. I could get framerates Really? Do you have a link to a report of this, or some description of how this happened? I could see it happen if you're running a composite manager, but that's only because the application can render to its redirected window as fast as it wants, but it's up to the compositor to sample those frames at its own pace. If that's the scenario you're thinking of, then it's just a side effect of the non-Present compositor design. there that I could not explain by issuing the same draw as before with the buffer swap only being scheduled every n frames. So, if you think about this, it sounds like cheating even more. There is not only the savings that you mentioned with the swap not happening. That's what the test application in this case already did to trigger the effect. Looking at this I thought that if a buffer swap is scheduled, even the draws that are not yet executed on the gpu and belonging to previous swaps that are now hidden by the now scheduled swap are skipped. Sure, if doing this you need to be careful if something else that must be measurable by the application like reading back buffer data happens in between. I have never tried to drive a verification of this interpretation to the end, so I may be wrong. But I ever thought that this sounds like the main reason why some gl drivers can draw so much more gears a second then others can - just don't draw the ones that are already proven not to be observable anymore by the application or user. So, yes, this is kind of cheating. ... probably not the only 'cheat' for a GL driver to be fast in a lot of 'benchmarks'. Greetings Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glxgears: Honor -fullscreen in initial reshape
If glxgears is started on a bare X server without a window manager, it does not
get a ConfigureNotify event. This means that the only time the viewport is
initialized is in main, when it calls reshape(winWidth, winHeight). This does
not take the size mangling caused by -fullscreen into account, so the gears
appear in a 300x300 box in the lower-left corner of the window instead of
filling the window as intended.
Fix this by moving the size override from make_window to main, and pass the
overridden size to both make_window and the initial reshape.
Signed-off-by: Aaron Plattner aplatt...@nvidia.com
---
src/xdemos/glxgears.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/xdemos/glxgears.c b/src/xdemos/glxgears.c
index 79b7226..2089715 100644
--- a/src/xdemos/glxgears.c
+++ b/src/xdemos/glxgears.c
@@ -517,12 +517,6 @@ make_window( Display *dpy, const char *name,
scrnum = DefaultScreen( dpy );
root = RootWindow( dpy, scrnum );
- if (fullscreen) {
- x = 0; y = 0;
- width = DisplayWidth( dpy, scrnum );
- height = DisplayHeight( dpy, scrnum );
- }
-
visinfo = glXChooseVisual(dpy, scrnum, attribs);
if (!visinfo) {
printf(Error: couldn't get an RGB, Double-buffered);
@@ -770,6 +764,14 @@ main(int argc, char *argv[])
return -1;
}
+ if (fullscreen) {
+ int scrnum = DefaultScreen(dpy);
+
+ x = 0; y = 0;
+ winWidth = DisplayWidth(dpy, scrnum);
+ winHeight = DisplayHeight(dpy, scrnum);
+ }
+
make_window(dpy, glxgears, x, y, winWidth, winHeight, win, ctx);
XMapWindow(dpy, win);
glXMakeCurrent(dpy, win, ctx);
--
1.7.12
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ANNOUNCE] New mailing list for VDPAU discussion
For those interested in VDPAU, I've created a new mailing list, vd...@lists.freedesktop.org. http://lists.freedesktop.org/mailman/listinfo/vdpau -- Aaron ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] Fix indirect fallback when a non-Mesa GLX extension is present.
When driCreateScreen calls driConvertConfigs to try to convert the configs for swrast, it fails and returns NULL. Instead of checking, it just clobbers psc-base.configs. Then, when the application asks for the FBconfigs, there aren't any. Instead, make the caller responsible for freeing the old modes lists if both calls to driConvertConfigs succeed. Without the second fix, glxinfo fails unless you run it with LIBGL_ALWAYS_INDIRECT: $ glxinfo name of display: :0.0 Error: couldn't find RGB GLX visual or fbconfig $ LIBGL_ALWAYS_INDIRECT=1 glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No (LIBGL_ALWAYS_INDIRECT set) server glx vendor string: NVIDIA Corporation server glx version string: 1.4 [...] Signed-off-by: Aaron Plattner aplatt...@nvidia.com --- This is a rebased version of [1], which was never applied (possibly because I forgot to send out a version that didn't accidentally revert the change to glxext.c). [1] http://lists.freedesktop.org/archives/mesa-dev/2010-April/000200.html src/glx/dri2_glx.c | 23 +++ src/glx/dri_common.c |2 -- src/glx/dri_glx.c| 21 - src/glx/drisw_glx.c | 23 +++ 4 files changed, 54 insertions(+), 15 deletions(-) diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c index 940626c..553869a 100644 --- a/src/glx/dri2_glx.c +++ b/src/glx/dri2_glx.c @@ -865,6 +865,7 @@ dri2CreateScreen(int screen, struct glx_display * priv) priv-dri2Display; struct dri2_screen *psc; __GLXDRIscreen *psp; + struct glx_config *configs = NULL, *visuals = NULL; char *driverName, *deviceName; drm_magic_t magic; int i; @@ -947,10 +948,16 @@ dri2CreateScreen(int screen, struct glx_display * priv) extensions = psc-core-getExtensions(psc-driScreen); dri2BindExtensions(psc, extensions); - psc-base.configs = - driConvertConfigs(psc-core, psc-base.configs, driver_configs); - psc-base.visuals = - driConvertConfigs(psc-core, psc-base.visuals, driver_configs); + configs = driConvertConfigs(psc-core, psc-base.configs, driver_configs); + visuals = driConvertConfigs(psc-core, psc-base.visuals, driver_configs); + + if (!configs || !visuals) + goto handle_error; + + glx_config_destroy_list(psc-base.configs); + psc-base.configs = configs; + glx_config_destroy_list(psc-base.visuals); + psc-base.visuals = visuals; psc-driver_configs = driver_configs; @@ -994,10 +1001,18 @@ dri2CreateScreen(int screen, struct glx_display * priv) return psc-base; handle_error: + if (configs) + glx_config_destroy_list(configs); + if (visuals) + glx_config_destroy_list(visuals); + if (psc-driScreen) + psc-core-destroyScreen(psc-driScreen); + psc-driScreen = NULL; if (psc-fd = 0) close(psc-fd); if (psc-driver) dlclose(psc-driver); + Xfree(driverName); Xfree(deviceName); glx_screen_cleanup(psc-base); diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c index eb62c82..1482b88 100644 --- a/src/glx/dri_common.c +++ b/src/glx/dri_common.c @@ -340,8 +340,6 @@ driConvertConfigs(const __DRIcoreExtension * core, tail = tail-next; } - glx_config_destroy_list(configs); - return head.next; } diff --git a/src/glx/dri_glx.c b/src/glx/dri_glx.c index a52159c..666423a 100644 --- a/src/glx/dri_glx.c +++ b/src/glx/dri_glx.c @@ -336,7 +336,7 @@ CallCreateNewScreen(Display *dpy, int scrn, struct dri_screen *psc, drm_handle_t hFB; int junk; const __DRIconfig **driver_configs; - struct glx_config *visual; + struct glx_config *visual, *configs = NULL, *visuals = NULL; /* DRI protocol version. */ dri_version.major = driDpy-driMajor; @@ -446,10 +446,16 @@ CallCreateNewScreen(Display *dpy, int scrn, struct dri_screen *psc, goto handle_error; } - psc-base.configs = - driConvertConfigs(psc-core, psc-base.configs, driver_configs); - psc-base.visuals = - driConvertConfigs(psc-core, psc-base.visuals, driver_configs); + configs = driConvertConfigs(psc-core, psc-base.configs, driver_configs); + visuals = driConvertConfigs(psc-core, psc-base.visuals, driver_configs); + + if (!configs || !visuals) + goto handle_error; + + glx_config_destroy_list(psc-base.configs); + psc-base.configs = configs; + glx_config_destroy_list(psc-base.visuals); + psc-base.visuals = visuals; psc-driver_configs = driver_configs; @@ -478,6 +484,11 @@ CallCreateNewScreen(Display *dpy, int scrn, struct dri_screen *psc, return psp; handle_error: + if (configs) + glx_config_destroy_list(configs); + if (visuals) + glx_config_destroy_list(visuals); + if (pSAREA != MAP_FAILED) drmUnmap(pSAREA, SAREA_MAX); diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c index a150c61..fbc6be2 100644 --- a/src/glx/drisw_glx.c +++ b/src/glx/drisw_glx.c @@ -524,6 +524,7
Re: [Mesa-dev] [PATCH 1/2] Fix __glXInitializeVisualConfigFromTags's handling of unrecognized fbconfig tags.
On Sun, May 02, 2010 at 02:39:07AM -0700, Dave Airlie wrote: On Fri, Apr 23, 2010 at 2:30 AM, Aaron Plattner aplatt...@nvidia.com wrote: __glXInitializeVisualConfigFromTags doesn't skip the payload of unrecognized tags. Instead, it treats the value as if it were the next tag, which can happen if the server's GLX extension is not Mesa's. For example, this falls down when NVIDIA sends a GLX_FLOAT_COMPONENTS_NV = 0 pair, causing __glXInitializeVisualConfigFromTags to bail out early. I've had a regression reported on irc from papillon81 with GLX_USE_GL and OpenSceneGraph bisected to this. The spec is pretty clear about the attribute format for protocol: (for visuals) The first 18 properties are ordered; the remaining properties consist of a property type and a property value. (for fbconfigs) The properties consist of a property type and a property value. You use __glXInitializeVisualConfigFromTags in glXChooseVisual, don't you? I think you need something like fbconfig_style_tags bp++; Or I guess you could just hope that the server never sends GLX_USE_GL as a visual or FBconfig property. I'm guessing we need something like the attached. Dave. Signed-off-by: Aaron Plattner aplatt...@nvidia.com --- src/glx/glxext.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/glx/glxext.c b/src/glx/glxext.c index 5289354..6d6f89e 100644 --- a/src/glx/glxext.c +++ b/src/glx/glxext.c @@ -539,6 +539,8 @@ __glXInitializeVisualConfigFromTags(__GLcontextModes * config, int count, i = count; break; default: + /* Ignore the unrecognized tag's value */ + bp++; break; } } -- 1.6.3.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
