Wednesday, June 20, 2007
Publications
So far, three of my papers has been accepted for publications:
- M. Reimers and J. Seland
Ray Casting Algebraic Surfaces using the Frustum Form
Accepted to Eurographics 2008 - C. Dyken, M. Reimers and J. Seland
Real-Time GPU Silhouette Refinement using adaptively blended Bezier Patches
To appear in Computer Graphics Forum
Draft version - J. Seland and T.Dokken
Real-Time Algebraic Surface Visualization
in Geometric Modelling, Numerical Simulation, and Optimization: Applied Mathematics at SINTEF
Draft Version
Friday, December 15, 2006
Talks and presentations
I have had the following talks and presentations:
- GPU Programming and Computing
Workshop - High-Performance and Parallel Computing
October 24, 2007, Simula Research Lab, Norway - Real time Ray-Casting of Algebraic Surfaces
Workshop on
Computational Methods for Algebraic Spline Surfaces
September 10 - 14, 2007, Strobl, Austria - Programmable Graphics Hardware
Workshop "GPU as a computational resource"
December 12th 2006 in Oslo - Implicit Surface Visualization using Graphics Hardware
Geometrical partial differentail equations: numerics and applications
Bergen 6-7 December 2006 - Programmable Graphics Hardware
Guest lecture in INF3320
22. November 2006 - Implicit Surface Visualization using Graphics Hardware
The CMA Seminar
28. September 2006
Thursday, October 27, 2005
Presentation at dagen@ifi

