but does that force us to constantly send that raw pointer around?
Yes, and it also has to be aligned. The buffer must be carefully crafted with considerable attention to caching issues. I kid you not, but I have seen some wild stuff. I've worked on the Larabee platform, which is the next generation discrete graphics card from intel. It has a 512K buffer, which means that you will be able to simultaneously process 16 floats. When you combine this with the parallelism possibilities on the next Nahalem processor (8 cores, 16 threads), you will be able to achieve processing speeds thousands of times faster then non-hardware optimized code. Unfortunately, to take advantage of this, you will need to manage the memory yourself, which requires lots of old fashioned straight "C" style coding. On Tue, Mar 23, 2010 at 4:54 PM, David Bergman < David.Bergman@bergmangupta.com> wrote:
On Mar 23, 2010, at 7:40 PM, Tom Brinkman wrote:
To you. There are many graphics shops that make extensive use of c++ *and* boost.
Not true. Sure, we use C++ around the edges. The actual graphics code is all done in C. There are no popular C++ graphics libraries. Sorry. Its not possible, graphics libraries require hardware acceleartion.
I never understood this idea that some libraries were not possible to build in C++. And, specifically, what graphics hardware acceleration has to do with C++(-specific) constructs. Are there intrinsic inefficiencies of C++ constructs (beside one indirection by virtual functions where they are used)? Is it something else? Yes, most low-level API's require a pointer to a memory area in the end, but does that force us to constantly send that raw pointer around?
/David _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost