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.
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. 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. 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. Regards, Nicolas 2009/9/21 Kenneth Ostby <[email protected]>: > Hi, > > Timothy Normand Miller: >>As with Larrabee, I suggest that we provide dedicated texture >>hardware. We could cache the compressed data and use one decompressor >>or a small number to service all texel requests. I expect that random >>access to the graphics memory will have much higher latency than >>pushing all requests through a small number of decompressors. > > I agree on this as well, having dedicated texture hardware allows us to > offload a lot of the decompression we would otherwise have to do from > the cores. What we should try to build into the texture hardware is > support for decompressing the textures, plus maybe support for a simple > prefetching scheme. Since our basic working set is texture, we can > assume that we are going to, more or less, request addresses in a linear > manner. Thus, it should be simple to include a basic prefetching > algorithm. > > > I will try to address some of the other points later today. > > > -- > Life on the earth might be expensive, but it > includes an annual free trip around the sun. > > Kenneth Østby > http://langly.org > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkq3QpEACgkQpcFZhY+Vljy2PQCfWEgCJB1Y7KahPHho6o82lvPm > Iu8AmwdOyelmr9b2Km2KmfNgpfb5FAe7 > =KpSS > -----END PGP SIGNATURE----- > > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
