From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3QKc2Kn010596 for ; Tue, 26 Apr 2011 22:38:02 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwCAP4st03RVaE2kGdsb2JhbACYB4Y+AYcZCBQBAQEBCQkNBxQEIYhwonSKeIInhTw0iF4BAQMGhXAEggaDd4hEh3eCIDqDbg X-IronPort-AV: E=Sophos;i="4.64,270,1301868000"; d="scan'208";a="106861650" Received: from mail-fx0-f54.google.com ([209.85.161.54]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 26 Apr 2011 22:37:44 +0200 Received: by fxm11 with SMTP id 11so1483786fxm.27 for ; Tue, 26 Apr 2011 13:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=VyvQw0hHykXuJ/Vzp6iDGKiJYfaYfZZaJcUWt/UVASQ=; b=TE41TSVW+imeIjX7bdDUcrgAZHnjeRgJo49ujS1Ekq8U/BffHOBnuqOfilfSJOO/Qs VxrjBj55rYxajJfqIfubr96iLQ0syJCkS4yPlVWkBPB8jyYevfxm19hNKaCBwjPAwmAs CjdY8dCnh067irmRgY1ehpiJCa8wj8j3E3nBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=YU56+eabMxnasmERj8N++LbzcwJYMjRngPVtPDOMDethhBw3foLsQak9KyPRVjmNJB ID35D1LIq8Yj0bQM4GSwVtR+KzhEriGEiFvjaSIzq3ivuf09p9Qo2CfKHHaAeEzIIaVq hXrQHOp5/Q8iFlPRIwlcU/ujfpeCoigHasP+c= MIME-Version: 1.0 Received: by 10.223.134.75 with SMTP id i11mr1327265fat.39.1303850263786; Tue, 26 Apr 2011 13:37:43 -0700 (PDT) Received: by 10.223.123.66 with HTTP; Tue, 26 Apr 2011 13:37:43 -0700 (PDT) In-Reply-To: <4DB71F64.7030501@gmail.com> References: <4DB71F64.7030501@gmail.com> Date: Tue, 26 Apr 2011 14:37:43 -0600 Message-ID: From: Anthony Tavener To: caml-list@inria.fr Content-Type: multipart/alternative; boundary=00235453076cd034d104a1d84b9c Subject: Re: [Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing. --00235453076cd034d104a1d84b9c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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=F6r=F6k 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=F6r=F6k 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 spen= t. > > > > > 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 > > --00235453076cd034d104a1d84b9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The problem with tearing will be in the way OpenGL is being used. The=20 code and hardware involved in the display update is not OCaml (or F#)=20 generated. You're setting things up for each frame with OCaml -- the=20 rendering is handled by OpenGL. So, as T=F6r=F6k suggests, verify whether= =20 you have vsync enabled in your OCaml implementation... and that lablgl=20 and whatever other layers render abstraction support it... I use=20 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=20 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=20 possibly spewing out garbage (temporary allocations) at an alarming=20 rate. Part of optimizing will be to try preventing unnecessary=20 allocations (not so much copying in every system on every frame).

I sometimes add a call for minor collection as part of my frame=20 update if I suspect stuttering (which doesn't tear, but causes=20 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,=20 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= =20 other programs, so the GC isn't likely to do the right thing without=20 some hints! :)


2011/4/26 T=F6r=F6k Ed= win <edwintoro= k@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.<= br> >
> 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 se= e 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. =A0Subscription 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


--00235453076cd034d104a1d84b9c--