PDP dev notes Entry: Syncing with pd SVN Date: Tue Aug 31 18:55:21 CEST 2010 # full repo: svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data pure-data # only pdp: svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/pdp/ pdp-pde Entry: Picking up PDP? Date: Mon Nov 28 16:42:54 EST 2011 After I forked PF from PDP I've been working on many things that might deserve some re-integration into the PDP framework. I'm not too happy with the design of PDP. Every time I pick up PDP again I think the problems might be fixable, but then give up shortly after that, seeing that they are not.. A better approach might be to start a new system and make interfaces with Pd / PDP. List of problems: * Memory allocation / reference counting. This is fixed in PF but backporting would break PiDiP etc. * Interfaces. This includes Pd, PDP's packet interface, raw buffer processing, interfaces of ad-hoc modules (video i/o ...). * Composability on the instruction level, i.e. automate inlining and unrolling. Most algorithms are simple, but a lot of effort is spent in manually writing unrolled loops with simple formulas. Entry: Upgrading V4L Date: Tue Nov 29 13:19:49 EST 2011 According to IOhannes v4l1 is no longer supported in recent kernels (zoo: 2.6.33.7-rt29 still works). The preferred way is now to use libv4l. He had changed PDP accordingly. To install on Debian: apt-get install libv4l-dev In configure.ac I had to change "pkg-config libv4l" to "pkg-config libv4l2" to make it compile on debian. That was probably the reason why I couldn't get my old webcams to work on zoo. Running naked xawtv also no longer works[1]: tom@zoo:~$ xawtv This is xawtv-3.95.dfsg.1, running on Linux/x86_64 (2.6.33.7-rt29) xinerama 0: 1440x900+0+0 X Error of failed request: XF86DGANoDirectVideoMode Major opcode of failed request: 130 (XFree86-DGA) Minor opcode of failed request: 1 (XF86DGAGetVideoLL) Serial number of failed request: 69 Current serial number in output stream: 69 I have to use : xawtv -nodga Mplayer just works mplayer tv:// It still gets messed up when plugging it in a USB hub, which seems to be a problem with the camera. [1221785.408222] usb 7-4: new full speed USB device using ohci_hcd and address 28 [1221785.639110] usb 7-4: New USB device found, idVendor=046d, idProduct=08b2 [1221785.639113] usb 7-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [1221785.641365] pwc: Logitech QuickCam 4000 Pro USB webcam detected. [1221785.641396] pwc: Registered as video0. [1221785.923306] input: PWC snapshot button as /class/input/input10 After plugging it back into a host port it doesn't recover. I tried to unload pwc, videodev and the v4l compat modules but nothing but v4l select errors. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513818 Entry: V4L2 Date: Mon Oct 29 20:08:59 EDT 2012 Merging some code from pdp_v4l2 (pidip) into pdp_v4l. I've had some hard kernel crashes working with the PWC cams. Last happened when unplugging: BUG: ... NULL pointer ... pwc_cleanup_queued_bufs() trace: usb_pwc_disconnect tom@zoo:~$ cat /proc/version Linux version 3.2.0-3-rt-amd64 (Debian 3.2.21-3) (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 SMP PREEMPT RT Thu Jun 28 10:46:01 UTC 2012 tom@zoo:~$ linux-image-3.2.0-3-rt-amd64 EDIT: Looks like there are later versions. tom@zoo:~$ sudo apt-get install linux-image-rt-amd64 Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: linux-image-3.2.0-4-rt-amd64 Suggested packages: linux-doc-3.2 debian-kernel-handbook grub-pc extlinux lilo The following NEW packages will be installed: linux-image-3.2.0-4-rt-amd64 linux-image-rt-amd64 0 upgraded, 2 newly installed, 0 to remove and 2061 not upgraded. Need to get 23.6 MB of archives. Entry: Alternative implementation Date: Mon Oct 29 21:55:28 EDT 2012 More like the "dsp" approach: fixed frame rate video engine. Maybe this can be done generically: use Pd to create an "external" dataflow network implemented by another app. Entry: Picking a webcam Date: Tue Oct 30 18:57:57 EDT 2012 Always a gamble going just by model number, but it seems best to go for either spca5xx or uvc: http://mxhaard.free.fr/spca5xx.html http://www.ideasonboard.org/uvc/ These are on the UVC list: HD-3000 and HD-5000 http://www.amazon.com/Microsoft-T3H-00011-LifeCam-HD-3000/dp/B008ZVRAQS http://www.amazon.com/Microsoft-LifeCam-HD-5000-720p-Webcam/dp/B002XN7C6W Entry: Microsoft LifeCam HD-5000 Date: Thu Nov 1 18:38:11 EDT 2012 045e:076d Microsoft Corp. LifeCam HD-5000 This needs to be massaged a little bit before it gives proper 30fps display. See here[1]. This worked for me: - manual exposure set to 153 - auto focus off Valid exposure values are: > But the camera does not respond to exposure adjustment linearly. There > are some valid values between 5-20000. They are from darkest to brightest > 5, 9 & 10 (same brightness), 19 & 20, 39, 78, 156, 312, 625, 1250, 2500, > 5000 and 10000. Every other value gives the maximum brightness. 156 is the > maximum value to get 30 fps. Maybe I can send a patch to the uvcvideo list? [1] http://comments.gmane.org/gmane.linux.drivers.uvc.devel/5717 Entry: Sharable C modules Date: Thu Nov 1 20:16:48 EDT 2012 Thinking about libprim etc... Basic idea is that you want a compile-time insertion of a project-specific struct header. Entry: V4L2 controls Date: Thu Nov 1 23:01:40 EDT 2012 Everything is in /usr/include/linux/videodev2.h The thing to find out is how guvcview maps controls to defines from videodev2.h [1] http://v4l.videotechnology.com/dwg/v4l2.html#CONTROL Entry: MMX on 64 bit? Date: Sun Nov 4 09:39:25 EST 2012 as --32 -o pixel_pack_s16u8.o pixel_pack_s16u8.s it's not actually the MMX, but using 32bit registers, i.e.: as -o pixel_unpack_u8s16.o pixel_unpack_u8s16.s pixel_unpack_u8s16.s: Assembler messages: pixel_unpack_u8s16.s:25: Error: invalid instruction suffix for `push' pixel_unpack_u8s16.s:27: Error: operand type mismatch for `push' pixel_unpack_u8s16.s:28: Error: operand type mismatch for `push' 25 pushl %ebp 26 movl %esp, %ebp 27 push %esi 28 push %edi Entry: Leaf objects Date: Sun Nov 4 10:30:55 EST 2012 So, the goal is to merge the "leaf object" library of PDP and libprim, starting with V4L. Entry: MMX stuff Date: Sun Nov 4 15:03:52 EST 2012 Got to fix ABI problems in the MMX code. Maybe it's best to go for SSE2 on the longer term, as it seems to have most of the saturated integer math that's necessary for PDP's feel. It would be nice to do some auto-vector code also. Or GCC extensions[4]. The good thing here is that ABI stuff gets taken care of by GCC. [1] http://en.wikipedia.org/wiki/SSE2 [2] http://gcc.gnu.org/projects/tree-ssa/vectorization.html [3] http://softpixel.com/~cwright/programming/simd/sse2.php [4] http://stackoverflow.com/questions/7919304/gcc-sse-code-optimization Entry: 64 bit processors Date: Sun Nov 4 17:07:53 EST 2012 Yeah I missed that revolution ;) I have two. zoo is an Acer desktop, tx is an Acer TimeLine X laptop. # 4 cores, only first one shown tom@tx:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz stepping : 7 microcode : 0x17 cpu MHz : 800.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 4788.54 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: # 4 cores, only first one shown tom@zoo:~$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 4 model name : AMD Phenom(tm) II X4 820 Processor stepping : 2 microcode : 0x1000086 cpu MHz : 800.000 cache size : 512 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save bogomips : 5600.14 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate What's interesting is the CPUflags. Making the intersection gives: SHARED: apic cx8 lahf_lm monitor nx popcnt sep vme clflush de lm msr pae pse sse cmov fpu mca mtrr pat pse36 sse2 constant_tsc fxsr mce nonstop_tsc pge rdtscp syscall cx16 ht mmx nopl pni rep_good tsc AMD: 3dnow cmp_legacy extd_apicid lbrv nrip_save sse4a 3dnowext cpu fxsr_opt misalignsse osvw svm 3dnowprefetch cr8_legacy hw_pstate mmxext pdpe1gb svm_lock abm extapic ibs npt skinit wdt INTEL: acpi ds_cpl flexpriority pln tm2 xsave aes dtes64 ida pts tpr_shadow xsaveopt aperfmperf dtherm pbe ss tsc_deadline_timer xtopology arat dts pcid sse4_1 vmx xtpr arch_perfmon epb pclmulqdq sse4_2 vnmi avx ept pdcm ssse3 vpid bts est pebs tm x2apic So both implement some SSE4 instructions, but they are named separately. What is the subset that can be used? [1] says they share 4 instructions. Maybe it's best just to use SSE2. Actually, SSE3 is called PNI[2] and supported by both. According to [2] it's also supported on Atom. [1] http://en.wikipedia.org/wiki/SSE4#SSE4_subsets [2] http://en.wikipedia.org/wiki/SSE3 Entry: TODO Date: Sun Nov 4 17:39:37 EST 2012 - cleanup v4l / x11 code to allow objects to be used outside PDP. there is already significant code in libprim that can be merged. - fix x64 ABI problems in MMX code. maybe best to let GCC handle it and use inline asm instead? Entry: MMX through GCC extensions Date: Mon Nov 5 14:11:24 EST 2012 #include Which I find in /usr/lib/gcc/x86_64-linux-gnu/4.6/include/mmintrin.h EDIT: Seems to make it quite a bit faster indeed. logistics patch is now running at 30fps with 65% CPU with only gain, add, mul, mix, biquad converted. Using __attribute__((always_inline)) for the inner biquad functions takes off another 5-7% for the whole patch. With cheby it's at 45%. TODO: - more MMX objects: resample, pack/unpack, crot, rand, randmix, - check asm for inline / alignment -> seems ok - xv / glx: find out where the tearing comes from Entry: leaf_v4l separated Date: Tue Nov 6 19:57:44 EST 2012 Next is to find out how to put libprim and PDP on the same codebase. Entry: Higher frame rate on built-in camera TimeLineX Date: Tue Nov 6 21:40:20 EST 2012 In guvcview when I change powerline frequency setting, temporarily the picture displays a higher frame rate. What's going on here? 058f:b002 Alcor Micro Corp. Entry: zl_ Date: Wed Nov 7 21:32:28 EST 2012 Instead of mixing with libprim it seems best to just make a simple C library of utility objects. A basic reusable old-tech approach. librpim is too tied to the scripting idea, and is probably best tied to zl_ directly Oh, and zl_ stands for Zwizwa Library ;) I think I'm going to keep the language-foo out of PDP. PDP is good as it is: simple, straightforward. The only place I see for languages is at compile time, to generate code. Entry: Next Date: Thu Nov 8 21:45:59 EST 2012 - integrate xwindow.c object into PDP, replacing most of the pdp_xwindow stuff. maybe this needs a gl object first? - MMX resample: better fetch strategy Entry: Resampling Date: Fri Nov 9 11:05:50 EST 2012 I'm not sure any more if it is useful to do many pixels in parallel. It seems that at least some operations need to be done serially. -> What does need to happen is that 4 pixels are computed and stored together. So it makes sense to do part of the ops in parallel since result storage is in parallel. What about restructuring? What can be done in parallell is to compute the offsets of the 4 vectors to be fetched from memory, that would work out nice. The coordinates would still be stored in 2 vectors, but the 4 components are used to compute the 4 vector locations: (x,y), (x+1,y), (x,y+1), (x+1,y+1) The challenge in doing this is to encode that +1 somehow. Currently this can't be done exactly since the coordinates are in 0.32 image-relative coordinates to allow for easy wrap-around. I.e. need to guarantee that x * scale and (x+offset_1) * scale always point to neighboring pixel indices. is there any mathematical property that can guarantee this? It might really be simpler to just perform a compare + correction. I.e. a modulo that works only for a the vectors that are just outside the range. Do this in parallel: x_inc = x_inc > right_edge ? 0 : x_inc y_inc = y_inc > bottom_edge ? 0 : y_inc In MMX that is PCMPGTW followed by PAND _mm_cmpgt_pi16() _mm_and_si64() Entry: Pd as a dataflow compiler Date: Fri Nov 9 12:40:13 EST 2012 Time to make this work ey ;) New project: PDC : Pure Data Compiler. Arrange a network. The result is a DFG that can be given any kind of interpretation. Any time the DFG changes, it gets recompiled and re-loaded. Essentially, abstract evaluation. Entry: Resample Date: Sat Nov 10 15:17:55 EST 2012 I'm giving up for doing this in straight mmx: there doesn't seem to be a good way: most of the code is shuffling that can just as well be replaced by integer operations and possibly straight s16 memory accesses. I'm going to commit now and remove all the shuffling code. It was an interesting trip though :) Another thing: if all pixel increments are made such that they are always positive, and always smaller than the with/height of the image, a simple compare -> conditional subtract is actually enough to compute the integer/fractional addresses directly: no multiplication is necessary. However, it is nearly free. Entry: Bug Date: Sat Nov 10 20:37:49 EST 2012 So I thought I had a bug as my scanned synthetis patch was running so slow. Turns out this was because it was running at 640x480 instead of 320x240! Entry: Camera 0c45:62c0 Microdia Sonix USB 2.0 Camera Date: Sun Nov 11 01:29:31 EST 2012 Very nice surprise, the cam works at high framerate. However, after upgrading: linux-image-3.0.0-1-686-pa linux-image-3.2.0-4-rt-686-pae the cam only does 1, 5 fps and won't accept anything else. [ 0.000000] Linux version 3.0.0-1-686-pae (Debian 3.0.0-3) (ben@decadent.org.uk) (gcc version 4.5.3 (Debian 4.5.3-8) ) #1 SMP Sat Aug 27 16:41:03 UTC 2011 ... [ 7.622315] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (0c45:62c0) [ 7.639655] input: USB 2.0 Camera as /devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0/input/input7 [ 7.640637] usbcore: registered new interface driver uvcvideo [ 7.640646] USB Video Class driver (v1.1.0) Framerates go up to 30. [ 0.000000] Linux version 3.2.0-4-rt-686-pae (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-12) ) #1 SMP PREEMPT RT Debian 3.2.32-1 ... [ 95.380809] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (0c45:62c0) [ 95.407087] input: USB 2.0 Camera as /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/input/input12 [ 95.409414] usbcore: registered new interface driver uvcvideo [ 95.409426] USB Video Class driver (1.1.1) framerates 1, 5 Entry: 2.6.32 Date: Mon Nov 12 11:04:14 EST 2012 This kernel is still running on an old pentium MMX computer, which is probably a good for testing if it still works. Entry: Building pd-extended Date: Tue Nov 13 16:23:38 EST 2012 I need to be careful not to break the pure-data externals repository build. Seems that core has moved to git, but all externals are still in SVN. I'm putting it under ~/pd/svn/pure-data from: svn checkout https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk pure-data To build a part: cd pure-data/externals make pdp make creb Entry: Converting to darcs-2 Date: Sat Dec 8 10:44:13 EST 2012 Entry: Running in gdb Date: Sat Dec 8 18:47:16 EST 2012 Next probably good to run it in gdb. It's simple enough with "gdb --args" Entry: X stuff Date: Sat Dec 8 19:41:56 EST 2012 Might just be my X since it's a bit unstable.. X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 132 (XVideo) Minor opcode of failed request: 19 () Value in failed request: 0x3f Serial number of failed request: 460 Current serial number in output stream: 461 How to debug this? -> I don't know where it comes from. Maybe the window manager? I added a limit to the window size of 4000x4000. Entry: List parser Date: Sun Dec 9 11:57:09 EST 2012 Problem with interfacing OO C code with pd is just the control messages. What I want is some kind of straightforward way to map a pd list, i.e. |coef 123< to a function call x_coef(x, 123). This needs a dispatcher, or a "de-dynamicifier". The trouble here is type stuff: somehow the static C type need a run-time representation. Instead of parsing header files, it seems best to tackle this at the source, encoding the syntax in some CPP constructs that are easily evaluated to different parts (declaration, implementation, parser, ...) Using explicit markers: #define API \ FUN_BEGIN(float, set_coef1) ARG(float, c) FUN_END \ FUN_BEGIN(float, set_coef1) ARG(float, c) FUN_END \ Using macro varargs FUN(ID(float, set_amp, "Set amplitude"), ID(float, amp, "amplitude")) FUN(ID(float, set_coord, "Set 2D coordinates"), ID(float, x, "X coordinate"), ID(float, y, "Y coordinate")) Declaration is then: #define FUN(n, ...) n (__VA_LIST__); #define ID(t,n,doc) t n Let's try this out for the xv wrapper. Entry: Release? Date: Tue May 14 13:24:25 EDT 2013 I got interrupted in December.. What's next? - new build system? - make V4L2 build properly - more tests? Entry: Prerelease Date: Tue May 14 14:32:13 EDT 2013 Hello, There's a PDP release in the pipeline: 0.14.0: Port ia32 MMX assembly code to GCC extensions (MMX support on amd64) Add V4L2 support to pdp_v4l (merge with pdp_v4l2) Distill zl (Zwizwa Lib) from PDP and libprim/PF code. This is quite a big change internally and is not 100% stable yet. It should be functionally equivalent with previous version. I'm going to put out what I have now for people that like to try it out. If you run into a bug, post here or send it to pdp@zwizwa.be http://zwizwa.be/pd/pdp/test/pdp-darcs-20130514_145023.tar.gz Some known issues are GLX crashes when texture size changes and V4L1 support being broken. ( See pdp_v4l_hack for a new camera-specific setup hack that was necessary to get high FPS on a Microsoft cam. It might be useful for other cams too. ) Cheers Tom Entry: Todo from pd-list Date: Wed May 15 20:19:40 EDT 2013 - find m_pd.h in different path WONTFIX? - fix default target DONE - weird images sizes sometimes crash (not in debug build?) Entry: 3dp Date: Fri Oct 11 10:08:33 EDT 2013 TODO: - Move the 3D context object to zl. - Cleanup zl such that pdp contains standalone lib to avoid merge issues The core object that's passed around in 3dp is a 3Dcontext. It seems simplest to move the implementation of this into zl. However... it might be best to take this code from PF, and just make 3dp work with recent api changes. It's not a small change to do this merge properly... Entry: procqueue Date: Sat Oct 12 19:21:57 EDT 2013 I thought I took that out... Apparently not. Means 3dp needs to support it? Entry: 3DP bug when opening 2 separate windows Date: Tue Oct 15 19:48:23 EDT 2013 tom@zoo:~/pdp/opengl/doc/examples$ pd.local example05.pd X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 154 (GLX) Minor opcode of failed request: 11 (X_GLXSwapBuffers) Serial number of failed request: 66 Current serial number in output stream: 67 Entry: SCAF also broken (32bit asm) Date: Tue Oct 15 20:07:52 EDT 2013 example 6 Entry: TODO 3dp Date: Tue Oct 15 20:14:54 EDT 2013 example 5,6,8,11,12,13,15 Entry: 3dp bug when changing window size in ex 8 with lots of squares Date: Tue Oct 15 20:17:14 EDT 2013 tom@zoo:~/pdp/opengl/doc/examples$ pd.local example08.pd MULTI_AUDIODEV 3 PDP_AUDIODEV 1 29157 using JACK priority 6 scheduling enabled. priority 8 scheduling enabled. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated. Fontconfig warning: "/etc/fonts/conf.d/53-monospace-lcd-filter.conf", line 10: Having multiple values in isn't supported and may not work as expected Fontconfig warning: "/etc/fonts/conf.d/65-droid-sans-fonts.conf", line 103: Having multiple values in isn't supported and may not work as expected Fontconfig warning: "/etc/fonts/conf.d/65-droid-sans-fonts.conf", line 138: Having multiple values in isn't supported and may not work as expected Fontconfig warning: "/etc/fonts/conf.d/90-fonts-unfonts-core.conf", line 11: Having multiple values in isn't supported and may not work as expected Fontconfig warning: "/etc/fonts/conf.d/90-fonts-unfonts-extra.conf", line 16: Having multiple values in isn't supported and may not work as expected ev: 22 ev: 22 ev: 19 X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 137 (DRI2) Minor opcode of failed request: 8 (DRI2SwapBuffers ) Resource id in failed request: 0x1800003 Serial number of failed request: 1765 Current serial number in output stream: 1765 Entry: 3dp window events don't seem to work after libprim/zl update Date: Wed Oct 16 09:47:09 EDT 2013 check mouserotate Entry: torus is gone! Date: Sun Oct 27 10:51:48 EDT 2013 static void draw_wtorus(t_drawcommand *x) { float ri = x->x_p0; float ro = x->x_p1; int n = (int)x->x_p2; int m = (int)x->x_p3; if (n < 1) n = 20; if (m < 1) m = n; // glutWireTorus(ri, ro, n, m); } In PF? Ok, this is because the GLUT dependency was removed. Added it back to pdp_opengl Entry: 3Dcontext events fixed Date: Sun Oct 27 12:33:21 EDT 2013 using the new "for" approach. Entry: TODO 3dp Date: Sun Oct 27 12:34:23 EDT 2013 example 5,6,8,11,12,13,15 Entry: example08.pd: gl method called outside of context? Date: Sun Oct 27 12:48:36 EDT 2013 Not sure how to fix this, since "current context" doesn't really mean anything in the packet conversion code.. bt #0 0x02f5b290 in pdp_packet_texture_isvalid () from /home/tom/darcs/pdp/opengl/pdp_opengl.pd_linux #1 0x02f5b361 in _pdp_packet_texture_old_or_dummy () from /home/tom/darcs/pdp/opengl/pdp_opengl.pd_linux #2 0x02f5b524 in _pdp_packet_texture_convert_bitmap_to_texture () from /home/tom/darcs/pdp/opengl/pdp_opengl.pd_linux #3 0x009ac85b in _pdp_type_run_conversion_program () from /home/tom/darcs/pdp/pdp.pd_linux #4 0x009acdac in _pdp_packet_convert () from /home/tom/darcs/pdp/pdp.pd_linux #5 0x009acec6 in pdp_packet_convert_rw () from /home/tom/darcs/pdp/pdp.pd_linux #6 0x02f5af7e in _pdp_packet_texture_convert_image_to_texture () from /home/tom/darcs/pdp/opengl/pdp_opengl.pd_linux #7 0x009ac85b in _pdp_type_run_conversion_program () from /home/tom/darcs/pdp/pdp.pd_linux #8 0x009acdac in _pdp_packet_convert () from /home/tom/darcs/pdp/pdp.pd_linux #9 0x009acf36 in pdp_packet_convert_ro () from /home/tom/darcs/pdp/pdp.pd_linux #10 0x00987d6d in pdp_convert_input_0 () from /home/tom/darcs/pdp/pdp.pd_linux #11 0x080af90b in pd_typedmess () #12 0x080b16cf in outlet_anything () #13 0x009b7316 in outlet_pdp_register () from /home/tom/darcs/pdp/pdp.pd_linux #14 0x009b752e in pdp_packet_pass_if_valid () from /home/tom/darcs/pdp/pdp.pd_linux #15 0x009b7ac3 in pdp_pass_if_valid () from /home/tom/darcs/pdp/pdp.pd_linux #16 0x009b6b5c in pdp_base_postprocess () from /home/tom/darcs/pdp/pdp.pd_linux #17 0x009b8d6c in pdp_procqueue_add () from /home/tom/darcs/pdp/pdp.pd_linux #18 0x009b6c5d in pdp_base_bang () from /home/tom/darcs/pdp/pdp.pd_linux #19 0x009b6d34 in pdp_base_input_hot () from /home/tom/darcs/pdp/pdp.pd_linux #20 0x080af90b in pd_typedmess () #21 0x080b16cf in outlet_anything () #22 0x009b73d7 in outlet_pdp_process () from /home/tom/darcs/pdp/pdp.pd_linux #23 0x009b7546 in pdp_packet_pass_if_valid () from /home/tom/darcs/pdp/pdp.pd_linux #24 0x00991f3b in pdp_plasma_postproc () from /home/tom/darcs/pdp/pdp.pd_linux #25 0x009b6b46 in pdp_base_postprocess () from /home/tom/darcs/pdp/pdp.pd_linux #26 0x009b8d6c in pdp_procqueue_add () from /home/tom/darcs/pdp/pdp.pd_linux #27 0x009b6c5d in pdp_base_bang () from /home/tom/darcs/pdp/pdp.pd_linux #28 0x00991e3b in pdp_plasma_bang () from /home/tom/darcs/pdp/pdp.pd_linux Maybe conversion of bitmap to texture should just be removed. I.e. only do this in 3dp object? Entry: fixing scaf Date: Tue Oct 29 09:44:07 EDT 2013 Probably best to make a different architecture. It doesn't seem too hard to write this in pure C in an unrolled/tiled loop. Hmm... no. That's not a good tap point. It might be simplest to keep the code in 386 bit mode and do the ABI adaptation in the feeder routine. How to switch to 386 bit mode? Maybe only the OS can do that? Doesn't look like this will work. What is the code that goes into the assembler? In scafmacro.s the memory references are through %edi and %esi. Changing these to the 64 bit equivalents should be enough. Then fix the feeder to use a 64bit ABI. esi -> rsi edi -> rdi To make this work, make sure all .s files pass through the C preprocessor, then use: // 32bit #define SI %esi #define SI %esi // 64bit #define SI %rsi #define SI %rsi http://stackoverflow.com/questions/2500362/running-32-bit-assembly-code-on-a-64-bit-linux-64-bit-processor-explain-the Entry: Fix scaf Date: Sun Nov 3 12:52:07 EST 2013 - convert pdp_ca.c to fixed size ints from stdint.h - use minimal %esi / %edi fix for core routines - create inline asm feeder EDIT: Tried on Acer One 32bit, but pdp_opengl gives problems after recompile. Should do a fresh configure & compile and find out what's wrong.. No protocol specified pdp: x11: can't open display :0 It also happened a launching xterm, but now xterm works again. Not sure what the difference was. Let's restart X server. Yep, that fixed it. Guess is that there is another bug in the 3Dcontext -> Xlib calls that exposes a bug in the X server. Entry: Next: scaf Date: Thu Dec 5 09:40:02 EST 2013 - build feeder in C - check if it works on x86 - verify on amd64 Entry: TODO 3dp Date: Sun Oct 27 12:34:23 EDT 2013 Last note was: example 5,6,8,11,12,13,15 crash: 5, behavior: 6, Entry: Release notes Date: Fri Dec 13 13:00:31 EST 2013 updates to pdp_scaf and pdp_opengl (3dp) SCAF (Simple Cellular Automata Forth) is ported to x86_64 ABI. It still uses the old MMX integer code which makes little sense on x86_64, but at least it works. 3dp +- works. Some known issues in corner cases (pdp/opengl/doc/examples) - example05.pd : multiple window render contexts - example06.pd : bug in scaf CA grid -> texture conversion ? Entry: glxcontext Date: Sat Dec 21 17:55:00 EST 2013 void zl_3Dcontext_glx_setup(void) { ... glx_env.glx = zl_glx_new(); ... } There's some confusion about context and drawables... Find out exactly what the relation is between these. The bug is probably just a misunderstanding of what is what. glXMakeCurrent takes: - Display - GLXDrawable (window) - GLXContext When a 3dp window is closed and reopened, the drawable should change, but the display and context should remain the same. The problem seems to be that the drawable is gone. Maybe this is just a flush problem? Or, does the closing of the window also delete the context? no Something non-obvious is going on here. It doesn't look like the swapbuffer call is the source of the problem, just a symptom. X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 154 (GLX) Minor opcode of failed request: 11 (X_GLXSwapBuffers) Serial number of failed request: 320 Current serial number in output stream: 321 I'm guessing this is just fallout from a dangling reference issue. Entry: Cleanup Date: Sun Dec 22 14:43:23 EST 2013 So I really want to clean up PDP to make it maintainable. What that means in practice is to _remove_ stuff. One of the complications is the procqueue. I wonder if it is actually used for anything essential. It can probably be replaced with abstract interpretation. The problem here is time. This is not someting for an incremental job. Or at least, the increments will be fairly large. Entry: Debug GLX error Date: Mon Dec 30 17:35:38 EST 2013 .. glXSwapBuffers(0x7fb9f0000950,0x1600003) glXSwapBuffers(0x7fb9f0000950,0x1600003) zl_3Dcontext_free(0x1d2baf0,(nil)) glXSwapBuffers(0x7fb9f0000950,0x160000a) glXSwapBuffers(0x7fb9f0000950,0x160000a) glXSwapBuffers(0x7fb9f0000950,0x160000a) X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 154 (GLX) Minor opcode of failed request: 11 (X_GLXSwapBuffers) Serial number of failed request: 592 Current serial number in output stream: 594 I'd like to really know what is going on here, i.e. go into the graphics driver and see why it raises a BadMatch, which is not what it's supposed to do. At least I find no valid reason. Maybe mesa debug would help here? Entry: Better errors on Acer Revo / Ubuntu Date: Mon Jan 6 11:36:08 EST 2014 glXSwapBuffers(0xb35004e0,0x1800003) glXSwapBuffers(0xb35004e0,0x1800003) glXSwapBuffers(0xb35004e0,0x1800003) glXSwapBuffers(0xb35004e0,0x1800003) zl_3Dcontext_free(0x87364e8,(nil)) glXSwapBuffers(0xb35004e0,0x180000a) glXSwapBuffers(0xb35004e0,0x180000a) X Error of failed request: GLXBadDrawable Major opcode of failed request: 153 (GLX) Minor opcode of failed request: 11 (X_GLXSwapBuffers) Serial number of failed request: 81 Current serial number in output stream: 82 Entry: Main 3D rendering objects Date: Mon Jan 6 11:36:55 EST 2014 The problem is one of organization. - X server connection - GLX contex - X window (drawable) How to fix? Probably best to trace all gl calls. Is there a simple way to do this without manual edit? Entry: gdb Date: Mon Jan 6 12:13:00 EST 2014 Is this just me getting old and confused, or did the buggy nature of emacs / gdb just get worse over time? I'm gessing the problem is that the process stdout/stderr is not tagged with target-stream-output '@'. Entry: zl updates Date: Sat Aug 16 12:08:04 EDT 2014 Looks like this broke: pdp_3d_windowcontext.c:133:5: warning: implicit declaration of function ‘pdp_packet_3Dcontext_event_out’ [-Wimplicit-function-declaration] pdp_packet_3Dcontext_event_out(p, x->x_eventout); Entry: __attribute__((unused)) Date: Sat Aug 16 12:08:16 EDT 2014 A useful warning, so added the attribute to all dummy variables. Entry: cleanup Date: Mon Jan 6 13:52:35 EST 2014 Is there a way to clean up PDP to make it easier to maintain? What I want to do is to reduce everything to a libprim core, then port it to the existing PDP api. I.e. I want to toss it all out. This however is not realistic without a design of what PDP is supposed to be. The trouble is feature creep. Obtaining a design would require a review of each file to understand how it actually works and where it is broken due to bad interactions. Some elements of the API that are a bit crooked: - planar processing (e.g. chanmask) - autoconvert - procqueue - refcount mechanism - dpd / 3dp "serial programming" idea Practically, moving part by part to libprim or other libraries is probably the best approach. I don't have the time/energy/motivation to turn this into a large sprint. The best I can do for now is incremental increases. Entry: Picking up again Date: Sat Oct 31 08:59:29 EDT 2015 For those who lost track: this got off the rails a little. PDP/PF have been stepping-stone projects towards learning more about designing programs, virtual machines, programming languages and compilers. The idea has been to keep PDP and PF up with the development in that area, which has largely been infeasbile due to the large amount of design errors made in the process. Today, another attempt to fix things. Current state: libprim: simple object system zl: bindings to (linux) libraries The idea was to build PF and possibly PDP on those two libraries, and then use RAI to generate DSP code. Entry: PF fixes Date: Mon Nov 2 07:57:08 EST 2015 Spent this weekend propagating some changes in libprim/leaf to libprim/pf: - leaf_object has a built in rc count, which is used to create composite (tree-structured) leaf objects. - removed the RC wrapper used in PF, and renamed the LIN wrapper to UNIQ. It looks like the PF design is sound, however its implementation could probably be made a little simpler.