Re: [Discuss-gnuradio] Upcoming changes in the development trunk

[Eric Blossom]

On Thu, May 28, 2009 at 12:51:31AM +0200, Martin DvH wrote:
> On Wed, 2009-05-27 at 08:12 -0700, Johnathan Corgan wrote:
> > On Wed, May 27, 2009 at 7:35 AM, Martin DvH
> > <address@hidden> wrote:
> > 
> > >> * Elimination of the single-threaded flowgraph scheduler.  The
> > >> "thread-per-block" scheduler is already the default in 3.2.  While this
> > >> won't require any code changes, if you've been manually selecting the
> > >> STS via the environment, you won't be able to do this anymore.
> > >
> > > Is it really neccesary to remove this?
> > 
> > Not strictly necessary, no.  A lot of the new features in 3.3 will
> > impact the scheduler, especially the new message passing between
> > blocks.  It will be extra work to modify both schedulers.  This is
> > Eric's area, however, so I'll let him comment further.
> > 
> OK, I get the picture.
> Since my single-threaded gpgpu-scheduler needs modifications as it is.
> Maybe you should implement the multi-threaded-scheduler and leave the
> scheduler choosing mechanism in place, and only leave stubs for the
> single-threaded case.
> I then could have a go at (trying to) implementing it for the
> single-threaded (gpgpu ) case.
> 
> Eric, what's your view on this?

I'm going to remove the STS, but can probably leave the choosing
mechanism in place.  I don't see a reasonable way to get the new async
message passing + data flow model implemented on top of the STS.

FYI, there are some guys at the DSPCAD group at the Univ of Maryland
who are figuring out how to get their static data flow scheduler to
read a GR flow graph description and generate schedules for various GPUs.

Eric