Stephane Marchesin wrote: > On Fri, Oct 24, 2008 at 08:29, Ioannis Papadopoulos > <[EMAIL PROTECTED]> wrote: > > >> I should have written "task scheduling and management". Yes, the threads are >> OS handled but everything else has to be handled by a runtime system. This >> means using some efficient way one has to create and schedule tasks to >> achieve maximum speedup. Moreover, the threads have to be able to be reused >> for different tasks, taking care about cache affinity etc. - these are all >> handled rather successfully by OpenMP. >> > > Well, not really. In my experience OpenMP is good when you have few > parallel sections, because the overhead for entering/leaving parallel > sections is too high. And that's not the case with mesa. > It's a fork-join model with implicit barriers at the end of each parallel section. However, you can get rid of them if you have one big PARALLEL part and use inside the nowait in any other directive. In OpenMP 3 you can also define tasks instead of just sections. >>>> 3) OpenMP is easy even for beginners in parallel processing >>>> 4) you can always remove OpenMP by telling the compiler that you don't >>>> want support (ok, even for pthreads you can do that, but manually) >>>> >>>> >>>> >>> Well, in my experience, OpenMP also has a number of disadvantages. >>> Granted it is very easy to write your first parallel program with it, >>> but it is also extremely fragile, because the parallel semantics can >>> be left implicit (which in my experience leads to a high number of >>> bugs that are difficult to find). Basically, once you tackle bigger >>> programs, you end up adding a lot of shared/private statements >>> everywhere, which becomes untractable inside big codes like mesa. >>> >>> >> Likewise, the pthread solution needs to put the locks in the correct places, >> use volatile etc The worse is that you have to maintain it as well. >> > > Well, my opinion is that once you're at the level where you've > separated shared variables from private ones, I think you might as > well use pthreads. > > (And FWIW, using volatile in threaded code means you've lost already. > volatile often means spinlocking. volatile doesn't enforce atomicity > so you also have to use memory barriers. as a rule of thumb one should > never use volatile for variable sharing in threaded code) > spinlocking is useful when you have a thread that is mapped to a dedicated processor and has nothing else to do - switching threads costs. That's were I'd use volatile - it doesn't enforce atomicity (and neither does the memory fence). Basically, I mean we have to reimplement everything should one goes with pthreads.
I'm already following Brian's advice and looking into the cell driver: basically, I'm trying to fuse them back to a common codebase (not separate the PPU logic from the SPU), see what are the tasks, what dependencies are there and how easy would be to schedule them (if it's embarrassingly parallel, the pthreads or OpenMP doesn't really matter). Brian, does the cell driver scale well when you go from 1 SPU to 8? >> Although normally I'm not a very strong advocate for OpenMP, in this case I >> think it fits the task completely: I tend to see OpenGL as just operations >> on matrices, which means that data parallelism is there and can be best >> exposed using OpenMP. >> > > Well, I agree here, my experience with OpenMP tells me that I wouldn't > want to deal with it for anything else than very constrained and > simple pieces of code (like you say, for example large matrix > multiplies). But the problem is that OpenGL is quite far from > operations on matrices, the complexity is above that; if mesa was only > doing matrix operations, we'd have it written in linpack already. For > example the cache friendlyness is more complex when you access > textures and vertex attributes, and then OpenMP fails big time... > > Stephane > If I'm not mistaken, the critical path is basically operations on vectors/matrices - I'm not an expert on graphics, but I thought that's the reason why the GPUs look a lot like vector processors. Giannis ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
