Well, I'm working all the time with pthreads, OpenMP and MPI. I'm also familiar with Intel's TBB. The all have their pros and cons - and I'm only talking for shared-memory applications, as a distributed memory implementation would have too much latency (people have been using MPI even for applications on shared-memory machines with mixed results).
I was thinking about pthreads, but the problem is: 1) there is no portable way of supporting atomic operations (OpenMP has a directive for that). Moreover, you have to maintain coherency and avoid race-conditions using the volatile keyword and locks. In OpenMP all this is done by the compiler. 2) one has to implement the scheduling and task management (OpenMP does that already and OpenMP 3.0 which is around the corner will support that even better - there is already a nearly done branch for v3.0) 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) On the other hand pthreads allow you to micromanage everything - what to execute where etc. thus maybe you can achieve optimal parallelism. Gallium3D seems interesting, I'll look into it - actually it boils down everything to have just a gallium-softpipe-multithreaded. Will the Gallium infrastructure eventually replace every driver in Mesa or is just another driver? Brian Paul wrote: > > I'm not sure of the merrits of OpenMP vs. pthreads but a few comments: > > As Ben suggested, probably the best way to take advantage of multiple > processors is to begin by parallelizing rasterization. Fragment > processing (in particular when there's lots of texture sampling or > non-trival fragment shaders) is the typical bottleneck. In other > cases, vertex transformation could be the bottleneck, but I don't > think that's as often the case as fragment processing. > > If you want to start looking at code, I'd suggest you work on the > gallium softpipe driver, as that's the future. Also, you might look > at the Cell driver which I've been working on. It divides the window > into tiles which are rendered by the Cell's SPUs. > > I'm not too familiar with OpenMP. When you talk about OpenMP, are you > talking about parallelizing across multiple machines and simulating > shared memory across a network? Or is it just for shared-memory > multiprocessors? I wouldn't bother with the former. > > I'm pretty comfortable with pthreads so I wouldn't hesitate to go that > way. > > -Brian > > > Ioannis Papadopoulos wrote: >> I'll look into that, seems like starting point and is coarse-grained >> enough. Thanks. >> >> I have spend some time looking into the Larrabee architecture and it >> was basically my inspiration: at some point, all these processors >> will probably live in the main CPU that will contain 100s of simple >> cores and then just a very simple hardware to actually show the >> buffer on the screen. Then it makes sense to have a scalable solution >> for software OpenGL on many cores. >> >> Ben Harper wrote: >>> I'm pretty ignorant of the Mesa internals, but my first stab at such a >>> thing would be to try and parallelize the triangle rasterizer by >>> splitting the framebuffer into tiles of say 64x64 pixels, and have a >>> queue for each of those tiles. Then, you have a pool of rasterization >>> threads that consume the work in each queue. You'd need to duplicate >>> triangles that fall into multiple tiles.. but I'm guessing that would >>> be the worst of the work. In case you haven't already, I would >>> recommend reading Intel's paper on larrabee that was presented this >>> year at siggraph. >>> >>> Ben >>> >>> On Thu, Oct 23, 2008 at 9:18 AM, Ioannis Papadopoulos >>> <[EMAIL PROTECTED]> wrote: >>> >>>> Hi, >>>> >>>> I'm interested in parallelizing some parts of Mesa using OpenMP. I >>>> don't >>>> know if anyone has tried it however I think it worths a shot. >>>> >>>> I'm aware of pMesa, but it's not exactly what I have in mind. I'm more >>>> interested in seeing how well would Mesa behave in a manycore chip >>>> (although there is not one available currently). More specifically, I >>>> want to see what speedups I can get using 2-16 cores and OpenMP, >>>> without >>>> any hardware support. For example, on my small Core2 Duo, nVidia 8400M >>>> GS is 4-5x faster in OpenGL than Mesa using 1 processor in glxgears - >>>> theoretically, if I assume that I can parallelize decently (minimize >>>> OpenMP barriers, have good load balancing) with 6 cores one can match >>>> the nVidia chip. >>>> >>>> Is there any profiling information to see where the most time is spend >>>> and what is the critical path? I'm mostly interested in loops (even >>>> hand-unrolled ones) and discrete tasks that could potentially be >>>> offloaded to an OpenMP thread. >>>> >>>> I started looking into src/math/m_matrix.c for my first tests, but I >>>> need some more information such as: >>>> 1) which functions are called over and over again in real opengl >>>> applications (and here the actual low-level functions are the >>>> interesting ones, not the OpenGL API functions), >>>> 2) which parts can run in parallel (data dependencies etc), >>>> 3) if anyone else is interested in this attempt. >>>> >>>> I'm not in favor of pthreads since: 1) you need to have a runtime >>>> system >>>> that schedules the tasks and does the load balancing and as such you >>>> might lose scalability if you don't do the best possible, 2) it is >>>> error-prone and 3) you have to do all the fine-tuning by hand. On the >>>> other hand, OpenMP is quite easy to program even for beginners, most >>>> major compilers support it really well and it scales very well. >>>> However, >>>> being a data parallelization technique, it requires some additional >>>> effort to force it to execute some tasks. For a starting point I think >>>> it is a very decent solution. >>>> >>>> Thanks in advance, >>>> 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 >>>> >>>> >> >> > ------------------------------------------------------------------------- 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
