Hi,
Right, try again. This time the changes file included: http://celeriac.net/gpgpu25122009.zip (17MB - thanks Josh) -hope it works for you :-) Cheers, Matthew |
Better, but I'm still having trouble with the changes file. When trying to browse any of the new-ish code (including the Cobalt code), I get "MessageNotUnderstood: UndefinedObject>>isSeparator" because the image is trying to read data from past the end of the changes file. The changes file is only 229KB, which is definitely on the small side.
Did you perhaps condense changes and then not save the image? (just guessing) If I rename the changes file, at least I don't get errors, but it's difficult to read the code with decompiled temp names. However, I did run the examples. Very cool! The Lorenz attractor is beautiful. I'm looking forward to being able to browse the code! Cheers, Josh On Dec 25, 2009, at 5:36 AM, Matthew Chadwick wrote:
|
Josh Gargus wrote:
> > Did you perhaps condense changes and then not save the image? (just > guessing) that's exactly what i did, after looking up .changes files (i don't know what it's for). i thought it sounded like a good idea to save space. - will try again, but without that step... |
Matthew Chadwick wrote:
Josh Gargus wrote:ok new one uploading now, should be there in about 20 mins...same url as before |
Matthew Chadwick wrote:Josh Gargus wrote: uploaded a new image + changes (i think .changes file is ok this time) http://celeriac.net/gpgpu25122009.zip also added just the montcello files: http://celeriac.net/gpgl.zip |
In reply to this post by Matthew Chadwick-2
There's a terse explanation at: http://wiki.squeak.org/squeak/49 ... I'll elaborate.
The .changes file is a change log of code that has changed in the image. Whenever you change a method, that code is appended to the .changes file (so, for example, if you crash Squeak then your changes aren't lost forever... they can be recovered from the .changes file... see http://wiki.squeak.org/squeak/2168). The actual source code for each method isn't actually stored in the image. Instead, each method contains an index into the .changes file to look up the source code. Some implications for our situation: - if there is no .changes file, then there is no source code. However, Squeak can decompile the bytecodes in a CompiledMethod object to recover the source code. Awesome! Except that it doesn't know the names of temporary variables and method arguments, so instead of meaningful names, you see "t1", "t2", "t3", etc. - if you've been programming in an image for a while, there are probably many methods that you have changed several times. All of these versions are in the .changes file. Condensing changes rewrites the .changes file, keeping only the most recent version of each changed method; the resulting changes file is much smaller. At the same time, the methods in the image must be updated with new indices into the .changes file in order to point to the new location of their source code. If you condense changes but don't save the image, then your image will try to look for the source code in the old location in the new, smaller .changes file. Often, the old location will be past the end of the new file, leading to the error that I mentioned. Cheers, Josh On Dec 25, 2009, at 12:44 PM, Matthew Chadwick wrote: > Josh Gargus wrote: >> >> Did you perhaps condense changes and then not save the image? (just guessing) > > > that's exactly what i did, after looking up .changes files (i don't know what it's for). i thought it sounded like a good idea to save space. > > - will try again, but without that step... > |
In reply to this post by Matthew Chadwick-2
Hi Matthew,
Do you have any information on the versions/settings for
OpenGL and graphics drivers that are required to run this? I tried it on several
windows machines, including a new one (notebook though), but could not get it
working. It's a very interesting approach and I would very much like to see it
in action!
TIA
Hans From: Matthew Chadwick [mailto:[hidden email]] Sent: zaterdag 26 december 2009 0:04 To: [hidden email]; Matthew Chadwick Subject: Re: [croquet-dev] GPGPU sampler Matthew Chadwick wrote:Josh Gargus wrote: uploaded a new image + changes (i think .changes file is ok this time) http://celeriac.net/gpgpu25122009.zip also added just the montcello files: http://celeriac.net/gpgl.zip |
It uses features from OpenGL 1.5 so any card from the last couple of years should run it. Windows shouldn't be an issue, nor drivers (just make sure they're the latest I guess). It could be that your machines have crappy integrated graphics - try it on a machine with a recent discrete card & it should run. Are you getting any errors BTW ? |
Thanks for the quick reply! The machine I am using now
apparently supports only openGL 1.4 (says OpenGL Extensions Viewer) after
updating to the latest driver. Probably this is a crappy Intel thing:-).
Starting the Mandelbrot example leads to the
MessageNotUnderstood: GPGPU>>handleError:
where handleError: is send from
GPGPU>>checkForFBO
checkForFBO
"(adapted from David Fraught's code) Check for FBO support" "this is a pretty minimal check" | status | status := ogl extensions includes:
#'GL_EXT_framebuffer_object'.
status ifFalse: [ self handleError: 'FBO is not supported\Try running:\GPUInfo new chkGLSLSupport' withCRs. ] Clearly, 'GL_EXT_framebuffer_object' is not available
on my system. (handleError: is not implemented in GPGPU, nor is the class
GPUInfo available; maybe these were part of David's code?)
Hans From: Matthew Chadwick [mailto:[hidden email]] Sent: vrijdag 29 januari 2010 10:52 To: Baveco, Hans Cc: [hidden email] Subject: Re: [croquet-dev] GPGPU sampler It uses features from OpenGL 1.5 so any card from the last couple of years should run it. Windows shouldn't be an issue, nor drivers (just make sure they're the latest I guess). It could be that your machines have crappy integrated graphics - try it on a machine with a recent discrete card & it should run. Are you getting any errors BTW ? |
yeh I've not had much joy with intel chipsets either. the gpu needs FBO
and PBO, and 128/256 fp bit precision.
BTW when you do find a machine that runs it, there's an error in the Mandelbrot example - i used mac option key when i should have used yellowbuttondown (you'll see what i mean - correct it in debug) Baveco, Hans wrote:
|
Matthew Chadwick wrote:
128/256 fp bit precision. sorry that should have been 128/256 bit precision - but that's over the whole RGBA vector, meaning 32/64bit floats - it usually says somewhere in the card's spec. |
Free forum by Nabble | Edit this page |