This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
I've compiled and run hwloc 1.6.1 on my development machine (Scientific
Linux 6.2) currently with 1) GTX-480 and everything seems to be working
[kalloyd_at_devhost ~]$ lstopo -v
Bridge Host->PCI L#0 (P#0 buses=0000:[00-08])
Bridge PCI->PCI (P#48 busid=0000:00:03.0 id=8086:340a
class=0604(PCI_B) buses=0000:[02-02] PCIVendor="Intel Corporation"
PCIDevice="5520/5500/X58 I/O Hub PCI Express Root Port 3") "Intel
Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 3"
PCI 10de:06c0 (P#8192 busid=0000:02:00.0 class=0300(VGA)
PCIVendor="nVidia Corporation" PCIDevice="GF100 [GeForce GTX 480]")
"nVidia Corporation GF100 [GeForce GTX 480]"
lstopo --whole-io shows much more detail, including both sides of the
I haven't yet written an OpenMPI, OpenGL program to see how it works
across a small cluster, but that will give me something to do in my
spare time ...
On Tue, 2013-02-12 at 23:37 +0100, Brice Goglin wrote:
> Stefan (or anybody else interested in hwloc GPU support),
> Did you have any chance to look at this?
> Le 01/02/2013 14:57, Brice Goglin a Ã©crit :
> > I just committed big changes to the display branch (and I also merged
> > latest trunk changes).
> > lstopo will now report things like this:
> > PCI 10de:06d1
> > GPU L#0 ":0.0"
> > GPU L#1 "cuda0"
> > GPU L#2 "nvml0"
> > The changes include:
> > 1) We don't have a "display" specific OS device anymore, it's just
> > another kind of GPU among cuda, opencl and nvml. The name is the X
> > server display name. There are string attributes in these new GL GPU OS
> > devices (lstopo -v):
> > GPU L#9 (Backend=GL GPUVendor="NVIDIA Corporation" GPUModel="Tesla
> > C2050") ":0.2"
> > 2) The gl component is now buildable as a plugin
> > 3) Given (2), we can't expose internal GL routines in the public API. So
> > hwloc/gl.h is just made of inline helpers as any other hwloc/foo.h. It
> > now contains functions to convert between displays (name or port/device)
> > and hwloc OS devices:
> > hwloc_obj_t hwloc_gl_get_display_osdev_by_port_device(hwloc_topology_t
> > topology, unsigned port, unsigned device)
> > hwloc_obj_t hwloc_gl_get_display_osdev_by_name(hwloc_topology_t
> > topology, const char *name)
> > int hwloc_gl_get_display_by_osdev(hwloc_topology_t topology, hwloc_obj_t
> > osdev,unsigned *port, unsigned *device)
> > If you really need the PCI device, just use osdev->parent as documented.
> > If you need the locality, use hwloc_get_non_io_ancestor(topology,
> > osdev)->cpuset
> > See tests/gl.c for examples.
> > Please review hwloc/gl.h and let me know if that works for you. I hope I
> > used the words port/device/server/screen as expected.
> > The last thing on my TODO list is to decide is whether we keep the "GL"
> > name or switch to something among display/X11/X/... for filenames and
> > function names.
> > Brice
> hwloc-users mailing list
Kenneth A. Lloyd, Jr.
CEO - Director of Systems Science
Watt Systems Technologies Inc.
Albuquerque, NM US
This e-mail is covered by the Electronic Communications Privacy Act, 18
U.S.C. 2510-2521 and is intended only for the addressee named above. It
may contain privileged or confidential information. If you are not the
addressee you must not copy, distribute, disclose or use any of the
information in it. If you have received it in error please delete it and
immediately notify the sender.