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
