<davexunit>has anyone here had any experience trying to reduce the number of GC runs when writing a realtime application? <davexunit>I having a little graphical demo that animates smoothly, but experiences a hiccup about once per second due to the GC running. ***fangism is now known as fangism-ctrl-Z
<madsy>Anyone have an idea why ",q" terminates my whole application even when scm_shell() runs in its own thread? <madsy>Logic says it should just terminate the thread and return to scm_join_thread() <madsy>nalaginrut: I'll dish up some later this afternoon :) <unknown_lamer>scheme@(figl gl)> (make-shader* (version-2-0 vertex-shader) "void main(void) { <wingo>now we need a compiler from scheme to shade language <unknown_lamer>well, the first next step is writing something that uses vertex/fragment shaders instead of the fixed pipeline and shows something on the screen <wingo>easiest to start with fragment shaders <unknown_lamer>I am trying to use the subset of gl that works with 2.1 and 3.x, mostly <unknown_lamer>I'd have just updated figl against opengl 3.3, but my dang laptop graphics don't support anything past 2.1 <wingo>your best bet is indeed the common subset of 2.1 and 3.x <unknown_lamer>I think a few possible ffi extensions will appear from this too <unknown_lamer>CFFI has a few bits that help with hiding the awful truth, I think I'm going to end up adapting those once I bind more of the evil parts of the GL api <wingo>we need better macros, that's for sure <unknown_lamer> (uint-list->bytevector (map (compose pointer-address (@@ (figl gl types) coerce-array-pointer)) pointers) <unknown_lamer>I am pretty sure I should have it take unwrap as an argument <madsy>unknown_lamer: You're the author behind figl? <madsy>I made my own OpenGL setup, which is a bit more high level <madsy>But I'm embedding scheme, not extending it <madsy>I don't think we'll see such a day :) <madsy>Later today I'll add my bone animation system to my demotool. It will be awesome <madsy>The standalone example is already on github. Download and use it for whatever you like <madsy>I didn't compile it as a library, but its usage is pretty simple <nalaginrut>seems the repo of guile-emacs is unstable, many times it throws "early EOF" <madsy>You can ignore the GLFW and libpng dependencies. The actual model loading only requires libassimp *wingo will check it out later <madsy>Yay, I aced the job interview :) ***haroldwu_irssi is now known as haroldwu
<madsy>Not my fav but it beats working at a grocery store *civodul dreams of guile-jobs.com <gzg>civodul: fossguile-jobs.com* :^P *gzg wonders if there's generally an equivalent to fossjobs.com, out there. <gzg>Not real domain, fyi. <TaylanUB>gzg: Don't get my hopes up like that. :D *TaylanUB is looking for a different job, iOS development is unethical and often very boring ... <davexunit>TaylanUB: I have avoided iOS development, though my currently employer has started projects to develop iOS applications. <davexunit>applications that I have 0 interest in maintaining and hopefully won't have to. <mario-goulart>TaylanUB: edw announced a job opportunity at actionx.com some days ago on #scheme ***fangism-ctrl-Z is now known as fangism
<unknown_lamer>getting good error messages out of the GLSL compiler looks ... impossible <davexunit>unknown_lamer: oh wow I had no idea about this. <unknown_lamer>it requires GL 3.3 at least though, so I haven't messed with it too much <unknown_lamer>also all of the documentation is rtfs or watch these very long screencasts, and I'm not a huge fan of screencasts <unknown_lamer>call me old fashioned, but I just want a web page with screenshots of the effects of commands inline <unknown_lamer>partly because I hear "skimming" and "scanning" are good ways to prepare yourself for digesting information <davexunit>I hate screencasts because I can't move at my own pace <unknown_lamer>I think I can actually get something pretty similar with figl up ... today? <unknown_lamer>if I can hook into the repl to run the glutMainLoopNextEvent thing after every evaluation... <unknown_lamer>then you should be able to get basic hacking going by just evaluating forms within (with-window ...) <unknown_lamer>I really hate how the GL folks didn't go with the magical everything-is-immutable-and-threadsafe OpenGL 3.0 >:O <davexunit>it sounds like our work overlaps in some ways. <davexunit>cepl's repl interaction is better than guile-2d's right now. <unknown_lamer>my fifteen minutes with it had it crashing sbcl here and there <davexunit>unknown_lamer: have you done much opengl programming in guile yet? <unknown_lamer>I hacked on the vbo.scm demo to use GL_POINT instead of GL_QUAD, and made it do some funky things <davexunit>I want more Guile graphics programmers to help me defeat the GC and achieve stutter-free realtime graphics programs. :) <unknown_lamer>that's gonna be fun, vbo's frame rate output showed considerable stutter <kurohin>In my quest to learn guile/scheme(one week in) I have now started to feel that my pinkies are somewhat strained, does anyone have any advice on how to mitigate the often use of shift and maybe dash. <unknown_lamer>not too noticeable in a particle system, but make the rendering more realistic and suddenly... <davexunit>unknown_lamer: if you run that with GC_PRINT_STATS=1 you will see all the GC runs. <madsy>davexunit: Easy. Just disable the GC ;-) <davexunit>the GC is a good thing, but I need to make some optimizations to make it run less. <unknown_lamer>hrm, doesn't libgc have some kind of non-blocking realtime collector mode <davexunit>unknown_lamer: I could be doing it wrong, but running in incremental mode didn't help when I tried. <davexunit>I think the solution will have to be some combination of: C extensions, GL shaders, more mutable data structures, and perhaps interning of certain immutable types. <madsy>davexunit: Replace some scm_gc_mallocs with malloc? :D <madsy>davexunit: If it knows about less memory it will run less, right? <davexunit>the GC isn't a big issue for me until my game has a large number of objects being updated each frame. which is common because I like to write bullet hell games that involve hundreds to thousands of particles on screen. <unknown_lamer>there's the old realtime trick of "don't allocate any memory" :( <unknown_lamer>but unfortunately it's not easy to know what in guile will cons and what will not <davexunit>I really like kentacho and his games, but bulletml is terrible. <davexunit>unknown_lamer: floating point numbers are allocated on the heap. <unknown_lamer>at least I hear uniform vectors store things like that packed <davexunit>the "issue" has been discussed here before about the floats. <unknown_lamer>allocate an f32vector statically, and then mutate the cells within ... (maybe a few quick accessors and a set! expander) <davexunit>it isn't a trivial problem to solve, and the use case of realtime graphical applications simulating tons of particles is not a very good reason to significantly alter guile. <davexunit>unknown_lamer: that might help, but you still need to create the float to stuff in there. <davexunit>figl's packed structs use the bytevectors already. I use them. <davexunit>unknown_lamer: yeah I think C is the answer, which will have the side effect of making my library more difficult to install and use. <davexunit>but I could write quite the blazing fast particle simulation in C. <unknown_lamer>' All collections initially run uninterrupted until a predetermined amount of time (50 msecs by default) has expired' <TaylanUB>Your total throughput will decrease as you make it more incremental, AFAIK. <davexunit>people urge that I don't add a C extension to guile-2d, but it's the only way I see to get performance where it needs to be. <TaylanUB>davexunit: Any idea what the bottleneck/s is/are ? <davexunit>TaylanUB: from what I can tell, when doing a lot of floating point math per frame. <TaylanUB>OK. I reckon mark_weaver had a patch for unboxed floats, dunno what happened with it. <davexunit>animating and rendering a few sprites: no issues. animating and rendering a thousand sprites: a lot of GC. <TaylanUB>(It was unclear whether it's an improvement *in general*, or only in specific cases, etc., IIRC.) <davexunit>TaylanUB: yeah he made a really cool patch, but from what I understand it will not be applied. <davexunit>I should probably still try it out and see if things work better, though... <davexunit>so it's basically: write C or wait for native compilation ;) <unknown_lamer>GC_PAUSE_TIME_TARGET - Set the desired garbage collector pause time in msecs. <TaylanUB>davexunit: Was there discussion on whether it could be made optional ? I imagine it might have high maintainance burden for little gain if it were just a compile-time option; no idea how possible it'd be as a run-time option. <davexunit>TaylanUB: I thought that it would have to be a compile-time option, which isn't worth it imo. <TaylanUB>Yeah, I agree, it would be just nasty if you end up with a library that requires a special Guile build and doesn't just work with people's out-of-the-box Guile from their favorite OS's package-manager. :\\ <davexunit>there's a lua game engine called love, it is written mostly in C for performance. <davexunit>I don't think that I will have to write much C, but for certain things I think it will be unavoidable. <unknown_lamer>hrm, setting pause time target has no effect on frame stutter in vbo.scm <unknown_lamer>incremental does seem to drop the stutter from 30ms to 20ms though <unknown_lamer>I kind of miss the old GC, for all of its evil... it had (with-deferred-interrupts ...) <unknown_lamer>for realtime tasks, I could see a simple interface... (with-delayed-gc ...) + (gc #:optional max-run-time) <davexunit>perhaps we could tell the GC to wait longer before running, which will make less runs, but each GC run will take longer... <davexunit>unknown_lamer: for my particle test, the GC runs less, about once per second. <unknown_lamer>and using multiple intermediate floats for some calculations