Re: [Mesa-dev] [PATCH 3/3] i965: Export format comparison for blitting between miptrees
Hello,
Unfortunately, this patch breaks things further, because...
On Fri, Jun 5, 2015 at 5:14 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
@@ -76,8 +77,14 @@ do_blit_drawpixels(struct gl_context * ctx,
struct gl_renderbuffer *rb = ctx-DrawBuffer-_ColorDrawBuffers[0];
struct intel_renderbuffer *irb = intel_renderbuffer(rb);
- if (!_mesa_format_matches_format_and_type(irb-mt-format, format, type,
- false)) {
+ mesa_format src_format = _mesa_format_from_format_and_type(format, type);
_mesa_format_from_format_and_type may return either mesa_format or
mesa_array_format, which needs further decoding since here we do need
a mesa_format. The attached patch unbreaks this — please apply it for
me if reviewed.
Thanks.
Alexander
From 2078c405133b321610a765e43784f30eddd0e722 Mon Sep 17 00:00:00 2001
From: Alexander Monakov amona...@gmail.com
Date: Tue, 9 Jun 2015 20:58:22 +0300
Subject: [PATCH] i965: do_blit_drawpixels: decode array formats
Correct a regression introduced by commit 922c0c9fd526 by converting array
format, if received from _mesa_format_from_format_and_type, to mesa_format.
References: https://bugs.freedesktop.org/show_bug.cgi?id=90839
Signed-off-by: Alexander Monakov amona...@gmail.com
Tested-by: AnAkkk anakin...@gmail.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/intel_pixel_draw.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_pixel_draw.c
b/src/mesa/drivers/dri/i965/intel_pixel_draw.c
index d39c698..96af286 100644
--- a/src/mesa/drivers/dri/i965/intel_pixel_draw.c
+++ b/src/mesa/drivers/dri/i965/intel_pixel_draw.c
@@ -78,6 +78,8 @@ do_blit_drawpixels(struct gl_context * ctx,
struct intel_renderbuffer *irb = intel_renderbuffer(rb);
mesa_format src_format = _mesa_format_from_format_and_type(format, type);
+ if (_mesa_format_is_mesa_array_format(src_format))
+ src_format = _mesa_format_from_array_format(src_format);
mesa_format dst_format = irb-mt-format;
/* We can safely discard sRGB encode/decode for the DrawPixels interface */
--
2.3.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] i915: Blit RGBX-RGBA drawpixels
On Sun, Jun 7, 2015 at 11:06 AM, Kenneth Graunke kenn...@whitecape.org wrote: On Friday, June 05, 2015 03:14:30 PM Chris Wilson wrote: The blitter already has code to accommodate filling in the alpha channel for BGRX destination formats, so expand this to also allow filling the alpha channgel in RGBX formats. More importantly for the next patch is moving the test into its own function for the purpose of exporting the check to the callers. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Jason Ekstrand ja...@jlekstrand.net Cc: Alexander Monakov amona...@gmail.com Cc: Kristian Høgsberg k...@bitplanet.net Cc: Kenneth Graunke kenn...@whitecape.org With that change, the series is: Reviewed-by: Kenneth Graunke kenn...@whitecape.org Thanks a lot for fixing this, Chris! Is this suitable for 10.5/10.6 backports? Thanks. Alexander ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] i915: Blit RGBX-RGBA drawpixels
On Fri, Jun 5, 2015 at 5:14 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
The blitter already has code to accommodate filling in the alpha channel
for BGRX destination formats, so expand this to also allow filling the
alpha channgel in RGBX formats.
More importantly for the next patch is moving the test into its own
function for the purpose of exporting the check to the callers.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jason Ekstrand ja...@jlekstrand.net
Cc: Alexander Monakov amona...@gmail.com
Cc: Kristian Høgsberg k...@bitplanet.net
Cc: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/intel_blit.c | 38
+++---
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_blit.c
b/src/mesa/drivers/dri/i965/intel_blit.c
index 360bfe8..02666dc 100644
--- a/src/mesa/drivers/dri/i965/intel_blit.c
+++ b/src/mesa/drivers/dri/i965/intel_blit.c
[snip]
@@ -269,12 +290,13 @@ intel_miptree_blit(struct brw_context *brw,
return false;
}
- if (src_mt-format == MESA_FORMAT_B8G8R8X8_UNORM
- dst_mt-format == MESA_FORMAT_B8G8R8A8_UNORM) {
+ /* XXX This could be done in a single pass using XY_FULL_MONO_PATTERN_BLT
*/
+ if (src_format != dst_format
+ (dst_format == MESA_FORMAT_B8G8R8X8_UNORM ||
+dst_format == MESA_FORMAT_R8G8B8X8_UNORM))
This change seems to invert the logic: previously the second pass is
done when dst is BGRA, now it's done if dst is BGRX. Is that intended?
Alexander
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 7/7] i965: Fix handling of MESA_pack_invert in blit (PBO) readpixels.
I wonder if PBO drawpixels in intel_pixel_draw.c needs the same treatment? Thanks. Alexander ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] i965: slow glTexSubImage2D because of Y tiling
Hi, i965 texture fast upload path did not work in 9.2.x due to this tiling change, but was improved for 10.0 release series; however, you need to use GL_UNSIGNED_BYTE format rather than GL_UNSIGNED_INT_8_8_8_8_REV to hit it. With that, upload on 10.0.x should be almost as fast as on 9.1.x. Funny that upload was quite fast with X-tiling on 9.1 even when the fast texture upload path was not used. I believe the reason is that reading the texture on the GPU is faster with Y-tiling (better cache usage), and when a few people noticed the upload speed regression it was too late. Finally, please note that PBO-based glDrawPixels is no longer slow after this patch (to appear in 10.1 release): http://cgit.freedesktop.org/mesa/mesa/commit/src/mesa/drivers/dri/i965/intel_pixel_draw.c?id=279e8d264109303f0e8248ab4c3703c71f65983f (primus switches to PBO glDrawPixels when detects it to be fast). Cheers. Alexander ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: implement blit path for PBO glDrawPixels
Ping. A week ago a few people who looked at the older version of this patch posted on IRC didn't point out obvious flaws. Can this get a review please? On Mon, Nov 4, 2013 at 1:34 AM, Alexander Monakov amona...@gmail.com wrote: Hello, This patch implements accelerated path for glDrawPixels from a PBO in i965. The code follows what intel_pixel_read, intel_pixel_copy, intel_pixel_bitmap and intel_tex_image are doing. Piglit quick.tests show no regressions. In my testing on IVB, performance improvement is huge (about 30x, didn't measure exactly) since generic path goes via _mesa_unpack_color_span_float, memcpy, extract_float_rgba. I don't have commit access so please commit the patch for me if approved. Thanks. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: implement blit path for PBO glDrawPixels
Hello,
This patch implements accelerated path for glDrawPixels from a PBO in
i965. The code follows what intel_pixel_read, intel_pixel_copy,
intel_pixel_bitmap and intel_tex_image are doing. Piglit quick.tests
show no regressions. In my testing on IVB, performance improvement is
huge (about 30x, didn't measure exactly) since generic path goes via
_mesa_unpack_color_span_float, memcpy, extract_float_rgba.
I don't have commit access so please commit the patch for me if approved.
Thanks.
From 1c469f60799528027abbc08a6ddd02b6b19a5a36 Mon Sep 17 00:00:00 2001
From: Alexander Monakov amona...@ispras.ru
Date: Mon, 4 Nov 2013 01:12:13 +0400
Subject: [PATCH] i965: implement blit path for PBO glDrawPixels
Signed-off-by: Alexander Monakov amona...@ispras.ru
---
src/mesa/drivers/dri/i965/intel_pixel.c | 5 ++
src/mesa/drivers/dri/i965/intel_pixel_draw.c | 115 +++
2 files changed, 120 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_pixel.c
b/src/mesa/drivers/dri/i965/intel_pixel.c
index 623f4f4..fc70381 100644
--- a/src/mesa/drivers/dri/i965/intel_pixel.c
+++ b/src/mesa/drivers/dri/i965/intel_pixel.c
@@ -115,6 +115,11 @@ intel_check_blit_fragment_ops(struct gl_context * ctx,
bool src_alpha_is_one)
return false;
}
+ if (ctx-Pixel.ZoomX != 1.0F || ctx-Pixel.ZoomY != 1.0F) {
+ DBG(fallback due to pixel zoom\n);
+ return false;
+ }
+
if (ctx-RenderMode != GL_RENDER) {
DBG(fallback due to render mode\n);
return false;
diff --git a/src/mesa/drivers/dri/i965/intel_pixel_draw.c
b/src/mesa/drivers/dri/i965/intel_pixel_draw.c
index af618a2..477586e 100644
--- a/src/mesa/drivers/dri/i965/intel_pixel_draw.c
+++ b/src/mesa/drivers/dri/i965/intel_pixel_draw.c
@@ -29,14 +29,115 @@
#include main/enums.h
#include main/image.h
#include main/mtypes.h
+#include main/condrender.h
+#include main/fbobject.h
#include main/teximage.h
#include main/texobj.h
#include main/texstate.h
+#include main/bufferobj.h
#include swrast/swrast.h
#include drivers/common/meta.h
#include brw_context.h
+#include intel_screen.h
+#include intel_blit.h
+#include intel_buffers.h
+#include intel_fbo.h
+#include intel_mipmap_tree.h
+#include intel_regions.h
#include intel_pixel.h
+#include intel_buffer_objects.h
+
+#define FILE_DEBUG_FLAG DEBUG_PIXEL
+
+static bool
+do_blit_drawpixels(struct gl_context * ctx,
+ GLint x, GLint y, GLsizei width, GLsizei height,
+ GLenum format, GLenum type,
+ const struct gl_pixelstore_attrib *unpack,
+ const GLvoid * pixels)
+{
+ struct brw_context *brw = brw_context(ctx);
+ struct intel_buffer_object *src = intel_buffer_object(unpack-BufferObj);
+ GLuint src_offset;
+ drm_intel_bo *src_buffer;
+
+ DBG(%s\n, __FUNCTION__);
+
+ if (!intel_check_blit_fragment_ops(ctx, false))
+ return false;
+
+ if (ctx-DrawBuffer-_NumColorDrawBuffers != 1) {
+ DBG(%s: fallback due to MRT\n, __FUNCTION__);
+ return false;
+ }
+
+ struct gl_renderbuffer *rb = ctx-DrawBuffer-_ColorDrawBuffers[0];
+ struct intel_renderbuffer *irb = intel_renderbuffer(rb);
+
+ if (!_mesa_format_matches_format_and_type(irb-mt-format, format, type,
+ false)) {
+ DBG(%s: bad format for blit\n, __FUNCTION__);
+ return false;
+ }
+
+ if (unpack-SwapBytes || unpack-LsbFirst ||
+ unpack-SkipPixels || unpack-SkipRows) {
+ DBG(%s: bad packing params\n, __FUNCTION__);
+ return false;
+ }
+
+ int src_stride = _mesa_image_row_stride(unpack, width, format, type);
+ bool src_flip = false;
+ /* Mesa flips the src_stride for unpack-Invert, but we want our mt to have
+* a normal src_stride.
+*/
+ if (unpack-Invert) {
+ src_stride = -src_stride;
+ src_flip = true;
+ }
+
+ src_offset = (GLintptr)pixels;
+ src_offset += _mesa_image_offset(2, unpack, width, height,
+ format, type, 0, 0, 0);
+
+ intel_prepare_render(brw);
+
+ src_buffer = intel_bufferobj_buffer(brw, src,
+ src_offset, width * height *
+ irb-mt-cpp);
+
+ struct intel_mipmap_tree *pbo_mt =
+ intel_miptree_create_for_bo(brw,
+ src_buffer,
+ irb-mt-format,
+ src_offset,
+ width, height,
+ src_stride, I915_TILING_NONE);
+ if (!pbo_mt)
+ return false;
+
+ if (!intel_miptree_blit(brw,
+ pbo_mt, 0, 0,
+ 0, 0, src_flip,
+ irb-mt, irb-mt_level, irb-mt_layer,
+ x, y, _mesa_is_winsys_fbo(ctx-DrawBuffer),
+ width, height, GL_COPY)) {
+ DBG(%s: blit failed\n, __FUNCTION__);
+ intel_miptree_release
Re: [Mesa-dev] [PATCH] Fix for throwing BadDrawable (invalid Pixmap or Window parameter) by Xserver
On Thu, Sep 5, 2013 at 6:25 PM, Maniak, Lukasz lukasz.man...@intel.com wrote: Original explanatory text: Fix for throwing BadDrawable (invalid Pixmap or Window parameter) by Xserver when calling XCreatePixmap or fill_bitmap from DRI_glXUseXFont. currentDrawable which came from __glXGetCurrentContext was not correct in this case, we use DefaultRootWindow(dpy) instead. To reproduce this error you just have to call this: dpy = (machine.display)-handle(); fontStruct = XLoadQueryFont(dpy, fixed); int firstGlyph = fontStruct-min_char_or_byte2; int dispListBase = 1; glXUseXFont(fontStruct-fid, firstGlyph, 1, dispListBase); But it doesn't make sense to call glXUseXFont without a current context. And you will get this: X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 53 (X_CreatePixmap) Feedback from CC reporters would be really helpful. Ian added me as the reporter of bug 54080, but that issue does not reference glXUseXFont at all. Alexander ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix for throwing BadDrawable (invalid Pixmap or Window parameter) by Xserver
On Thu, Sep 5, 2013 at 6:40 PM, Alexander Monakov amona...@gmail.com wrote: But it doesn't make sense to call glXUseXFont without a current context. However ARB_create_context allows to make a context current without an associated drawable. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix glXChooseFBConfig with GLX_DRAWABLE_TYPE GLX_DONT_CARE
On Thu, Apr 4, 2013 at 1:02 AM, Ian Romanick i...@freedesktop.org wrote:
Reveiwed-by: Ian Romanick ian.d.roman...@intel.com
Please add the following lines to the commit message:
NOTE: This is a candidate for stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47478
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62999
Bugzilla: http://bugs.winehq.org/show_bug.cgi?id=26763
Done. I don't have git write access, can you push it for me?
From e19c1fcfdd72fc3f87908db77808f65be5000843 Mon Sep 17 00:00:00 2001
From: Alexander Monakov amona...@ispras.ru
Date: Tue, 2 Apr 2013 01:38:27 +0400
Subject: [PATCH] Honor GLX_DONT_CARE in MATCH_MASK
NOTE: This is a candidate for stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47478
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62999
Bugzilla: http://bugs.winehq.org/show_bug.cgi?id=26763
---
src/glx/glxcmds.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 7b62be3..5c79073 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -912,8 +912,10 @@ init_fbconfig_for_chooser(struct glx_config * config,
/* Test that all bits from a are contained in b */
#define MATCH_MASK(param) \
do { \
-if ((a-param ~b-param) != 0) \
+if ( ((int) a- param != (int) GLX_DONT_CARE) \
+ ((a-param ~b-param) != 0) ) { \
return False;\
+} \
} while (0);
/**
--
1.7.11.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Fix glXChooseFBConfig with GLX_DRAWABLE_TYPE GLX_DONT_CARE
https://bugs.freedesktop.org/show_bug.cgi?id=47478
https://bugs.freedesktop.org/show_bug.cgi?id=62999 (dup of the above)
I don't have commit access so please push if OK.
From 3e23a23ec8a3bc36e13efc7cf95229e9e31955f1 Mon Sep 17 00:00:00 2001
From: Alexander Monakov amona...@gmail.com
Date: Mon, 1 Apr 2013 23:00:10 +0400
Subject: [PATCH] Honor GLX_DONT_CARE in MATCH_EXACT and MATCH_MASK
This makes MATCH_EXACT the same as MATCH_DONT_CARE, so eliminate the latter
and use the former.
---
src/glx/glxcmds.c | 39 +--
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 7b62be3..992d3a5 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -886,14 +886,6 @@ init_fbconfig_for_chooser(struct glx_config * config,
config-swapMethod = GLX_DONT_CARE;
}
-#define MATCH_DONT_CARE( param )\
- do { \
-if ( ((int) a- param != (int) GLX_DONT_CARE) \
- (a- param != b- param) ) {\
- return False; \
-} \
- } while ( 0 )
-
#define MATCH_MINIMUM( param ) \
do { \
if ( ((int) a- param != (int) GLX_DONT_CARE) \
@@ -904,7 +896,8 @@ init_fbconfig_for_chooser(struct glx_config * config,
#define MATCH_EXACT( param )\
do { \
-if ( a- param != b- param) { \
+if ( ((int) a- param != (int) GLX_DONT_CARE) \
+ (a- param != b- param) ) {\
return False; \
} \
} while ( 0 )
@@ -912,8 +905,10 @@ init_fbconfig_for_chooser(struct glx_config * config,
/* Test that all bits from a are contained in b */
#define MATCH_MASK(param) \
do { \
-if ((a-param ~b-param) != 0) \
+if ( ((int) a- param != (int) GLX_DONT_CARE) \
+ ((a-param ~b-param) != 0) ) { \
return False;\
+} \
} while (0);
/**
@@ -926,12 +921,12 @@ static Bool
fbconfigs_compatible(const struct glx_config * const a,
const struct glx_config * const b)
{
- MATCH_DONT_CARE(doubleBufferMode);
- MATCH_DONT_CARE(visualType);
- MATCH_DONT_CARE(visualRating);
- MATCH_DONT_CARE(xRenderable);
- MATCH_DONT_CARE(fbconfigID);
- MATCH_DONT_CARE(swapMethod);
+ MATCH_EXACT(doubleBufferMode);
+ MATCH_EXACT(visualType);
+ MATCH_EXACT(visualRating);
+ MATCH_EXACT(xRenderable);
+ MATCH_EXACT(fbconfigID);
+ MATCH_EXACT(swapMethod);
MATCH_MINIMUM(rgbBits);
MATCH_MINIMUM(numAuxBuffers);
@@ -951,7 +946,7 @@ fbconfigs_compatible(const struct glx_config * const a,
MATCH_MINIMUM(maxPbufferPixels);
MATCH_MINIMUM(samples);
- MATCH_DONT_CARE(stereoMode);
+ MATCH_EXACT(stereoMode);
MATCH_EXACT(level);
MATCH_MASK(drawableType);
@@ -978,14 +973,14 @@ fbconfigs_compatible(const struct glx_config * const a,
switch (a-transparentPixel) {
case GLX_TRANSPARENT_RGB:
- MATCH_DONT_CARE(transparentRed);
- MATCH_DONT_CARE(transparentGreen);
- MATCH_DONT_CARE(transparentBlue);
- MATCH_DONT_CARE(transparentAlpha);
+ MATCH_EXACT(transparentRed);
+ MATCH_EXACT(transparentGreen);
+ MATCH_EXACT(transparentBlue);
+ MATCH_EXACT(transparentAlpha);
break;
case GLX_TRANSPARENT_INDEX:
- MATCH_DONT_CARE(transparentIndex);
+ MATCH_EXACT(transparentIndex);
break;
default:
--
1.7.11.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix glXChooseFBConfig with GLX_DRAWABLE_TYPE GLX_DONT_CARE
On Mon, Apr 1, 2013 at 11:05 PM, Alexander Monakov amona...@gmail.com wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=47478
https://bugs.freedesktop.org/show_bug.cgi?id=62999 (dup of the above)
I don't have commit access so please push if OK.
Hm, now I see that MATCH_EXACT is used only in special cases, and my
attempt was too eager. Only MATCH_MASK needs fixing. Attaching
adjusted patch.
From 117cf9951c6b67aa4500a9e8f70afac8fcdafeed Mon Sep 17 00:00:00 2001
From: Alexander Monakov amona...@ispras.ru
Date: Tue, 2 Apr 2013 01:38:27 +0400
Subject: [PATCH] Honor GLX_DONT_CARE in MATCH_MASK
---
src/glx/glxcmds.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 7b62be3..5c79073 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -912,8 +912,10 @@ init_fbconfig_for_chooser(struct glx_config * config,
/* Test that all bits from a are contained in b */
#define MATCH_MASK(param) \
do { \
-if ((a-param ~b-param) != 0) \
+if ( ((int) a- param != (int) GLX_DONT_CARE) \
+ ((a-param ~b-param) != 0) ) { \
return False;\
+} \
} while (0);
/**
--
1.7.11.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
I feel rather awkward asking, but: why implement this inside of
Gallium, instead of as a standalone {egl,glX}SwapBuffers interceptor
obtaining counter values via GL extensions, such as
ARB_occlusion_query or AMD_performance_monitor? That way Intel (and
Nouveau?) people could also benefit from it.
Best regards,
Alexander
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] texobj: add verbose api trace messages to several routines
On Mon, 4 Mar 2013, Carl Worth wrote: I don't think it should be too hard to get this to work, (though it may require a source change to the Steam overlay). I'll do some more experiments tomorrow and see if I can't make a concrete recommendation to be able to give to Valve as a bug report. And, obviously, if there's something we can do to make apitrace more robust here, I'll submit that change as well. I faced a similar issue in my lightweight OpenGL offloading via GLX forking project, primus [1], and I'm successfully using the following approach: 1) The interposition is based on LD_LIBRARY_PATH augmentation, LD_PRELOAD is not employed. Pro: no ugly tricks with dlopen/dlsym interposition. Contra: the interposer needs to know the path to the real OpenGL library. For APITrace, /usr/$LIB/libGL.so.1 will usually be a working default choice (NB: $LIB is a special token expanded by the dynamic loader, not the shell). 2) Specifically in order to work with the Steam overlay, the interposer *protects itself from dlsym interposition* by using real_dlsym = dlsym(dlopen(libdl.so.2), dlsym). Similar protection against dlopen interposition would also make sense. Hope that helps, Alexander [1] https://github.com/amonakov/primus ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] texobj: add verbose api trace messages to several routines
On Tue, 5 Mar 2013, Jose Fonseca wrote: I expected that when one sets TRACE_LIBGL env var with the path for the true libGL.so.1, then apitrace wouldn't be picking up symbols the overlay -- it would be taking symbols only from the true libGL.so, there avoiding infinite recursion. ... unless the overlay interposes dlsym and/or dlopen -- which it does, like apitrace, and virtualgl, and glc, and what not. This eternal battle for dominating symbols is quite depressing. Proper support in the dynamic loader for wrapper libraries would help immensely here. Alexander ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] texobj: add verbose api trace messages to several routines
On Tue, 5 Mar 2013, Jose Fonseca wrote: $LIB is a neat idea. But does it work on debian/ubuntu systems, where mesa/NVIDIA libGL.so are put in different paths , which are then chosen via /etc/ld.so.conf*? I think Debian installs a symlink to the active libGL in /usr/lib. Not sure about Ubuntu; it's painful in other ways, e.g. until 13.04 their loader expanded $LIB differently so it needed /usr/lib/$LIB. However, the point seems moot as ... But of course, apitrace trace could easily just do dlopen(libGL.so.1) and fill TRACE_LIBGL env var with it. ... this looks like a better approach anyhow. There is no guarantee that when we do real_dlsym = dlsym(dlopen(libdl.so.2), dlsym) that a fake_dlsym or a fake_dlopen doesn't return itself. But I suppose it can't hurt. Yes, VirtualGL may inject a dlopen interposer capable of doing just that, but at least that's avoidable. It also makes efforts to prevent mutual recursion. Alexander ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC] primus: PoC client-side GPU offloading
Greetings, Mesa hackers, I've hacked together a small (~500 sloc) preloadable library that implements OpenGL offloading by means of GLX forking, similar to VirtualGL. The basic idea is to track contexts and drawables and create shadow contexts and pbuffers on the secondary X server, redirecting all GL commands there; on glXSwapBuffers, perform readback and display. However, primus assumes that both X servers are on the local machine, which allows to eliminate copying and use a direct rendering context for displaying the rendered buffer as well. With recent Mesa git, I see decent performance with i965 dri and nvidia blob (it's cool that with a small hack it's possible to load both libraries in one address space and use direct contexts from different threads). I have a few questions: 1. primus needs to load libglapi explicitly with RTLD_GLOBAL, otherwise DRI modules (e.g. i965_dri.so) cannot find symbols defined in that library. Is that how it's supposed to be? Should DRI modules link against libglapi? 2. How should window resizes be handled? Should I call XGetGeometry every frame to check if size changed? 3. Is there a way to discover from what path the font was loaded when given just a Font XID in glXUseXFont? Even though this project may seem a little late given that PRIME has gained traction, I hope that it may serve as a benchmark for PRIME offloading, and maybe even as a real offloading solution in the meantime given enough bugfixing effort. The project is hosted at https://github.com/amonakov/primus Thanks. Alexander ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
