[cairo] Threaded animation with cairo_gl backend over a GtkWidget
Henry (Yu) Song - SISA
hsong at sisa.samsung.com
Wed Jan 16 07:34:28 PST 2013
Hi, Carlos
No need to change code. msaa compositor will fallback to spans and traps compositor if it detects driver does not support HW msaa.
Thanks
Henry
________________________________
From: Carlos López González [genetita at gmail.com]
Sent: Tuesday, January 15, 2013 11:44 PM
To: Henry (Yu) Song - SISA; cairo at cairographics.org
Subject: Re: [cairo] Threaded animation with cairo_gl backend over a GtkWidget
Hi Henry,
2013/1/16 Henry (Yu) Song - SISA <hsong at sisa.samsung.com<mailto:hsong at sisa.samsung.com>>
Hi, Carlos
export PKG_CONFIG_PATH=/usr/local/lib/pkg - assuming you "configure --prefix=/usr/local" I don't use cmake and seldom use xcode. Could not help you there.
It is fine, I'll fix that the same way than I did with my example.
In addition to my sample test program, you can perform cairo tests on nsgl, "make test TARGETS=nsgl"
Ok.
cairo-gles does not have new API - it implements a msaa compositor which uses HW MSAA for antialising. So it is much faster than existing spans/traps compositor, plus it is more stable. cairo-gles name is probably misleading. It is not gles only, it supports GLX/OpenGL and EGL/GLES, and if you apply my NSGL patches to it, it supports NSOpenGL too.
cairo_gl_surface APIs are all defined in cairo-gl.h
So does it mean that if I use the cairo version from the mentioned cairogles repository instead of the official release of cairo and add the proper environment variables that you mentioned before, I can still using the same code for my cairo-sample file? (assuming that I have a graphic card/driver with MSAA capable)
Henry
________________________________
From: Carlos López González [genetita at gmail.com<mailto:genetita at gmail.com>]
Sent: Tuesday, January 15, 2013 11:22 PM
To: Henry (Yu) Song - SISA
Subject: Re: [cairo] Threaded animation with cairo_gl backend over a GtkWidget
Hi Henry,
I'd be glad on test your development cairo-nsgl but I want to confirm first the steps to do:
1) git clone cairo-nsgl.
2) build cairo-nsgl with nsgl support with gl support and without glx support based on your provided command line. I would install into a personal folder: /Users/carlos/Software/cairo-nsgl
3) compile your cairo-nsgl-fill.m file using your provided compile command.
I have some doubts (excuse me if I'm asking silly simple things):
How could pkg-config find where I installed the cario-nsgl code?
In my example I used cmake to let pkg-config macro to find the local compiled version of
cairo (see my CMakeLists.txt file) by adding the search path to the local compiled version
of cairo:
set(CMAKE_PREFIX_PATH "/Users/carlos/Software/cairo")
I think that I better use cmake to make possible to find cairo-nsgl properly. In that case, for me,
it is more convenient to generate XCode project files directly from cmake because I can run and
debug directly from XCode. In this case it might be better to use the native Objective-C compiler
which is Clang. Is that right?
Regarding to the original issue, I'll test your suggestions from the previous email and will
test the same changes made for the laptop to the iMac.
But again, in case I want to use cairogles, what's the API? I can't find any cairo-gles.h file
or similar on the http://code.google.com/p/cairogles sources. Any idea?
Thanks, Carlos
2013/1/16 Henry (Yu) Song - SISA <hsong at sisa.samsung.com<mailto:hsong at sisa.samsung.com>>
I also created a cairo to NSOpenGLContext binding such that you don't need glx, gtk on mac, you can use cocoa directly. It is located https://github.com/csyuschmjuh/cairo-nsgl, I need someone to test/confirm its is working - NSView is working, but not implemented for virtual screen yet.
To compile for nsopengl on mac "./configure --prefix=/your_install_directory --enable-gl=yes --enable-glx=no --enable-nsgl=yes"
To compile for glx on mac "./configure --prefix=/your_install_directory --enable-gl=yes"
Attached is the cocoa-based sample code with cairo. compile it with "gcc -o cairo-nsgl-fill cairo-nsgl-fill.m `pkg-config --libs --cflags cairo` -framework OpenGL -framework AppKit"
Thanks
Henry
________________________________
From: cairo-bounces+hsong=sisa.samsung.com at cairographics.org<mailto:sisa.samsung.com at cairographics.org> [cairo-bounces+hsong=sisa.samsung.com at cairographics.org<mailto:sisa.samsung.com at cairographics.org>] on behalf of Henry (Yu) Song - SISA [hsong at sisa.samsung.com<mailto:hsong at sisa.samsung.com>]
Sent: Tuesday, January 15, 2013 3:43 PM
To: Carlos López González
Cc: cairo at cairographics.org<mailto:cairo at cairographics.org>
Subject: Re: [cairo] Threaded animation with cairo_gl backend over a GtkWidget
You are using a driver that does not support window/pixmap multisampling. Remove GLX_SAMPLE_BUFFERS and GLX_SAMPLES, that should work for you.
cairo-gles supports both glx/gl and egl/gles. You still can use MSAA for rendering to texture, but you will fallback to spans/traps compositors for rendering to pixmap/window because your driver does not support msaa on window/pixmap.
In your sample, you are creating a texture-based gl_surface, I am not sure what kind of surface is created by gdk binding to cairo - most likely it is an image surface. in that case, you will get a performance hit by downloading texture to image in system memory.
Henry
________________________________
From: Carlos López González [genetita at gmail.com<mailto:genetita at gmail.com>]
Sent: Tuesday, January 15, 2013 3:04 PM
To: Henry (Yu) Song - SISA
Cc: cairo at cairographics.org<mailto:cairo at cairographics.org>
Subject: Re: [cairo] Threaded animation with cairo_gl backend over a GtkWidget
The code modifications applied to the laptop gives a null surface because glXChooseVisual returns a NULL pointer when creating the XVisualInfo for the modified attributes. Possibly my graphic card doesn't support those requirements.
Attached are the glxinfo output and the interesting line from lspci.
I'll test it on OSX tomorrow.
Thanks!
2013/1/15 Carlos López González <genetita at gmail.com<mailto:genetita at gmail.com>>
Hi Henry,
thank you very much for your detailed reply and the code additions. I'll give it a try and would let you know the results.
I considered cairogles but isn't it created for embedded systems? When it were added upstream, would it be suitable to be used in non embedded system?
In case of use cairogles, where can I find its API?
Thanks!
2013/1/15 Henry (Yu) Song - SISA <hsong at sisa.samsung.com<mailto:hsong at sisa.samsung.com>>
I modified your code a little as attached. Two changes
1. add cairo_gl_device_set_thread_aware ()
2. add GLX_SAMPLES/GLX_SAMPLE_BUFFER
1. The first add is to reduce GL context switch if you have dedicated one thread for rendering (regardless where you create your gl_surface). If you have multiple threads that render to the same gl surface, you cannot set_thread_aware (device, FALSE)
2. If your driver (proprietary nvidia, fglrx and latest intel (mesa > 9.0) on sandbridge/ivybridge) supports MSAA, you might want to try our new cairo which uses MSAA for antialiasing. It is at http://code.google.com/p/cairogles. It is faster than gl backend in the cairo upstream and we are in process of upstreaming it. It is also more stable. If you want to MSAA on window/pixmap, you need to add GLX_SAMPLES and GLX_SAMPLE_BUFFERS to your glx attrib. If you want to experiment more complex drawing, I recommend you use our gles, it is more stable and fast (I think it is the fastest backend at this moment given your driver supports MSAA, and you don't want to have ANTIALIAS_BEST/subpixel). When you use our cairogles, please set CAIRO_GL_COMPOSITOR=msaa in your environment.
3. There is a caveat when you are using gl surface in cairo at this moment. You need to dedicate a gl context to cairo. You cannot interleave cairo with gl calls/or other library that uses the same gl context as cairo. If you do that, you MUST same context/drawable/any other GL states before you call gl directly and you MUST restore these before you enter cairo drawing.
Let me how pixman compare to gl in your test case, Don't have radeon/nouveau drivers, not sure how they turn out.
Henry
________________________________________
From: cairo-bounces+hsong=sisa.samsung.com at cairographics.org<mailto:sisa.samsung.com at cairographics.org> [cairo-bounces+hsong=sisa.samsung.com at cairographics.org<mailto:sisa.samsung.com at cairographics.org>] on behalf of Carlos López González [genetita at gmail.com<mailto:genetita at gmail.com>]
Sent: Tuesday, January 15, 2013 11:39 AM
To: cairo at cairographics.org<mailto:cairo at cairographics.org>
Subject: Re: [cairo] Threaded animation with cairo_gl backend over a GtkWidget
Hi!
I've modified the mentioned Cairo animation with miltithreading example [1] to use a cairo_gl_surface, expecting to have some GPU acceleration. It works fine (doesn't crash) but when I use a cairo_gl_surface it runs much slow than when I use a image surface (!). See code here:
https://github.com/genete/my-test-area/blob/direct_draw/src/cairo_sample.c
commenting the line at 135 and 137 I can use cairo_image or cairo_gl.
Same code has been compiled and run in a iMac 2011 using XQuarz as Xserver with the same result.
Am I missing something at the cairo_gl code or simply I would never could make use of my GPU in my linux laptop or my iMac?
I appreciate any help.
Thanks!
[1] http://cairographics.org/threaded_animation_with_cairo/
2013/1/15 Carlos López González <genetita at gmail.com<mailto:genetita at gmail.com><mailto:genetita at gmail.com<mailto:genetita at gmail.com>>>
I forgot to CC cairo list
---------- Forwarded message ----------
From: Carlos López González <genetita at gmail.com<mailto:genetita at gmail.com><mailto:genetita at gmail.com<mailto:genetita at gmail.com>>>
Date: 2013/1/15
Subject: Re: [cairo] Threaded animation with cairo_gl backend over a GtkWidget
To: Uli Schlachter <psychon at znc.in<mailto:psychon at znc.in><mailto:psychon at znc.in<mailto:psychon at znc.in>>>
Hi!
I've upgraded to Ubuntu 12.10 and as part of the upgrade Ubuntu disabled the proprietary nvidia driver.
With the the nouveau driver enabled and simply enable multithreading, it crash.
carlos at laptop:~/my-test-area/build$ LANG=C ./cairo-sample
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
cairo-sample: ../../src/xcb_io.c:178: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
Abortado (`core' generado)
But when add XIniThreads() as shown in the previous post, it doesn't crash but it runs *extremely* slow (?). I'm using a GeForce 8400M GS graphic card (glxgears runs smoothly).
If I enable the private nvidia-current driver it crashes in any case with the same message than I had before. The suggested breakpoint or the --sync option doesn't help much.
So which are my alternatives?
If I create the cairo_gl_surface but not using cairo_gl_surface_create_for_window but the cairo_gl_create_surface, would it have GPU acceleration as well?
I just want to create a minimal example of multithreading drawing over a gtkwidget using cairo_gl to later translate to a bigger application, but it seems that it is impossible.
Is there any *real* application that uses Cairo with GPU acceleration in production?
Thanks!
2013/1/14 Uli Schlachter <psychon at znc.in<mailto:psychon at znc.in><mailto:psychon at znc.in<mailto:psychon at znc.in>>>
Hi,
On 14.01.2013 21:24, Carlos López González wrote:
[...]
> The program 'cairo-sample' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadMatch (invalid parameter attributes)'.
> (Details: serial 230 error_code 8 request_code 135 minor_code 5)
minor_code 5 likely is DRI2's GetBuffer request, but could also be a
RANDRGetScreenInfo, RenderChangePicture, SHAPEQueryExtents, SHMCreatePixmap or
SyncQueryCounter. Of course, this doesn't really help us (does it?).
[...]
> (Note to programmers: normally, X errors are reported asynchronously;
> that is, you will receive the error a while after causing it.
> To debug your program, run it with the --sync command line
> option to change this behavior. You can then get a meaningful
> backtrace from your debugger if you break on the gdk_x_error() function.)
do "break gdk_x_error" before you "run" the program.
> [Thread 0xb4738b40 (LWP 3625) exited]
> [Thread 0xb54ffb40 (LWP 3624) exited]
> [Thread 0xb6224880 (LWP 3620) exited]
> [Inferior 1 (process 3620) exited with code 01]
> (gdb) where
> No stack.
> (gdb)
>
>
> How can I add the --sync option?
If the program supports this option: "run --sync".
Uli
--
"Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?" -- A. P. J.
--
cairo mailing list
cairo at cairographics.org<mailto:cairo at cairographics.org><mailto:cairo at cairographics.org<mailto:cairo at cairographics.org>>
http://lists.cairographics.org/mailman/listinfo/cairo
--
Carlos
http://synfig.org
--
Carlos
http://synfig.org
--
Carlos
http://synfig.org
--
Carlos
http://synfig.org
--
Carlos
http://synfig.org
--
Carlos
http://synfig.org
--
Carlos
http://synfig.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20130116/1579475a/attachment-0001.html>
More information about the cairo
mailing list