| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
To quote the documentation:
First, within a single shader invocation, if you perform an incoherent memory write, the value written will always be visible for reading. But only through that particular variable and only within the shader invocation that issued
the write. You need not do anything special to make this happen.
This means there is nothing stopping us from just reading and writing in the buffer as if the values were local variables, as they are specific to a given invocation. Also, buffer access happens infrequently, and furthermore
there's nothing stopping the GPU from caching the values, as memory access is incoherent anyhow.
Long story short: Now the code uses only 28 VGPRs, meaning that the AMD GCN hardware ideal of 32 is again achieved.
|
| |
|
| |
|
|
|
|
|
|
| |
re-calculating it every dispatch.
By this I could get the VGPR usage down from 40 to 36.
|
|
|
|
| |
cardioid.
|
| |
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| | |
It seems forcing points outside the cardioid and bulb with a bad random
generator can take really long...
Also, now framerate adjusts based on time it takes to render frames.
|
| |
| |
| |
| | |
specifiers to buffers.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
completely store its state and working (nearly) fully independent of
each other.
|
|/ |
|
|
|
|
|
|
|
|
| |
least have 8 SSBOs), to allow three times larger images. Also make it possible to ignore maximum buffer size reported by the driver.
The maximum buffer size limitation is rather strict on radeonsi, so I decided to split the buffer in three, effectively increasing the maximum image size by a factor of three.
While doing so I realized that at least on radeonsi the reported maximum buffer size seems to be off. For this reason I added a new command line switch, that allows to ignore the maximum buffer size check.
For those curious: radeonsi reports a maximum buffer size of 128 MB, but I had no problems when using three buffers of 1098 MB each.
|
|
|
|
|
| |
hash of it, causing more drastic changes of the y=f(x,yDecoupler)
function with dispatch number.
|
|
|
|
| |
teh available randomness!
|
|
|
|
| |
everywhere.
|
| |
|
|
|
|
|
| |
Restrict starting value range to positive y-values, probably improving
random quality
|
| |
|
| |
|
|
|
|
| |
Also: Steal integer hash from stackexchange...
|
|
|