Brandon Barker wrote:
> Is there any further news about OpenCL being supported on Solaris? It really
> seems like this will be a must-have API for many scientific workloads in the
> near future.
>
>
No recent updates. We are still in discussions. I did a
proof-of-concept port
of CUDA fo
Nils Goroll wrote:
> Hi,
>
> I am trying to compile and get to work GLanalyzer on OpenSolaris/x86.
>
> The code is using a lot of SUN specific GL functions which don't exist
> for x86/NVIDIA. Has anyone taken on the effort yet to make the
> necessary adjustments?
>
> If so, I'd be very interested
Rayson Ho wrote:
> On Mon, Mar 2, 2009 at 7:13 PM, John Martin wrote:
>
>>> 1) Best way to replace /proc/cpuinfo for OpenSolaris?
>>>
>>> opencc -v
>>> opencc WARNING: cannot read /proc/cpuinfo, defaulting to basic 32-bit x86.
>>>
&
C. Bergstr?m wrote:
>
>
> 1) Best way to replace /proc/cpuinfo for OpenSolaris?
>
> opencc -v
> opencc WARNING: cannot read /proc/cpuinfo, defaulting to basic 32-bit
> x86.
This code is looking for the plain text processor description, e.g.
"Intel(R) Core(TM) i7". On Solaris this can be fetched w
C. Bergstr?m wrote:
>
>
> I just glanced at it, but looks like Elf32_Word and friends is
> undefined..
>
> ../include/elf_stuff.h:57:23: warning: sys/cdefs.h: No such file or
> directory
>
> pm me if you'd like access to the env to help or look around.
>
>
This is in the linux include directory.
Joerg Schilling wrote:
> John Martin wrote:
>
>
>> This biggest headache I had doing the port was asprintf()/vasprintf().
>> There was a lot of code that used these functions. Once we have this
>> with b107,
>> it will make things a lot easier.
>>
C. Bergstr?m wrote:
> To follow up on this very old thread.. John.. I'm not sure if you ended
> up recreating that work you said you would, but didn't want to bother
> you... Another guy on our team started to take the port up again
> recently.. Some of the missing functions are now available i
G?rard Henry wrote:
> 2) totalview
> i launched totalview on a linux machine, and displayed it on my
> opensolaris laptop and it is unusable,
Can we get details for both systems to reproduce the problem?
Javier Iparraguirre wrote:
> I agree with Attila.
>
> Additionally, I think that Tesla + UltraSPARC T2 has the potential to
> create a supercomputer in a box.
There's very little I can say about this other than NVIDIA and I have
discussed
what it would take to get CUDA running on SPARC. Byte ord
G?rard Henry wrote:
> hello all,
> i'm trying to compile scipy-0.6.0 with SS12 on solaris 10 machine.
> I followed notes here:
> http://blogs.sun.com/yongsun/entry/build_scipy_0_6_0
>
> but it failed with 3 errrors:
> "scipy/sparse/sparsetools/sparsetools.h", line 409: Error: multiplies is
> not a
Harshal wrote:
>
>
>
> If its techically possible, but not supported either by SUN or
> NVIDIA... is there any chance to make it available to users for
> use-at-your-own-risk kind of thing.
NVIDIA owns the software so it is their call. I can forward requests
for NVIDIA to get their permission f
Fellingham Linda wrote:
>
>> There is support for nVidia Tesla S1070 on Solaris? Which update,
>> build?
>>
I don't know the status of contractual support, but the S1070 requires the
R177 driver that first went into Nevada build 100 and will be in
OpenSolaris 2008.11.
I believe we are still
kevin wrote:
> In linux, I can use "taskset" to assign a task to whichever cpu I want:
> taskset -c 0 a.out
> then a.out is assigned to be execute on the first cpu.
>
> In Solaris, I find the command "pbind" can bind pid to some cpu, but it is
> inconvenient:
> SYNOPSIS
>pbind -b processor
C. Bergstr?m wrote:
> What about uu_msprintf?
>
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4508459
>
> Which describes exactly this problem, but doesn't look like that will
> get resolved in ON any time soon.. I'm pretty sure this will be all
> resolved in one way or another by
C. Bergstr?m wrote:
> I've got enough on my TODO list to keep busy for a couple days,
> but I'm feeling quite optimistic we can get this upstream in the
> foreseeable future.
>
The two biggest issues I had were:
1. The build environment depends upon the default shell being bash.
If the defa
Rayson Ho wrote:
>
> If you can share the changes, I believe Chris and I will be able to
> merge it to the official tree, as many other members of Open64 are
> interested in the Solaris/AMD64 port.
>
>
All of the changes I made were to code I left at the vendor site. [The
vendor
does monitor
Rayson Ho wrote:
> Just want to see if anyone on the lists is interested in getting the
> Open64 compiler ported to Solaris/OpenSolaris on the AMD64/EM64T
> platform...
>
> (And FYI: PathScale is based on Open64...)
>
> Please join the Open64 project if you are interested!!
>
I have ported open6
17 matches
Mail list logo