Re: [hpx-users] list of OS names

[Lars Viklund]

I did some work porting HPX to DragonFly BSD last winter, but ended up
not merging it back because of hwloc on DFBSD reporting topologies we
did not expect in HPX.

For reference, my work can be found at:
https://github.com/zao/hpx/commit/9786ac6c58754912f84af243a467a5ab2572d456

Particularly the init_globally example and the counters are a bit
non-trivial.

For RTLD_DI_ORIGIN, I reimplemented it now by something like the
following:

  void* end_sym = dlsym(dll_handle, "_end");
  Dl_info dli;
  dlinfo(end_sym, &dli);
  // dli.dli_fname contains the full path to the library, apply
  // dirname-alike to strip the file component off, as dirname(3) may be
  // mutating or not be reentrant

Note that dlinfo(RTLD_DI_LINKMAP)'s claims to return paths in its
Dl_info* is a lie and cannot be used here, it seems to actually be the
literal contents of the library file.

On Mon, Aug 13, 2018 at 05:40:39PM +0200, Thomas Heller wrote:
> Patrick Welche  schrieb am Mo., 13. Aug. 2018 16:16:
> 
> > On Mon, Aug 13, 2018 at 08:06:25AM -0500, Hartmut Kaiser wrote:
> > > FWIW, I have merged #3402 just now.
> >
> > Thanks!
> >
> > I have got as far as linking libhpx now - somehow there is a -ldl in
> > link.txt (and in the generated pkg-config .pc files). I have been hunting
> > through the cmake files where it comes from, but haven't found it. Any
> > ideas? (dlopen and friends are in many OS's system library as opposed to
> > libdl.)
> >
> 
> If I'm not mistaken, this might even come out of the inner cmake core
> itself.
> 
> 
> > Cheers,
> >
> > Patrick
> > ___
> > hpx-users mailing list
> > hpx-users@stellar.cct.lsu.edu
> > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
> >

> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users


-- 
Lars Viklund | z...@acc.umu.se
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] list of OS names

[Lars Viklund]

On Mon, Aug 13, 2018 at 01:22:38PM +0100, Patrick Welche wrote:
> On Mon, Aug 13, 2018 at 01:19:42PM +0100, Patrick Welche wrote:
> > Chugging along trying to get hpx to compile, I thought I would try the
> > 1.1.0 patches I had so far on master. I just got an extra compile error:
> > 
> > /usr/src/local/hpx/src/hpx_init.cpp: In function ‘int 
> > hpx::detail::run_or_start(hpx::util::function_nonser&,
> >  const boost::program_options::options_description&, int, char**, 
> > std::vector >&&, hpx::startup_function_type, 
> > hpx::shutdown_function_type, hpx::runtime_mode, bool)’:
> > /usr/src/local/hpx/src/hpx_init.cpp:603:24: error: ‘hpx_start’ has not 
> > been declared
> >  if(hpx_start::include_libhpx_wrap)

The functionality in question is part of one of our GSoC student's work
on introducing HPX even earlier in the startup process via loader
tricks, currently only on a few OSes like GNU/Linux and macOS.

There is a missing guard in this source file and it should be resolved
by the fix in PR#3402.

https://github.com/STEllAR-GROUP/hpx/pull/3402

Everything else about this feature should be inert on the OSes the
feature doesn't apply to.

-- 
Lars Viklund | z...@acc.umu.se
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] list of OS names

[Lars Viklund]

On Wed, Aug 08, 2018 at 10:08:22PM +0100, Patrick Welche wrote:
> On Wed, Aug 08, 2018 at 11:01:40PM +0200, Thomas Heller wrote:
> > With that being said, we are totally open to suggestions to make this
> > handling of different OSes more maintainable. Do you have suggestions?
> 
> Yes - I had a subsequent trivial patch which then also matches better
> the header inclusion #ifdefs at the start - basically "not windows"
> should be the #else case as per the little patch.
> 
> I said I would check FreeBSD. I looked in:
> 
>   https://github.com/freebsd/freebsd/blob/master/lib/libc/stdlib/getenv.c
> 
> and don't see a "freebsd_environ". Does "environ" same as everyone else
> really not work on FreeBSD?

There's some subtle differences when it comes to shared libraries.

On Linux `environ` is available universally regardless of where you are
in the program, while on FreeBSD we need to grab it at a specific point
and clone the contents, so that it's available everywhere we need it.
There no system function to acquire the proper environment like there's
on macOS, which would make things easier.

