is the next major testing
platform for wine. Test suites are the most important, but application
testing can mean knowing when new software works in wine and from a user
standpoint of view more "interesting" and applicable than what test suites
are getting passed.
-Seth Shelnutt
[1]ht
23 and 53.
Port 53 is reserved for DNS gateway, but since I don't run one that isn't an
issue on mine end. Do you have anything against running on port 53?
Thanks,
Seth Shelnutt
On Thu, Aug 18, 2011 at 7:29 PM, Dan Kegel wrote:
> http://buildbot.kegel.com/ caught a couple of rea
I've never used fedora but my playing around with opencl in gentoo the
libonpencl.so only can come from two sources, the nvidia driver or the ati
stream sdk. So you might want to look at the binary driver for nvidia.
That's my only guess.
-Seth
On Jan 20, 2011 10:34 AM, "Max TenEyck Woodbury"
wro
Reece,
I have to agree with you on the idea of just using UIAutomation and then
using the MSAA bridge/proxy for MSAA support in the end. This leaves only
one implementation in wine, requires only one to be implemented. It's likely
that eventually MSAA will be phased out. Although since MSAA is alr
worked out I'm hoping to see what needs to be done to get
MSAA supported under wine.
Thanks,
Seth Shelnutt
For ati there is also GL_ATI_mem_info [1] or WGL_AMD_gpu_association [2] . I
believe that [1] is now obsolete as from reading some of the wine-dev
mailing list [3], and some other site it seems AMD is now pushing the using
of WGL_AMD_gpu_association instead. A patch could be written in the exact
sa
pable device and thus is the reason for programs such as fold...@home to
fail in wine when using these cards.
Thanks,
Seth Shelnutt
From 74a2f691b6ff377ac412ec2689edbb3975d491c5 Mon Sep 17 00:00:00 2001
From: Seth Shelnutt
Date: Mon, 12 Jul 2010 22:56:37 +
Subject: The Nvidia Geforce 8400 and
simpler and created
less overhead for just two GPU's that probably don't represent a large
population. I think the 8400 should be tied to the 8500 or on it's own. If
you put the 8400 back with the 8300 then someone might run into the same
issue we are having now.
Thanks,
Seth Shelnu
the drivers to help with this issue. For now
though I just submitted a patch to deal with the issue of a 8500/8400 being
reported as a 8300. I moved the detection to be reported as an 8600. I
thought about creating a new 8500 in the database but I realized that an
8600 is of feature parity and has the same video memory minimum.
Thanks,
Seth Shelnutt
now. There is no lose of functionality and while yes this new code will
be added and a lot of the hard coded values will remain, this at least
provides some level of automatically determining these values and support
for newer cards or cards that have not been hard coded in.
What are your thoughts?
-Seth Shelnutt
com and
just go through the list of the cards.
Thanks,
Seth Shelnutt
) {
WINE_TRACE("\n");
return cudaGetDeviceProperties(prop, device);
}
Also your linking looks off. You shouldn't be linking -l"." . You need to
specify the exact file, like for CUDA we did -lcudart or -lcufft.
I hope that help you some.
-Seth Shelnutt
On Wed
haredVar':
cudart.c:825: warning: 'return' with a value, in function returning void
cudart.c: In function 'wine_cudaRegisterFunction':
cudart.c:831: warning: 'return' with a value, in function returning void
winegcc -shared cudart.dll.spec -mno-cygwin -o cudart.dll.so cudart.o
-L/usr/local/cuda/lib/ -lcudart -lodbc32 -lole32 -loleaut32 -lwinspool
-lodbccp32 -luuid
If anyone has any ideas about why this doesn't work, that would be great.
I've exhausted everything I could think of.
Thanks,
Seth Shelnutt
ondering if you guys have
any idea of the top of you head.
Thanks,
Seth Shelnutt
On Wed, Jun 2, 2010 at 8:06 AM, Roderick Colenbrander <
thunderbir...@gmail.com> wrote:
>
>
>
> Sure the code is in directx.c but the I suspect the issue Seth is
> seeing is that differe
eporting. I've searched but
I can't find this driver DB, so I don't know what 0x0006000f-0x000b21aa
corespondent too. Can someone point me in the right directions?
Thanks,
Seth Shelnutt
text+0x5140): undefined reference to `__cuda_exp2f'
cudart.o: In function `__internal_double2ll_kernel':
cudart.c:(.text+0x6130): undefined reference to `__cuda___isnan'
cudart.o: In function `__internal_double2ull_kernel':
cudart.c:(.text+0x6383): undefined reference to `__cuda___isnan'
cudart.o: In function `clock64':
cudart.c:(.text+0x7f61): undefined reference to `__cuda_clock'
Thanks,
Seth Shelnutt
Patchwatcher is suppose to sort of do this. It only works for linux, not
other systems, but it will not only check your patch against compiling but
also against the test suit and mark and regressions.
he scripts is to copy them into the ~/.appinstallcache folder after it's
created and before the tests are run.
Thanks,
-Seth Shelnutt
the point of integration.
> - Dan
>
I look forward to seeing his proposal. Will he be bring patchwatcher back to
life, but in buildbot form?
-Seth Shelnutt
e info see
http://folding.stanford.edu/ or
http://www.overclockers.com/forums/forumdisplay.php?f=21).
Thanks,
Seth Shelnutt
2010/2/16 André Hentschel
> Just some ideas by me:
>
>
>
> Dan Kegel schrieb:
> > Seth Shelnutt wrote:
> >> I am wondering what that status of patchwatcher is?
> >
> > It's waiting around for somebody to have time to start it
> > up aga
nouncement of my intent I'm just trying to see how things stand now.
Thanks,
Seth Shelnutt
ere it's at/what needs
to be done.
Thanks,
Seth Shelnutt
2009/12/12 André Hentschel
> Tom Wickline schrieb:
> > I was thinking sense your about to revise this area why not just do it
> > now and have it over with?
> > But yea I suppose Wine support on ARM is in the ea
gdk-x11-2.0.so.0
/usr/lib/libgdk-x11-2.0.so.0.1600.1
Thanks,
Seth Shelnutt
s but I don't know if is considered a large enough project for GSoC.
Thanks,
Seth Shelnutt
On Wed, Mar 18, 2009 at 7:17 PM, Kai Blin wrote:
> Hi folks,
>
> Wine has been accepted into the Google Summer of Code 2009.
>
> If you're a student interested in working on Win
- core: http://fah-web.stanford.edu/ihaque/FahCore_14.exe
MD5 hash: 4e4621e3cbe1e4069c264c449615c127
- WU: http://fah-web.stanford.edu/ihaque/wudata_01.dat
MD5 hash: 8d4e47c17445a8deca403caa52fbcb6f
Thanks for the help,
Seth Shelnutt
can't update it, and port it
to the latest GIT of Wine and see how it does. See if it works as well as
the CUDA wrapper, or the CAL wrapper. See if there is a benefit or not to
having this support.
Thanks,
Seth Shelnutt
saw some of my recent question
on a win to lin wrapper, and though I was the same person. Interesting
enough there happens to be another Seth who trolls the Wine mailing list!
-Seth Shelnutt
On Fri, Feb 20, 2009 at 4:44 PM, Shlomi Fish wrote:
> Hi Seth!
>
> On Fri, Jan 23, 2009 at 4:46 A
s could simply be kept in
the registry for easy editing, and adding of libraries without the need to
recompile wine.
Hopefully I've put my idea across clearly. What are everyone's thoughts?
Thanks,
Seth Shelnutt
On Fri, Feb 13, 2009 at 8:15 AM, Ben Klein wrote:
> 2009/2/13 SorinN :
> > it could be done with jQuery
>
> I hear this a lot. Is it really such a good idea? I'd argue a site not
> requiring Javascript to function is much cleaner, friendlier and more
> accessible.
>
>
>
I agree, with the no javas
r. I think
it shows just how advanced Wine is. Not only can it run a windows program
but with a wrapper it transfers the calls from windows dll to linux .so to
the GPU, with stellar performance.
-Seth Shelnutt
On Sun, Feb 1, 2009 at 12:48 PM, Dan Kegel wrote:
> I'm going to be g
It seems when using this wrapper and a cuda enabled program, it causes the
program/wine to use 100% of a CPU core, while running in windows the FaH GPU
client only takes around 10-15% at most of a CPU core. Any ideas why the
sudden jump to 100% use? It makes the systems most unusable in the normal
abled card so I
can't test anything.
The source files are viewable here,
http://shelnutt.twomurs.com/patches/cuda/
and as a 7z file.
http://shelnutt.twomurs.com/patches/cuda.7z
Binary file is available under
http://shelnutt.twomurs.com/patches/cuda/bin/
Thanks,
Seth Shelnutt
05 flags 0 addr
0xf7fddaaf
[EMAIL PROTECTED]:~/.wine/drive_c/Program Files/[EMAIL PROTECTED]
/[EMAIL PROTECTED]
Thanks,
Seth Shelnutt
On Sun, Jul 13, 2008 at 5:26 AM, Michael Karcher <
[EMAIL PROTECTED]> wrote:
> No, thats boring. Your program crahsed at address 0xf7fcaaf. IIRC code
>
some features are missing in the Linux version. If that is
> true, the only thing you can do is to contact Nvidia and ask them for help
>
>
>
>
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Seth Shelnutt
> *Sent:* Wednesday, July 09, 2008 7:
Well at least it compiled, but it isn't working. We are still getting the
message that the function isn't implemented.
Initializing Nvidia gpu library
cudaMalloc CUDAStream::Allocate failed feature is not yet implemented
Now both cudamalloc and all four cuda stream's, cudaStreamCreate, Destroy,
I've spent the whole day reading different things and I'm just not sure why
it is creating an empty file. I'm still getting the same error messages even
when using winemaker correctly.
[EMAIL PROTECTED]:~/wine/patches/cuda$ make
winegcc -shared cuda.dll.spec -mno-cygwin -o cuda.dll.so cudart.o
/us
I think I am using winemaker wrong. It does not give me a .res file as the
winelib user's guide says I need, and the guide says I should be getting a
Makefile.in and configure script. When I try to use it and link to the
libcudart.so.2.0 file it acts like the target directory is libcudart.so.2.0
[
one
Also after that I get an error about libcudart.so.2-LhAtfa.o is an empty
file. What is that LhAtfa.o? Of course it is an empty file as far as I know
that isn't a real file. What is it trying to link to?
Thanks,
Seth Shelnutt
On Mon, Jul 7, 2008 at 5:59 PM, Juan Lang <[EMAIL PROTECT
urn cudaGLUnregisterBufferObject( bufferObj );
}
/*Direct3D functions were skipped, implementation at a later time*/
cudaError_t WINAPI wine_cudaGetLastError( ){
return cudaGetLastError( );
}
cudaError_t WINAPI wine_cudaGetErrorString( ){
return cudaGetErrorString( );
}
#
# File: cudart.dll.spec
#
# Copy
I just have a makefile. No makefile.in. Perhaps I used winemaker wrong? I
simply did "winemaker --dll cuda".
On Mon, Jul 7, 2008 at 5:00 PM, John Klehm <[EMAIL PROTECTED]>
wrote:
>
>
> Check the IMPORT variable in Makefile.in and see if everything you
> need is listed.
>
> --John
>
Ah ok, now I understand.
I am having a problem with the opengl section of it. It doesn't like GLuint
. I've added the gl.h file to my list of headers as I thought maybe I needed
the header to define it. But it still doesn't like it. Here are the errors,
and one of the lines of code. I've googled i
The compiler chokes on the C++ coding that you pointed out. I'm not sure
exactly how to handle it, maybe just convert it all to c syntax? For now
I'll just commit out those lines and just work on trying to get something to
compile.
Now are you saying the code should be,
retval, WINAPI wine_cudaGet
. Of course the 5.5 part doesn't apply then as
> well.
>
>
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Seth Shelnutt
> *Sent:* Sunday, July 06, 2008 6:29 PM
> *To:* Michael Karcher
> *Cc:* wine-devel@winehq.org
> *Subject:* Re: CUDA wrapper
I writing a wrapper, would it be correct to more or less follow this guide,
on winelib dll's? http://www.winehq.org/site/docs/winelib-guide/bindlls
I've never coded anything for Wine before so I want to make sure I do it
right from the beginning instead of having to go back and make drastic
change
>From reading the programing guide and reference manual it seems that most of
the function are the same as expected between Windows and Linux, in fact the
reference manual doesn't differentiate between the two.
http://developer.download.nvidia.com/compute/cuda/2.0-Beta2/docs/Programming_Guide_2.0b
place to start would be to
download the SDK's and see how much documentation is available on both the
Linux and Windows calls.
-Seth Shelnutt
r Wine. I'll stop the all caps
now ;).
On Sat, Jul 5, 2008 at 9:44 PM, Jeff Zaroyko <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 6, 2008 at 11:11 AM, Seth Shelnutt <[EMAIL PROTECTED]>
> wrote:
> > After replacing the driver "Display" with "nv4_display.
and some other things. This is because we
> can't get pci ids from X, relying on e.g. /proc/bus/pci/devices is not the
> way to go.
>
> Roderick
>
> > Datum: Sat, 5 Jul 2008 00:17:09 -0400
> > Von: "Seth Shelnutt" <[EMAIL PROTECTED]>
> > An: win
ause it talks
> to the Windows hardware drivers. Thus we need an implementation of this
> cudart.dll which calls the Linux cuda cudart.so instead. (And then hope it
> works out)
>
>
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Seth Shelnutt
> *
Interesting. So it is not to difficult. Now is there anyway to change these
settings without compiling a custom version of WINE? I don't have a problem
compiling WINE but I'm sure not ever person out there would want to. I think
for now I wil just compile a version and host it for people to try out
rivers can then handle them and run it all fine and dandy.
Here is the post, with error message about wrong graphics card detected,
http://www.ocforums.com/showpost.php?p=5698997&postcount=19 .
Thanks,
Seth Shelnutt
52 matches
Mail list logo
