* more thoughts and testing on how to implement the new binner:
   -> set batch size to 256 triangles, so triangle indices within a batch can be stored as uchars (-> coarse and fine rasterizer will have "unpack"/recompute the actual triangle id later on (one uint add), but this is negligible considering the amount of saved memory)
   -> each binner work-item handles one bin (this basically turns the previous and the Laine/Karras method on its head: instead of "one work-item = one triangle -> put into bins", it's "one work-item = one bin -> iterate over triangles")
      this is necessary, since OpenCL has absolutely no means of intra-work-group communication aside from atomics (which are unusably slow when accessing one single address for communication purposes across all work-items),
	  which is, by itself, necessary for maintaining the input order guarantee
   -> so: iterate over 256 triangles
   -> for valid triangles: store loop indices inside a private memory queue (256 bytes or 2 ulong16s; theoretically, I could also store this inside a bit mask, which would allow arbitrary batch sizes, but it would make "packing"/"unpacking" more complex/insane - maybe at a later point)
   -> make 2 vstore16(ulong16...) calls to the global memory batch queue buffer
   -> repeat / next batch
   -> also: could use async work-group copy to pull in all required triangle data (on the other hand, this might already be cached, since it's accessed sequentially by all work-item)
 * lowered bin size to 64*64px due to needing more bins (-> one work-item = one bin); might make this dynamic again at a later point