I forget the particulars, but it's differently available at link time on
FreeBSD vs. Linux and results in linker errors if you use it directly in
a shared library. The way here is convoluted, but it works.

Heller outlined most of the pain points already where low level
differences occur, but it's very easy as a programmer to accidentally
target GNU/Linux extensions and features and not know about it until
someone like you or me figures it's time to try it on a BSD.

All the non-Windows OSes are similar, except for all the places where
they're quite different.

Anything you see in the codebase that's conditional under `__FreeBSD__`
is typically due to me trying to build the thing and figuring out what
things need generalization and what things just need specialization.

At some places, macOS and FreeBSD are similar enough to share
implementations, and I've tried to do that there. Due to having rather
limited Net and Open experience, I opted to not use the generic
BSD conditional.

// Lars Viklund, user of weird OSes

> 
> Cheers,
> 
> Patrick
> _______
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

-- 
Lars Viklund | z...@acc.umu.se
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Fwd: RE: [GSoC] Interested in Asynchronous integration of CUDA and OpenCL to HPX

[Lars Viklund]

Hi!

Regarding build failures on Linux after PR #40, I've amended the problem 
with PR #41 which addresses the Linux build. There's still some INSTALL 
failures, but those were long pre-existing.

It'd probably be a nice QoL improvement if someone would change the 
FindOpenCL.cmake file to detect an installed CUDA or Intel SDK.

You can always specify the paths as a workaround on the command line 
with -DOpenCL_INCPATH and -DOpenCL_LIBPATH to the corresponding directories.

I'm not sure if this honors -DCMAKE_PREFIX_PATH, didn't try.

