On Mon, Sep 21, 2009 at 5:38 AM, Nicolas Boulay <[email protected]> wrote: > How do you manage memory between the memory controller that handle > texture and the shader ? The key of the performance will be to fill > correctly this internal memories.
Like I say, if we cache thing intelligently and do sort-first, we'll manage to have _reasonable_ locality. We can cache textures separately from other surface reads. We must evaluate the wisdom of each of these things. Although, at some point, we just have to do it and get on with life. :) > An other way of doing it is to define "object" at the shader level. So > when a shader need a call, it will ask for the data [x,y] of the > texture n°N. The memory controller could find the real adresse of the > next x, and next y, for a prefetch. It makes sense to define objects at the source level, but at the machine level, an object is just a surface with an encoding. That means it has a starting address, a width, a height, and a total length. We can rely on the host driver to actually allocate space for things. > Such prefetch could be defined inside the shader load instruction > set. Beside that, i prefer preloading, to prefetching. Prefetch is > very architecture defined, if the prefetch distance is not the good > one, you will loose performance. Preload defined a true register for > it, so you will never loose performance. I'm interested in this, but we have to keep in mind that there are limits on what we can expect the programmer to want to do. And moreover, we have to assume that the compiler isn't very smart. Prefetching and/or preloading would be awesome, but other GPUs don't do it. They just throw thousands of threads at the problem, keeping things saturated in the aggregate. I don't really like that, although using a sort-first strategy will help with this significantly. > The key point is to define high level object to clearly said to the > hardware what we want, and use large register to transfer the data > (8x8 data sampling ?) instead of using caches. The memory controller > should know about 1D, 2D, 3D arrays, but we could also add some linked > list. This become complexe, but object oriented cpu have already > existed in the past ( http://en.wikipedia.org/wiki/Intel_iAPX_432 ). > We could imagine "get" and "set" methode of the object handle by the > memory controller using a kind of firmware. Decompression could be > handle that way also. You're right that we need _something_ like an object. It would be _nice_ to have a shader program that's compiled and set in stone that refers to surfaces by "handles", and something else can decide what those handles refer to. So... what is the complexity of an object descriptor? We need to keep this as simple as possible. Alternatively, if we're compiling from LLVM, we can just hack the LLVM code to refer to the right addresses. This just has to be done once before being loaded into the hardware. It might be more sensible to save on some hardware. I don't know if the hardware needs to know about 3D, but in order to do patching, it DOES need to understand 2D. Like I was saying before, to optimize for sort-first, we'd like the patch it's working on to fit into one memory row, so we can avoid row misses. This is an inherently 2D structure, and the surface organization will therefore be a nontrivial function of the patch size and the surface width/height. Of course, it EVERYTHING is organized this way, it's really not that bad. A surface would be defined by a starting address (which is a memory row), a width (in patch units), and a height (in patch units). Converting an arbitrary X/Y coordinate into a linear framebuffer address should be relatively simple. There's no point in doing 3D (voxels) since it would inherently occupy more than one memory row. -- Timothy Normand Miller 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)
