Eric Daoust's GSoC midterm deliverables:

1) Sped up nohalo level 1 code.

2) New fast resampling method targeted for downsampling (without the affine transformation info passed from "above," and without variable size buffers, which will be implemented later in the SoC). This will be the lower quality (but most likely very fast) version.

(I'll email RE: Adam's deliverables when I have them nailed down. Adam is currently focusing on the much trickier nohalo level 2 and buffer issues.)

Nicolas Robidoux Universite Laurentienne

Michael Schumacher wrote:

Mentors and students, please do agree on the desired midterm goals for your projects, and present them on the gegl-developer list.

Hi

The midterm goals for the GEGL-on-GPU GSoC project is to implement a few point ops as pixel shaders and to get GEGL to actually do processing on the GPU using these ops

/ Martin

Adam Turcotte's midterm deliverables:

-- Figure out how to use/adapt/emulate intermediate buffers to store intermediate results (kind of like nohalo runs on the GPU: intermediate buffer would be like a texture).

-- Figure out how to use/adapt/emulate variable size sampler buffers for non-recursive reasonable quality downsampling.

-- Make good progress in implementing the above (hopefully, be done)

nicolas

Argh!

My explanation (RE: Adam's GSoC deliverables) was terrible (Adam just called me on it).

What I meant:

Somehow allowing a variable footprint (stencil) in (re)samplers. Right now, the footprint is fixed (from
gegl/gegl/buffer/gegl-sampler-cubic.c):

GEGL_SAMPLER (self)->context_rect.x = -1; GEGL_SAMPLER (self)->context_rect.y = -1; GEGL_SAMPLER (self)->context_rect.width = 4; GEGL_SAMPLER (self)->context_rect.height = 4;

The RHS's are arbitrary, but I don't think they can be changed at run-time on a pixel by pixel basis (or even on a run by run basis?).

Hopefully, it makes sense now.

We already have some ideas of how to emulate it.

Nicolas Robidoux

Quick note:

Adam knows tons more about object oriented programming (in C) than I do. So, even if I write something stupid, don't assume that HE does not know what he's doing.

(He's the "strong quiet type" ;-)

Nicolas Robidoux

On Sat, Jun 20, 2009 at 12:14 AM, Nicolas Robidoux wrote:

Quick note:

Adam knows tons more about object oriented programming (in C) than I do. So, even if I write something stupid, don't assume that HE does not know what he's doing.

Strong and silent doesn't really work in terms of being involved with a development community. The students should be strongly encouraged to involve themselves with our development community on the mailing lists; or if not there at least on the IRC channels. The technical - code - achievements probably will be greatly helped by direct communication. Communication by proxy might work for some of the project specific technical questions, for the general programming and architecture related issues it doesn't.

The students need to get involved in direct communication or we might have to fail them at the midterm.

/Øyvind K

For clarification here's my mid term deliveries as extracted from the email exchange "Perf tools evaluation and proposal"

Step 1 - SELECTION - user workflow: 1a) Select the libraries of interest 1b) Select the entry/exit function (normally the main function), i.e. only data measured inside this function (including calls to other functions) is displayed
1c) Hotpath elaboration. I.e. display and selection of the code execution path to display. (TBD)

This is to be implemented in a web-interface (in a very simple manner to start with...)

In other words the code to be delivered should be able to import valgrind data, add it to a database and display it (as detailed above).

Henrik

2009/6/23 Øyvind Kolås :

On Sat, Jun 20, 2009 at 12:14 AM, Nicolas Robidoux wrote:

Quick note:

Adam knows tons more about object oriented programming (in C) than I do. So, even if I write something stupid, don't assume that HE does not know what he's doing.

Strong and silent doesn't really work in terms of being involved with a development community. The students should be strongly encouraged to involve themselves with our development community on the mailing lists; or if not there at least on the IRC channels. The technical - code - achievements probably will be greatly helped by direct communication. Communication by proxy might work for some of the project specific technical questions, for the general programming and architecture related issues it doesn't.

The students need to get involved in direct communication or we might have to fail them at the midterm.

/Øyvind K --
«The future is already here. It's just not very evenly distributed»                                                 -- William Gibson http://pippin.gimp.org/                            http://ffii.org/