I think I've made things harder for my self than they need to be rather than creating a glsl_type object to hold all the array information for all dimensions I'm now thinking it would be simpler when processing the ast to hir to just create a new type object for each dimension which will then just be accessed recursively in the ir code. This way I possibly don't need to touch the ir code at all, everything should just work. I have been back and forth on which was the correct was to do this but I'm now pretty sure I need to go back and change the way I've currently implemented this part. However if everything works how I'm picturing it in my mind after changing this there isn't much more left to do for implementing the extension (I'm sure there probably is more to it though).
On Tue, 2014-01-14 at 22:53 +1100, Timothy Arceri wrote: > Hi all, > > Its still a work in progress currently just passing the compile tests > that I submitted to the piglit list [1]. > Its also a bit of a mess (some patches need squashing, a number of > patches are just temp updates to support single dimension arrays for the > time being) but I thought I would request feedback from anyone that's > interested so that I can find out if I'm at least heading in the right > direction at this early stage. > > Anyway if anyone's interested in taking a look my latest code is here: > https://github.com/tarceri/Mesa_arrays_of_arrays/tree/rebase6 > > Some issues I'm aware of (aside all the missing functionality) is the > key and name generation code in glsl_types.cpp is a bit flimsy its good > enough to pass the piglit tests but I'm sure it wouldn't take much to > break it. > > [1] > http://lists.freedesktop.org/archives/piglit/2014-January/008990.html > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev