I pinned this question to my email b/c I'm going to be doing something similar soon and why not help a similar soul out, but really even though I can't give you a straight answer now, the answer is still pretty straight forward.
There's nothing predominantly interesting between a gpu shader and a cpu bound method generating an image. That's it. If you're seeing something other than expected, it's simply due to error. Part of this may play a part in actually understanding what a vertex and fragment shader is doing down to each individual expression as it relates to a pixel... well, actually... that's probably all of it. I only very briefly glanced at your code and the glsl code you referenced much earlier in the day and nothing at the time jumped out at me, but I'm certain scrutiny would turn something up. It's important to understand how a fragment shader works in relation to the pixels on screen, how any derivative functions in use work in relation, and so on. The only resource that's prohibitive in this case is time. Most things are going to take longer to do on cpu, but there's nothing special about the gpu or shader code here except that it runs in parallel very very fast. So while "give more scrutiny" is all I have to offer atm, if you're having some question of a gpu shader having access to some impossible data inaccessible to the cpu, then I can only hope to completely throw that out of thought so you may feel more comfortable giving scrutiny to your code vs the shader code. That's where the problem is and that's where the problem will be identified and fixed. On Mon, Jun 20, 2016 at 10:03 AM <bluebl...@gmail.com> wrote: > > <https://lh3.googleusercontent.com/-bPOQJTHF8Js/V2gEJqUg5jI/AAAAAAAAACI/lg6cWG0cJqo0tFl4wsuDYF2w4kycTbRPACLcB/s1600/blank.png> > > I am attempting to generate a random starfield, in go. This is something > that will need to printed on actual paper, but that is another issue and I > only mention it to give some context for what I am doing here: Using go to > create graphics to pair with something I'm already doing in go (I've been > through several iterations of trying to use the go parts I have with > numerous variations of tex/latex templates using asymptote, and I reached a > point of frustration where I figured why not just do it all in go, as it > seems less a problem than I originally thought -- but opens a new set of > problems to solve, one of the biggest is that I know nothing at all about > graphics, let alone how to apply graphics in go). > > Cosmic1 from: > https://gist.github.com/thrisp/1ed1785ac6a902585595fb8cb52f0a16, > generates the above it is the first thing that even roughly approximates > what I want to do. > > Any thoughts, or help cleaning that up. Maybe tell me why exactly I can't > directly translate an opengl shader to something cpu bound(which I suspect > is a thing, I may need to do more that I can't see right now). > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