On 2017-03-03 02:06, Hartmut Kaiser wrote:
> FWIW, Lars has provided us with a patch for this issue, see 
> https://github.com/STEllAR-GROUP/hpxcl/pull/40.
>
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
>
>
>> -Original Message-
>> From: hpx-users-boun...@stellar.cct.lsu.edu [mailto:hpx-users-
>> boun...@stellar.cct.lsu.edu] On Behalf Of Patrick Diehl
>> Sent: Thursday, March 2, 2017 10:25 AM
>> To: hpx-users@stellar.cct.lsu.edu
>> Subject: [hpx-users] Fwd: RE: [GSoC] Interested in Asynchronous
>> integration of CUDA and OpenCL to HPX
>>
>> FYI
>>
>>
>>  Forwarded Message 
>> Subject: RE: [GSoC] Interested in Asynchronous integration of CUDA and
>> OpenCL to HPX
>> Date: Thu, 2 Mar 2017 16:08:43 +
>> From: #SESHADRI MADHAVAN# 
>> To: Patrick Diehl 
>>
>> Hi Patrick,
>>
>> I haven't reported it yet. However it is same as Issue #38, probably we
>> could re-open it, with exactly the same error stack.
>>
>> Additionally, I am currently running older version of HPX. There was a
>> huge trouble getting it to run due to the version discrepancies between
>> Visual Studio, Boost etc. For example, there was a change in the Boost
>> serialization from 1.58 to 1.59 in the file pfto.hpp, However, the
>> upgraded versions (1.60, 1.61) still used the old code, rendering the
>> compile to be incomplete (https://svn.boost.org/trac/boost/ticket/11598).
>>
>> Also, the old versions of hpx throw up C1004 end-of-file reached error
>> (https://msdn.microsoft.com/en-us/library/4exw7xyc.aspx) which is why I
>> couldn't get them to work in Visual Studio 2012. Visual Studio 2015 also
>> throws up another error with old versions of hpx, namely the change in
>> support for Cpp
>> standards(http://stackoverflow.com/questions/146381/visual-studio-support-
>> for-new-c-c-standards),
>> this has been fixed in the latest version available on branch, but not
>> the ones before.
>>
>> Maybe, we should create a page explaining the packages of dependencies
>> and visual studio version that work well together for windows.
>>
>> The different versioning and the nightmarish build environment in
>> windows is delaying my progress at the moment, which I hope to resolve
>> it soon. I would love to just switch over to the familiar territory of
>> linux, but my other University projects heavily depend on windows.
>>
>> Additionally, I will be off for the next couple of days and will be back
>> on Sunday. I hope to get concrete ideas for the proposal by mid next
>> week. Hope this timeline is feasible with you.
>>
>> Best Regards,
>> Madhavan
>>
>>
>> -Original Message-
>> From: Patrick Diehl [mailto:di...@ins.uni-bonn.de] Sent: Thursday, March
>> 2, 2017 11:49 PM
>> To: #SESHADRI MADHAVAN# 
>> Subject: Re: [GSoC] Interested in Asynchronous integration of CUDA and
>> OpenCL to HPX
>>
>> Hi Madhavan,
>>
>> have you reported the issue on github? We also started to work at this
>> issue.
>>
>> Best,
>>
>> Patrick
>>
>> On 03/01/2017 03:48 PM, Patrick Diehl wrote:
>>> You also could reopen the issue and provide more detaisl about the
>>> compilation error.
>>>
>>> Best,
>>>
>>> Patrick
>>>
>>> On 03/01/2017 03:16 PM, #SESHADRI MADHAVAN# wrote:
 Hi Patrick,

 The error appearing seems to originate from this issue
>> https://github.com/STEllAR-GROUP/hpxcl/issues/38. I am using Windows and
>> Visual Studio 2015 for compilation.
 Seems that the fix doesn’t work completely.

 Best Regards,
 Madhavan

 -Original Message-
 From: Patrick Diehl [mailto:di...@ins.uni-bonn.de]
 Sent: Thursday, March 2, 2017 3:56 AM
 To: #SESHADRI MADHAVAN# 
 Subject: Re: [GSoC] Interested in Asynchronous integration of CUDA
 and OpenCL to HPX

 Hi Madhavan,

 cool, please send a pull request for this feature. Yes, both should be
>> provided. With respect to your last question it seems HPX in version 0.9
>> should works. This was the last version when I worked with the code.
 Please fell free to ask questions like this in our irc channel. So more
>> people could support you.
 Best,

 Patrick

 On 03/01/2017 02:47 PM, #SESHADRI MADHAVAN# wrote:
> Hi Patrick,
>
>
>
> I have one additional question, as to why the FindOpenCL.cmake was
> hardcoded to find AMDSDKs as this will allow only the AMD GPUs to be
> supported right?, I am using NVIDIA GPU a

Re: [hpx-users] updated project timeline

[Lars Viklund]

On 2016-06-09 16:29, Kuo Lu wrote:
> Hi Mr. Schafer,
>
> Here is the update: since last time I decided to parse .obj files, I
> studied this tutorial
> 
>  to

I'd like to make some comments regarding the information in that 
tutorial about the OBJ format and the things it's omitting by very 
carefully setting the export flags.

'f' directives describe a polygonal face which may have more than 3 
vertices. If it does, they'll be provided as more of the 'v/t/n' tuples 
and it's up to you to figure out how to handle N-gons or if you're going 
to triangulate them somehow.

Also on the 'f' directive, the tuples are not always on the form 
'v/t/n', valid formats are also 'v//n', 'v/t' and 'v'; omitting some of 
the components.

The indices are not always positive integers either. A negative index 
means offsetting from the last element of that kind read thus far. If 
you've got N positions read thus far, 1 would refer to the first one, 
while -1 would refer to the last one thus far.

The final pass done in that tutorial to generate a singly-indexed stream 
of vertices may not be necessary if your code can handle the kind of 
multiple indices that OBJ has, or if you only care about the positions 
and can ignore the texture coordinates and normals.

If you run into trouble reading files you've exported, you may need to 
restrict the options used to export to generate files you can handle, or 
handle the files in a more complete manner. These are the common traps 
I've run into implementing OBJ parsers in the past, I hope some of it is 
of help.

A problem you would have to face is that OBJ can at best represent 
geometry objects made up of one or more polygons. It carries no 
information about what kind of Blender object the geometry is sourced 
from like boxes / spheres / cylinders / whatever. If your task depends 
on approximating the geometry with fundamental forms, you may need to 
figure out how to deduce that from the polysoup you have.

// Lars V. -- amateur 3D graphics dabbler
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] compile error -lPUBLIC

[Lars Viklund]

On 4/25/2016 9:18 PM, Hartmut Kaiser wrote:
>
>> I'm trying to compile HPX 0.9.11 and have been having issues when the
>> cmake scripts attempt to link libhpx.so. ld complains that it can't find -
>> lPUBLIC.
>>
>> Is -lPUBLIC an internal library or an external dependency? (if it's
>> external, what package would be required to satisfy the requirment, if
>> it's internal, should I just go ahead and try building 0.9.12)
>> thanks in advance for the assistance!
>
> We don't refer to a library call named 'PUBLIC'. No idea where this is coming 
> from.
> Could you please provide us with full logs of your cmake and build steps 
> (including command line options for those)?

In newer CMake versions, you can specify PUBLIC/PRIVATE/INTERFACE 
qualifiers when setting include paths and linking in libraries, to 
indicate if something should be propagated to dependent targets or not.

PUBLIC things are used by both the target and dependent targets.
PRIVATE things are used only by the target.
INTERFACE things are used by only the dependent target.

Is it possible that we are using CMake features that are not supported 
as far back as we claim to do?

It would indeed be interesting to know what CMake version you are on and 
how you run it.
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] OpenGL Rendering in Action = Segfault in glLinkProgram

[Lars Viklund]

On 21/01/2016 18:10, Hartmut Kaiser wrote:
> Jan,
>
>> I'm still working on my parallel rendering project and can't find a
>> solution for an error for over a month now.
>> Whenever i call my rendering routine through an action (component- or
>> plain action), i get a Segfault at glLinkProgram().
>> If i call it in hpx_main() as a normal method or through std::async, it
>> works fine, so my method is not faulty (correct image, no glErrors).
>>
>> I want to call it in a component action to render 16 images on 16
>> components of a 16-core node/locality simultaneously, but the simplified
>> version of just calling it once on a 1-core locality in a plain action
>> in the hpx_main() gives the same segmentation fault.
>>
>> I know this most likely is an error on the interaction of OpenGL and
>> asynchronous actions in general, but maybe someone on this list has an
>> idea or has used OpenGL with HPX.
>
> Is OpenGL thread-safe in the first place? If you run an OpenGL function from
> inside an action and use more than one core, you might end up calling into
> OpenGL concurrently, not sure if that's a problem.

OpenGL contexts may be made current on any OS thread, but a given 
context may only be current on a single OS thread at a time.

As HPX actions may be dispatched on different OS threads over time, you
need to be very careful about which OS thread your context is current
on.

In general when doing concurrency and 3D APIs, you tend to prepare as
much work as possible in threads without invoking API functions, and
chew through the deferred work in a dedicated OS thread that has control
over the context.

While there's shared contexts and shared resources in OpenGL, they have
a bit of a performance penalty and are not quite the fast-path when it
comes to driver implementations. Some resources like FBOs and VAOs
cannot be shared at all.

As a side note on multiple contexts and function pointers for 
extensions, it's technically illegal to share function pointers between 
different contexts, but if you only have one context, you don't need to 
care about that. If you do, you may need to use GLEW-MX or similar 
extension wrangler.

> Another issue could be that you run out of stack-space. HPX threads have a
> very limited stack-size by default which is easily overflown. Try running
> your app with -Ihpx.stacks.small_size=0x2 to increase the default
> stack-sizes used.
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] OpenGL Rendering in Action = Segfault in glLinkProgram

