It's interesting how the universities that are most well-known are not necessarily the ones that engineering companies want to hire from. We all know about Michigan State (East Lansing) and University of Michigan (Ann Arbor), but did you know that for engineering jobs, companies prefer to hire from Western Michigan (Kalamazoo)? We have a similar situation at Binghamton versus other public universities in New York State. For various reasons (including low tuition) the ratio of applications to admissions is very high, allowing us to get a very high proportion of really good undergrads. I haven't met a LOT of undergrads here, but those I've met have impressed me.
I have the opportunity to give independent study credit to get undergrads to work on coding projects, and I'd like to direct them towards OpenShader because of its dual role as an open source research project. What I need to do is figure out what are the best things to have them work on. It's important that the student learn something from this work that they can potentially find useful later and that their work directly impact research. Note that I've asked for someone with C++ experience, while having taken the Computer Architecture course is optional. Sooner rather than later, I'd like to have an agenda of bite-sized coding projects that will directly contribute to the simulator, and I'd like to get some suggestions. The first thing I thought of is a general event management system, similar to the one used in SESC or MSIM. Basically, you have a time-ordered queue, where you can insert function calls at future points in time, and when that time slot occurs, all of the functions for that time are called. To make this scalable to many cores, I think we should use some sort of work stealing algorithm, and we should use a low-overhead lockless technique (e.g. http://www.mcs.anl.gov/~dinan/pubs/2009/dinan_sc09.pdf). I still like the idea of being able to sleep and wake in the MIDDLE of code (rather than only being able to start at the beginning of a function), so we should consider adding a feature that can do long_jmp as well. What other basic building blocks could we work on that will make building the rest of the simulator relatively easy? On top of those, we need to build various logic blocks, like shader processors (which we basically have), shader multiprocessors, texture blocks, caches, memory access and arbitration, scheduling, etc. We also need to develop a compiler. We need to compare PTX to LLVM and see which we should use as an intermediate representation. PTX "belongs" to nVidia, so I don't know how far we can adopt it. But if we can at least _import_ PTX, that lets us make use of tons of existing tools that already compile CUDA code. BTW, I want to have a rule that this simulator needs to be built very portably. We've had a heck of a time getting Barra-sim to compile and run because of compatibility problems with compiler versions, BOOST versions, etc. If we're crazy enough to decide to require a library not our own, we should pull a default version into our own tree so that building and using it is transparent. I want to be superior to basically all of these other academic projects by avoiding ties to specific versions of OS and other tools. (I always had to build SESC statically linked on RHEL4 in order to get it to run on any other version of Linux.) (Also, when we pull in an external library, we need to carefully delineate it in docs, because we don't have as many rights to it as our own code.) -- Timothy Normand Miller, PhD Assistant Professor of Computer Science, Binghamton University http://www.cs.binghamton.edu/~millerti/<http://www.cse.ohio-state.edu/~millerti> Open Graphics Project
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
