[Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing.

[Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing.

[Peter Ronnquist]

While making the simple examples for SDL+opengl for the C language I
realized that even the C version showed "stuttering" but the fsharp
version is completely smooth and synced to the vblank.
Appearantly the fsharp version somehow manages to sync to the vblank
probably thanks to  the openTK api:

  do base.VSync <- VSyncMode.On

I had to configure the nvidia driver with
X Server XVideo Settings:
Video Texture Adaptor -> Sync to VBlank
Video Blitter Adaptor Settings -> Sync to VBlank

OpenGL Settings
Performance -> Sync to VBlank
                   -> Allow Flipping

then both the C sdl opengl version and ocaml sdl openg version worked smoothly.

So to sum it up, I had the wrong setting of the nvidia driver and was
fooled sinced the fsharp version still synced with the vblank.

I am posting the ocaml sdl openg test program here in case someone
would like to try it on debian 6 squeeze:

Sorry for the "false alarm", it was not ocamls fault,  and thank you
for the good advice.

(*

 Using opengl, sdl and revised syntax.

 Compile with:

 camlopt -pp camlp4r -I . -I +sdl -I +lablgl bigarray.cmxa sdl.cmxa
lablgl.cmxa unix.cmxa  str.cmxa simple2.ml -o simple2

*)

open Sdlevent;
open Sdlkey;
open Sdlgl;

(* Window size in pixels *)
value x_size_window = 512;
value y_size_window = 512;

(* Space coordinates *)
value upper_size = 1.5;
value lower_size = -1.5;
value left_size = -1.5;
value right_size = 1.5;

value init_gl width height = do {
  GlDraw.viewport ~x:0 ~y:0 ~w:width ~h:height;
  GlClear.color (0.0, 0.0, 0.0) ~alpha:0.0;
  GlClear.clear [`color; `depth];
  GlDraw.shade_model `smooth;
  GlMat.load_identity ();

  GlClear.color (0.1, 0.3, 0.1);
  GlDraw.shade_model `smooth;
};

value time =
  let start = Unix.gettimeofday () in fun () -> Unix.gettimeofday () -. start
;

value key_left_is_down = ref False;
value key_right_is_down = ref False;


(* Start of program *)
value () =

    do {

    Sdl.init [`VIDEO];
    at_exit Sdl.quit;


    set_attr [DOUBLEBUFFER True];
    ignore (Sdlvideo.set_video_mode x_size_window y_size_window
[`OPENGL ; `DOUBLEBUF ; `RESIZABLE ; `HWSURFACE]);
    init_gl x_size_window y_size_window;

    let render () =
      do {

    GlMat.mode `projection;
    GlMat.load_identity ();
    GluMat.ortho2d ~x:(-1.5, 1.5) ~y:(-1.5, 1.5);
    GlMat.mode `modelview;
    GlMat.load_identity ();
    GlClear.clear [ `color ; `depth];

    GlMat.translate ~x:(sin (time ()*.2.0) *. 1.) ~z:1. ();
    GlDraw.begins `quads;
      List.iter GlDraw.vertex2 [
        ( -0.2, -0.5);
	  (0.2, -0.5);
	    (0.2, 0.5);
	      (-0.2, 0.5)];

    GlDraw.ends ();
    Gl.flush ();
    Sdlgl.swap_buffers ();

    }
    in
      let quit_loop = ref False in
      while not quit_loop.val  do {
	(* Calculate elapsed time since last rendering *)
	  render ();
	

        match Sdlevent.poll () with
        [ Some( KEYDOWN {keysym = KEY_ESCAPE} ) -> do {
          print_endline "You pressed escape! The fun is over now.";
          quit_loop.val := True
        }
        | Some( KEYDOWN {keysym = KEY_LEFT} ) -> do {
          key_left_is_down.val := True;
        }
        | Some( KEYDOWN {keysym = KEY_RIGHT} ) -> do {
          key_right_is_down.val := True;
        }
        | Some( KEYUP {keysym = KEY_LEFT} ) -> do {
          key_left_is_down.val := False;
        }
        | Some( KEYUP {keysym = KEY_RIGHT} ) -> do {
          key_right_is_down.val := False;
        }
        | Some event -> do {
          print_endline (string_of_event event);
        }
        | None -> ()
        ]

      };

};

Re: [Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing.

[Peter Ronnquist]

Thank you for all suggestions, I will prepare three similar and simple
test programs c, sharp and ocaml that show the behavior I'm refering
to.

My intention is to sync with the vertical blanking and the f# opentk
api actually have a VSyncMode.On flag.

In sdl I use doublebuffering and HWSurfaces to mimic the same behavior.

The difference in behaviour is hardly noticable and is probably not
considered a problem by most people except for hardcore animation
enthusiasts.

My intention is to be ready with this during the weekend.

RE: [Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing.

[Jon Harrop]

Hi Peter,

Sorry for the late response. I have done a lot of OCaml+OpenGL work over the
years and found it to be extremely good for smooth animation. Conversely, I
have been uniformly unimpressed with Mono.

Frame update during animations should be synchronized with the vertical
refresh of the display to prevent tearing. Therefore, if you are seeing torn
images then the problem is certainly with the way OpenGL is being setup or
used and not to do with OCaml's GC or other user-land problems.

The visualization samples from my book OCaml for Scientists are freely
available:

 
http://ffconsultancy.com/products/ocaml_for_scientists/visualisation/index.h
tml

The "Simple 2D animation" program should provide a spinning triangle with no
tearing thanks to the use of double buffering and the GLUT swap buffers
command to update the animation in sync with the display.

Cheers,
Jon.

> -----Original Message-----
> From: Peter Ronnquist [mailto:peter.ronnquist@gmail.com]
> Sent: 26 April 2011 20:16
> To: caml-list@inria.fr
> Subject: [Caml-list] f#/mono vs ocaml runtime system - open gl animation
> screen tearing.
> 
> Hi all,
> 
> I have been experimenting with f# and mono on debian linux and compared it
> with ocaml.
> I am interested in visual presentations for example games and in my tests
f# +
> mono + opentk was able to make completely smooth animations using opengl
> (opentk) on debian 6.0 (squeeze).
> 
> Ocaml + lablgl gives "stutters" in the animation within the period of a
couple of
> seconds. The animation runs smooth for a couple of seconds and then the
> animation update is disturbed with the result that the image is "teared".
The
> tearing lasts only for a fraction of second but is visible for a trained
eye.
> 
> I suspected that the GC could be a cause for this and I tried to
manipulate the GC
> settings but I could not get a completely smooth animation for a longer
period
> of time.
> 
> This is completely acceptable for many applications but for making a game
or
> for the meticulous graphical applicaton user it is not ideal.
> 
> My thought is that maybe f#/mono unboxes more values than ocaml and in
this
> way the GC doesn't need to work as hard?
> 
> My question really is if you think it is worthwhile to investigate the
runtime
> system for mono and compare it with the runtime system for ocaml to locate
> the differences that might influence the animation and then even update
the
> ocaml runtime system to use a similar strategy as the f# runtime system?
> 
> I would be interested in this but it would be nice to first hear from the
list if this
> is a good idea. I also read in the Jane Street blog
> (http://ocaml.janestreet.com/?q=node/89) that ocamlpro might work on the
> ocaml runtime system (including unboxing).
> 
> Best Regards
> Peter Ronnquist
> 
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing.

[rixed]

Another difference between the two is not the GC but the way your GL
binding initialize opengl (for instance, double buffering like
previously mentioned, or failure to get the proper bit depth of pixel
format). These settings can make a big differnce as well.

Also, why don't you post a link to the offending program ?
If it's merely a rotating triangle you have hardly any intellectual
property in there :-)
Without this one can only speculate...

Re: [Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing.

[Ethan Burns]

Are you using double buffering?  I am certainly no expert, but if you are using double buffering then I am not sure how the GC would interfere.  The call to Sdlgl.swap_buffers (assuming you are using the ocamlsdl library) seems to call straight through to SDL_GL_SwapBuffers in the SDL library.  Once you have made this call, I don't think that the OCaml GC will get a chance to interfere until the buffer is completely swapped (therefore no stuttering effects).

Ethan

Re: [Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing.

[Anthony Tavener]

[-- Attachment #1: Type: text/plain, Size: 3638 bytes --]

The problem with tearing will be in the way OpenGL is being used. The code
and hardware involved in the display update is not OCaml (or F#) generated.
You're setting things up for each frame with OCaml -- the rendering is
handled by OpenGL. So, as Török suggests, verify whether you have vsync
enabled in your OCaml implementation... and that lablgl and whatever other
layers render abstraction support it... I use glcaml+sdlcaml, so I'm not
specifically familiar with your case.

While the GC will not be responsible for tearing in a GL app... you will
eventually have to play with the GC for a game. In particular, with a
typical game you have an update loop running at a high rate and possibly
spewing out garbage (temporary allocations) at an alarming rate. Part of
optimizing will be to try preventing unnecessary allocations (not so much
copying in every system on every frame).

I sometimes add a call for minor collection as part of my frame update if I
suspect stuttering (which doesn't tear, but causes inconsistent framerate).
If that helps then I try to find what system is using up so much memory and
can generally improve it. In the end, you'll probably need to tune the GC,
and maybe even hint for collections at more ideal times. Games and realtime
simulations aren't like most other programs, so the GC isn't likely to do
the right thing without some hints! :)


2011/4/26 Török Edwin <edwintorok@gmail.com>

> On 04/26/2011 10:15 PM, Peter Ronnquist wrote:
> > Hi all,
> >
> > I have been experimenting with f# and mono on debian linux and
> > compared it with ocaml.
> > I am interested in visual presentations for example games and in my
> > tests f# + mono + opentk was able to make completely smooth animations
> > using opengl (opentk) on debian 6.0 (squeeze).
> >
> > Ocaml + lablgl gives "stutters" in the animation within the period of
> > a couple of seconds. The animation runs smooth for a couple of seconds
> > and then the animation update is disturbed with the result that the
> > image is "teared". The tearing lasts only for a fraction of second but
> > is visible for a trained eye.
>
> Did you try to synchronize to VSYNC?
> Also which OpenGL drivers are you using, some older versions of the
> Intel drivers used to have quite significant tearing even with 2D
> animations/video.
>
> >
> > I suspected that the GC could be a cause for this and I tried to
> > manipulate the GC settings but I could not get a completely smooth
> > animation for a longer period of time.
> >
> > This is completely acceptable for many applications but for making a
> > game or for the meticulous graphical applicaton user it is not ideal.
> >
> > My thought is that maybe f#/mono unboxes more values than ocaml and in
> > this way the GC doesn't need to work as hard?
>
> Try 'latencytop', and 'perf record/perf report' to see where time is spent.
>
> >
> > My question really is if you think it is worthwhile to investigate the
> > runtime system for mono and compare it with the runtime system for
> > ocaml to locate the differences that might influence the animation and
> > then even update the ocaml runtime system to use a similar strategy
> > as the f# runtime system?
>
> Do you have a simple testcase? (OCaml code vs Mono code that easily
> reproduces the issue?)
>
> Best regards,
> --Edwin
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

[-- Attachment #2: Type: text/html, Size: 4521 bytes --]

Re: [Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing.

[Peter Ronnquist]

> Are you positive the language runtime system is the only
> change between your two setups ? For example, would a simple animation
> written in C and OCaml and F# perform differently ?
> It may also be an issue with the OpenGL FFI binding (I would trust the OCaml
> GC more than a hairy mix of OCaml/C code binding a large library).

I should add that the ocaml program is using sdl for setting up the
initial window and for syncing with the screen update.
When using C and sdl or using f# and opentk then the update of the
screen is completely smooth.
I'm comparing simple animations. For ocaml it is a moving rectangle,
in f# it is a rotating and zooming rectangle.

I have not thought about that it could be an issue with the OpenGL or
SDL binding although I still tend suspect that it is the GC/runtime
that interferes with the vertical blank synchronization.

Using glut (no sdl) and open gl gives a very visible "stuttering" both
with C and with ocaml but when using SDL and C then the result is
smooth animation.

My initial thinking was that it should be theoretically possible to
have smooth animation when using sdl and ocaml. When I tried it and
saw the occasional "stutters" my conclusion was that ocamls GC
interfere with the animation.
Then I tried f# and mono and realized that it is possible to have a GC
that does not interfere with the animation hence I began to experiment
with the GC configuration in ocaml without success.
Lastly I was thinking that it might be something else than the GC and
by the discussion here on the list and elsewhere it seems like the
unboxing management is one other difference between ocaml and f#/mono.

Re: [Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing.

[Török Edwin]

On 04/26/2011 10:15 PM, Peter Ronnquist wrote:
> Hi all,
> 
> I have been experimenting with f# and mono on debian linux and
> compared it with ocaml.
> I am interested in visual presentations for example games and in my
> tests f# + mono + opentk was able to make completely smooth animations
> using opengl (opentk) on debian 6.0 (squeeze).
> 
> Ocaml + lablgl gives "stutters" in the animation within the period of
> a couple of seconds. The animation runs smooth for a couple of seconds
> and then the animation update is disturbed with the result that the
> image is "teared". The tearing lasts only for a fraction of second but
> is visible for a trained eye.

Did you try to synchronize to VSYNC?
Also which OpenGL drivers are you using, some older versions of the
Intel drivers used to have quite significant tearing even with 2D
animations/video.

> 
> I suspected that the GC could be a cause for this and I tried to
> manipulate the GC settings but I could not get a completely smooth
> animation for a longer period of time.
> 
> This is completely acceptable for many applications but for making a
> game or for the meticulous graphical applicaton user it is not ideal.
> 
> My thought is that maybe f#/mono unboxes more values than ocaml and in
> this way the GC doesn't need to work as hard?

Try 'latencytop', and 'perf record/perf report' to see where time is spent.

> 
> My question really is if you think it is worthwhile to investigate the
> runtime system for mono and compare it with the runtime system for
> ocaml to locate the differences that might influence the animation and
> then even update the ocaml runtime system to use a similar strategy
> as the f# runtime system?

Do you have a simple testcase? (OCaml code vs Mono code that easily
reproduces the issue?)

Best regards,
--Edwin

Re: [Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing.

[Gabriel Scherer]

[-- Attachment #1: Type: text/plain, Size: 2950 bytes --]

Given the complexity and general fragility of the graphic stack on
GNU/Linux, I would suppose this issue can come from anywhere. It may be
related to the GC pauses (and the difference in GC behavior might be mainly
correlated to boxing/unboxing decisions), but it may as well come from a lot
of other things. Are you positive the language runtime system is the only
change between your two setups ? For example, would a simple animation
written in C and OCaml and F# perform differently ?
It may also be an issue with the OpenGL FFI binding (I would trust the OCaml
GC more than a hairy mix of OCaml/C code binding a large library).

I have absolutely no expertise in this domain, and your initial idea may
very well be correct, but still you should make sure you're really
investigating the real problem, and not something completely unrelated,
before going into something as specialized and difficult than runtime
implementation considerations.

On Tue, Apr 26, 2011 at 9:15 PM, Peter Ronnquist
<peter.ronnquist@gmail.com>wrote:

> Hi all,
>
> I have been experimenting with f# and mono on debian linux and
> compared it with ocaml.
> I am interested in visual presentations for example games and in my
> tests f# + mono + opentk was able to make completely smooth animations
> using opengl (opentk) on debian 6.0 (squeeze).
>
> Ocaml + lablgl gives "stutters" in the animation within the period of
> a couple of seconds. The animation runs smooth for a couple of seconds
> and then the animation update is disturbed with the result that the
> image is "teared". The tearing lasts only for a fraction of second but
> is visible for a trained eye.
>
> I suspected that the GC could be a cause for this and I tried to
> manipulate the GC settings but I could not get a completely smooth
> animation for a longer period of time.
>
> This is completely acceptable for many applications but for making a
> game or for the meticulous graphical applicaton user it is not ideal.
>
> My thought is that maybe f#/mono unboxes more values than ocaml and in
> this way the GC doesn't need to work as hard?
>
> My question really is if you think it is worthwhile to investigate the
> runtime system for mono and compare it with the runtime system for
> ocaml to locate the differences that might influence the animation and
> then even update the ocaml runtime system to use a similar strategy
> as the f# runtime system?
>
> I would be interested in this but it would be nice to first hear from
> the list if this is a good idea. I also read in the Jane Street blog
> (http://ocaml.janestreet.com/?q=node/89) that ocamlpro might work on
> the ocaml runtime system (including unboxing).
>
> Best Regards
> Peter Ronnquist
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

[-- Attachment #2: Type: text/html, Size: 3696 bytes --]

[Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing.

[Peter Ronnquist]

Hi all,

I have been experimenting with f# and mono on debian linux and
compared it with ocaml.
I am interested in visual presentations for example games and in my
tests f# + mono + opentk was able to make completely smooth animations
using opengl (opentk) on debian 6.0 (squeeze).

Ocaml + lablgl gives "stutters" in the animation within the period of
a couple of seconds. The animation runs smooth for a couple of seconds
and then the animation update is disturbed with the result that the
image is "teared". The tearing lasts only for a fraction of second but
is visible for a trained eye.

I suspected that the GC could be a cause for this and I tried to
manipulate the GC settings but I could not get a completely smooth
animation for a longer period of time.

This is completely acceptable for many applications but for making a
game or for the meticulous graphical applicaton user it is not ideal.

My thought is that maybe f#/mono unboxes more values than ocaml and in
this way the GC doesn't need to work as hard?

My question really is if you think it is worthwhile to investigate the
runtime system for mono and compare it with the runtime system for
ocaml to locate the differences that might influence the animation and
then even update the ocaml runtime system to use a similar strategy
as the f# runtime system?

I would be interested in this but it would be nice to first hear from
the list if this is a good idea. I also read in the Jane Street blog
(http://ocaml.janestreet.com/?q=node/89) that ocamlpro might work on
the ocaml runtime system (including unboxing).

Best Regards
Peter Ronnquist