[Lars Viklund]

On Thu, Jan 21, 2016 at 11:10:47AM -0600, Hartmut Kaiser wrote:
> Jan,
> 
> > I'm still working on my parallel rendering project and can't find a
> > solution for an error for over a month now.
> > Whenever i call my rendering routine through an action (component- or
> > plain action), i get a Segfault at glLinkProgram().
> > If i call it in hpx_main() as a normal method or through std::async, it
> > works fine, so my method is not faulty (correct image, no glErrors).
> > 
> > I want to call it in a component action to render 16 images on 16
> > components of a 16-core node/locality simultaneously, but the simplified
> > version of just calling it once on a 1-core locality in a plain action
> > in the hpx_main() gives the same segmentation fault.
> > 
> > I know this most likely is an error on the interaction of OpenGL and
> > asynchronous actions in general, but maybe someone on this list has an
> > idea or has used OpenGL with HPX.
> 
> Is OpenGL thread-safe in the first place? If you run an OpenGL function from
> inside an action and use more than one core, you might end up calling into
> OpenGL concurrently, not sure if that's a problem.

OpenGL contexts may be made current on any OS thread, but a given context
may only be current on a single OS thread at a time.

As HPX actions may be dispatched on different OS threads over time, you
need to be very careful about which OS thread your context is current
on.

In general when doing concurrency and 3D APIs, you tend to prepare as
much work as possible in threads without invoking API functions, and
chew through the deferred work in a dedicated OS thread that has control
over the context.

While there's shared contexts and shared resources in OpenGL, they have
a bit of a performance penalty and are not quite the fastpath when it
comes to driver implementations. Some resources like FBOs and VAOs
cannot be shared at all.

> Another issue could be that you run out of stack-space. HPX threads have a
> very limited stack-size by default which is easily overflown. Try running
> your app with -Ihpx.stacks.small_size=0x2 to increase the default
> stack-sizes used.
-- 
Lars Viklund | z...@acc.umu.se
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users