The Dept. Of Informatics had their yearly self-celebration event today, dagen@ifi. I presented a 45-minute talk on GPGPU programming, which was quite well received. Nothing particularly new in my presentation, but I the flow of the presentation is a bit different than the SIGGRAPH and Vis 04 tutorials everyone seem to copy.
This was also my first presentation as a researcher, and even tough it was not a very scientific event, it is very nice to have presented something in front of a large audience.
My own research is also progressing, Cristopher Dyken and I have just finished a GPU based silhouette enhancement algorithm, and we are now writing it up for publication, hopefully someone will accept it as well.
Monday, October 17, 2005
Hunting for optimizations
The last week has been an interesting experience in the unique joys of optimizing GPU programs. I know of course that Donald Knuth is often quoted as saying
Our VBOs are not very big. (For each triangle in the original mesh we determine if it is to be subject to refinement, and we render tessellated triangle for the original triangle, determining the final surface in the vertex shader.) What I wanted to do with my VBOs was to fill them with pretesselated triangles for the various levels. So my initial thought was that they were to small for VBOs to give any speedup. Still I found it a bit strange, and posted some code in the forum at opengl.org.
In the discussion that followed it was pointed out that I was passing my data as integers and could hit a nonoptimized codepath in the driver. Changing the datatype from int to float more than doubled my framerate!
This just shows how incredibly optimized the graphics drivers are to certain kinds of workloads and that experimentation and experience is the only way to get full speed on a GPU. (One could argue that this applies to CPU programming as well, but I tend to trust my compiler at bit more there.)
Premature optimization is the root of all evil in programmingHowever, we (Dyken and I) had a running prototype of our algorithm (adaptive mesh subdivision on GPU) so it was time to optimize it. We were doing everything in immediate mode, so I was quite certain that using VBO (Vertex Buffer Objects) would immediately result in a nice speedup. Alas, I was wrong. When switching to VBOs I actually saw decreased performance.
Our VBOs are not very big. (For each triangle in the original mesh we determine if it is to be subject to refinement, and we render tessellated triangle for the original triangle, determining the final surface in the vertex shader.) What I wanted to do with my VBOs was to fill them with pretesselated triangles for the various levels. So my initial thought was that they were to small for VBOs to give any speedup. Still I found it a bit strange, and posted some code in the forum at opengl.org.
In the discussion that followed it was pointed out that I was passing my data as integers and could hit a nonoptimized codepath in the driver. Changing the datatype from int to float more than doubled my framerate!
This just shows how incredibly optimized the graphics drivers are to certain kinds of workloads and that experimentation and experience is the only way to get full speed on a GPU. (One could argue that this applies to CPU programming as well, but I tend to trust my compiler at bit more there.)
Tuesday, September 27, 2005
Shallows is released!
After around four monts of work we have released version 0.90 of the shallows library. We are trying to get a blurb in all the right places, and as of this writing we are on the frontpage of both OpenGL.org and Freshmeat.net.
To recap what shallows is all about, I hereby paste the advertisement blurb here as well :-)
Shallows is an opensource (GPL) C++ library designed to make GPGPU programming easier and safer. The goal is to reduce the time spent on writing and debugging OpenGL API-related C/C++ code, so the developers of GPGPU applications can concentrate on implementing the algorithms instead. GPGPU applications are all about performance, the overhead by using shallows is therefore kept low.
In contrast to Brook and Sh the Shallows library is familiar to an experienced OpenGL developers mental view of the GPU pipeline, while at the same time checking for errors and minimize the number of codelines necessary for common GPGPU tasks.
To recap what shallows is all about, I hereby paste the advertisement blurb here as well :-)
Shallows is an opensource (GPL) C++ library designed to make GPGPU programming easier and safer. The goal is to reduce the time spent on writing and debugging OpenGL API-related C/C++ code, so the developers of GPGPU applications can concentrate on implementing the algorithms instead. GPGPU applications are all about performance, the overhead by using shallows is therefore kept low.
In contrast to Brook and Sh the Shallows library is familiar to an experienced OpenGL developers mental view of the GPU pipeline, while at the same time checking for errors and minimize the number of codelines necessary for common GPGPU tasks.
The resurrection of my blog, take 2
More than a month has passed since my last update. What have I been up to one might wonder?
Mainly, I have been working on the shallows library -- this actually deserves a post itself, which will be forthcoming.
I also went to Eurographics 2005 in Dublin. We drank a lot of Guinness, and went to a large number of interesting presentations. Next year I really hope I will be able to present something there as well.
I wrote a short article on the "gaming" side of the event which was published on hardware.no (in Norwegian only).
Well home from Dublin I was down with the flu for more than two weeks, while at the same time working on shallows from home (on my brand new Athlon 64 X2 with a 7800GT card :-) And yes, I also finally played Half-Life 2. )
Mainly, I have been working on the shallows library -- this actually deserves a post itself, which will be forthcoming.
I also went to Eurographics 2005 in Dublin. We drank a lot of Guinness, and went to a large number of interesting presentations. Next year I really hope I will be able to present something there as well.
I wrote a short article on the "gaming" side of the event which was published on hardware.no (in Norwegian only).
Well home from Dublin I was down with the flu for more than two weeks, while at the same time working on shallows from home (on my brand new Athlon 64 X2 with a 7800GT card :-) And yes, I also finally played Half-Life 2. )
Monday, August 15, 2005
Back from summer
A long time with no updates. Hopefully with a new semester starting I will post more frequently.
To summarize what has happened the last months:
1) I passed the Numerical Analysis, so now all exams for my PhD are over, allowing me to focus only on research.
2) I spent several weeks at Sintef. Writing the second generation of ShaderLib together with Trond R. Hagen and Jon Mikkelsen. The library now has a new name, Shallows and we have also created a Sourceforge project for it. Though as of yet we only use it to share CVS between the three of us.
3) I went to EMS summerschool on Subdivision in Tuscany, which was very nice and very hot!
4) Last week CMA hosted a conference on PDE-Based Image Processing and Related Inverse Problems. I helped organizing the event, and attended every session.
5) I am about to start working on a 4-phase version of the Level Set Image Segmentation, using the new Shallows library.
To summarize what has happened the last months:
1) I passed the Numerical Analysis, so now all exams for my PhD are over, allowing me to focus only on research.
2) I spent several weeks at Sintef. Writing the second generation of ShaderLib together with Trond R. Hagen and Jon Mikkelsen. The library now has a new name, Shallows and we have also created a Sourceforge project for it. Though as of yet we only use it to share CVS between the three of us.
3) I went to EMS summerschool on Subdivision in Tuscany, which was very nice and very hot!
4) Last week CMA hosted a conference on PDE-Based Image Processing and Related Inverse Problems. I helped organizing the event, and attended every session.
5) I am about to start working on a 4-phase version of the Level Set Image Segmentation, using the new Shallows library.
Friday, May 13, 2005
Status report on the Level Set
Those who regularly(?) have read my blog, will know that I have been working on a Level Set Segmentation algorithm for ages. For me it at least feels so.
It is finally shaping up, and I am now stepping through every calculation and verifying the against the original Matlab code.
I do think most calculations are in place and correct. But since I have been using multiple PBuffers, it is very important to be careful wrt. what PBuffer is active when reading and writing subbuffers.
I am now hopeful I will get the algorithm up and running during next week!
It is finally shaping up, and I am now stepping through every calculation and verifying the against the original Matlab code.
I do think most calculations are in place and correct. But since I have been using multiple PBuffers, it is very important to be careful wrt. what PBuffer is active when reading and writing subbuffers.
I am now hopeful I will get the algorithm up and running during next week!
