I read some tutorials on how to implement a raytracer in opengl 4.3 compute shaders, and it made me think about something that had been bugging me for a while. How exactly do GPUs handle the massive amount of random access reads necessary for implementing something like that? Does every stream processor get its own copy of the data? It seems that the system would become very congested with memory accesses, but that's just my own, probably incorrect intuition.
Related Questions in OPENGL
- Concatenate excel cell string within cell reference string
- Use hidden information for filtering data
- Using Vlookup in Excel sheet to match substring
- Import from api into multiple excel cells
- Loop through list of files and open them
- Pull and push data from and into sql databases using Excel VBA without pasting the data in Excel sheets
- Loop with equation for upper limit
- excel vba null value in array
- Why is my xml file having these after convert from excel?
- TextToColumns function uses wrong delimiter
Related Questions in GPU
- Concatenate excel cell string within cell reference string
- Use hidden information for filtering data
- Using Vlookup in Excel sheet to match substring
- Import from api into multiple excel cells
- Loop through list of files and open them
- Pull and push data from and into sql databases using Excel VBA without pasting the data in Excel sheets
- Loop with equation for upper limit
- excel vba null value in array
- Why is my xml file having these after convert from excel?
- TextToColumns function uses wrong delimiter
Related Questions in COMPUTE-SHADER
- Concatenate excel cell string within cell reference string
- Use hidden information for filtering data
- Using Vlookup in Excel sheet to match substring
- Import from api into multiple excel cells
- Loop through list of files and open them
- Pull and push data from and into sql databases using Excel VBA without pasting the data in Excel sheets
- Loop with equation for upper limit
- excel vba null value in array
- Why is my xml file having these after convert from excel?
- TextToColumns function uses wrong delimiter
Related Questions in RANDOM-ACCESS
- Concatenate excel cell string within cell reference string
- Use hidden information for filtering data
- Using Vlookup in Excel sheet to match substring
- Import from api into multiple excel cells
- Loop through list of files and open them
- Pull and push data from and into sql databases using Excel VBA without pasting the data in Excel sheets
- Loop with equation for upper limit
- excel vba null value in array
- Why is my xml file having these after convert from excel?
- TextToColumns function uses wrong delimiter
Popular Questions
- How do I undo the most recent local commits in Git?
- How can I remove a specific item from an array in JavaScript?
- How do I delete a Git branch locally and remotely?
- Find all files containing a specific text (string) on Linux?
- How do I revert a Git repository to a previous commit?
- How do I create an HTML button that acts like a link?
- How do I check out a remote Git branch?
- How do I force "git pull" to overwrite local files?
- How do I list all files of a directory?
- How to check whether a string contains a substring in JavaScript?
- How do I redirect to another webpage?
- How can I iterate over rows in a Pandas DataFrame?
- How do I convert a String to an int in Java?
- Does Python have a string 'contains' substring method?
- How do I check if a string contains a specific word?
Popular Tags
Trending Questions
- UIImageView Frame Doesn't Reflect Constraints
- Is it possible to use adb commands to click on a view by finding its ID?
- How to create a new web character symbol recognizable by html/javascript?
- Why isn't my CSS3 animation smooth in Google Chrome (but very smooth on other browsers)?
- Heap Gives Page Fault
- Connect ffmpeg to Visual Studio 2008
- Both Object- and ValueAnimator jumps when Duration is set above API LvL 24
- How to avoid default initialization of objects in std::vector?
- second argument of the command line arguments in a format other than char** argv or char* argv[]
- How to improve efficiency of algorithm which generates next lexicographic permutation?
- Navigating to the another actvity app getting crash in android
- How to read the particular message format in android and store in sqlite database?
- Resetting inventory status after order is cancelled
- Efficiently compute powers of X in SSE/AVX
- Insert into an external database using ajax and php : POST 500 (Internal Server Error)
The Stream Multiprocessors (SM) have caches, but they are relatively small and won't help with truly random access.
Instead, GPUs are trying to mask the memory access latency: that is each SM is assigned more threads to execute than it has cores. On every free clock cycle it schedules some of the threads that aren't blocked on memory access. When the data needed for a thread isn't in the SM cache, the thread stalls until that data arrives, letting other threads to be executed instead.
Note that this masking only works if the amount of computation exceeds the time spent on waiting for the data (e.g. per-pixel lighting calculations). If it's not the case (e.g. just summing lots of randomly scattered 32-bit floats), then you are likely to bottleneck at the memory bus bandwidth: most of the time your threads will be stalled waiting for their bits to arrive.
A related thing that can help with SM utilization is data-locality. When multiple threads access nearby memory locations then one cache-line fetch will bring the data needed by multiple threads. For example, when texturing a perspectively warped triangle, even though each fragment's texture coordinates can be arbitrary, nearby fragments are still likely to read nearby texels from the texture. Consequently there's a lot of common data shared between the threads, and one cache-line fetch would unblock multiple of them.
Ray-tracing, on the other hand, is horrible at data-locality. Secondary rays tend to diverge a lot, and hit different surfaces at practically random locations thru-out the entire scene. This makes it very hard to utilize the SM architecture for either ray-scene intersection or shading purposes.