From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 60CCE7F860 for ; Mon, 17 Mar 2014 11:34:15 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of edwin+ml-ocaml@etorok.net) identity=pra; client-ip=62.113.205.31; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of edwin+ml-ocaml@etorok.net designates 62.113.205.31 as permitted sender) identity=mailfrom; client-ip=62.113.205.31; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@mx.etorok.net designates 62.113.205.31 as permitted sender) identity=helo; client-ip=62.113.205.31; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="postmaster@mx.etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAGLPJlM+cc0f/2dsb2JhbABZgwY7wliBGhZ0giUBAQEDAUA6DwsYCRMLBw8CECUREwYCAodhAwkMCa8xhFuWcw2HLxEGjFCCHxaEIpRegX+BbYxnhUiDLzs X-IPAS-Result: AiMFAGLPJlM+cc0f/2dsb2JhbABZgwY7wliBGhZ0giUBAQEDAUA6DwsYCRMLBw8CECUREwYCAodhAwkMCa8xhFuWcw2HLxEGjFCCHxaEIpRegX+BbYxnhUiDLzs X-IronPort-AV: E=Sophos;i="4.97,669,1389740400"; d="scan'208";a="63217664" Received: from mx.etorok.net ([62.113.205.31]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Mar 2014 11:34:14 +0100 Received: by mx.etorok.net (OpenSMTPD) with ESMTP id c6549b0a; for ; Mon, 17 Mar 2014 12:34:12 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=etorok.net; h= message-id:date:from:mime-version:to:references:in-reply-to :content-type:content-transfer-encoding; s=ml; l=2173; bh=pU4NfK AOcLHYjtE/qdmBXSJ+Udc=; b=VU1v32GS7X955CAVhpBAo+ag7hXAobBRrhdrxK H5cvOW6qRj4CBistJ9qS4WG1WAPViEvy5O83VU5VmBhyRfrCpzEwnQStFnRGwnFh hsMA835hdPUr+lxvQFFtP+9atchOjzwwQbXKF1tYF9M5sNw2hKl4jAwE4c3489At SAgxA= Received: by mx.etorok.net (OpenSMTPD) with ESMTPSA id 554bd241; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-SHA bits=128 verify=NO; for ; Mon, 17 Mar 2014 12:34:11 +0200 (EET) Message-ID: <5326CFA2.909@etorok.net> Date: Mon, 17 Mar 2014 12:34:10 +0200 From: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <1732E7D3-C154-4305-90C8-0CC292FE08CF@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] OpenGL and LWT On 03/17/2014 12:09 PM, Jeremie Dimino wrote: > Hi, > > On Sat, Mar 15, 2014 at 5:37 PM, Richard Neswold > wrote: > > Hello, > > What would be the appropriate way to use LWT and LabGL together? > > My gut feeling would be to have the core model and logic to be LWT with a 'detached' thread executing the OpenGL main loop. The thread would get events through the reactive module and would update the display accordingly. > > The problem is I'm still trying to wrap my head around LWT and I'm not sure a detached thread can participate with the LWT environment it was spawned from. It appears the detached thread is supposed to do something and eventually return a value. > > > Yes, the purpose of Lwt_preemptive.detach is to execute a blocking action in a separate system thread in order not to block all lwt threads. And from another system thread you cannot run lwt code directly, you have to use Lwt_preemptive.run_in_main. Be careful to have an OpenGL context set as current on the thread(s) from which you make GL calls. See: https://www.opengl.org/wiki/OpenGL_and_multithreading http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html I don't think you'll get a performance improvement from launching multiple GL calls in different (Lwt) threads. > > > Is the correct approach to use a detached thread to make the individual OpenGL calls? > > > I think that would be very slow, as in involves system thread synchronization. > > > Any recommendations or resources on the subject would be appreciated. > > > You could try to assume that OpenGL calls are fast and perform them in the same thread as lwt. Well there are a few that are slow, like swapping buffers which can wait for vsync. I think its best to make GL calls from just *one* thread, either your application's main thread, or a dedicated rendering thread. You can probably build a Lwt.t that waits for the rendering thread to finish one frame using Lwt_unix.make_notification/send_notification for thread-safe Lwt notification, coupled with Lwt.wait/Lwt.wakeup_result. Best regards, --Edwin