The hardware thread on the core that generated the texture instruction is, generally speaking, running a loop over multiple fibres (qquads). So when one fibre generates a texture request it's likely that the next fibre in the loop will generate a texture request within a very short time ... and so on for all the fibres in that hardware thread.
Once the hardware thread has issued all its texture requests and exhausted all "shader ALU instructions" that could run in the shadow of those requests, it has to relinquish control of the core to the other hardware threads, i.e. go to sleep.
When the texture unit reports that it's encountering misses, I guess the relevant core marks some kind of "waiting for slow texture results" status on the thread that generated the requests. This prevents the core returning the dozing thread to context until there are results it can use.
If the texture unit had texels already in cache and was able to return results to the originating thread without the originating thread having to go to sleep, I guess it raises a simple "texture results ready" flag.
Alternatively, I suppose, the originating thread could request that a simple watchdog with sleep intervals is setup, to poll the status of texturing. The core could then adjust its polling interval when told that page misses have occurred. Polling would run on the "control thread" that runs on each core, independent of the shader threads. This control thread is the same thread that generates qquads, performs interpolation, etc.
Jawed
