On Thu, Jun 25, 2015 at 1:19 AM, Timothy Arceri <t_arc...@yahoo.com.au> wrote: > On Wed, 2015-06-24 at 11:17 -0700, Jason Ekstrand wrote: >> On Sat, Jun 20, 2015 at 5:32 AM, Timothy Arceri < >> t_arc...@yahoo.com.au> wrote: >> > Hi all, >> > >> > The restrictions in ES make the extension easier to implement so >> > I thought I'd try get this stuff reviewed an committed before >> > finishing >> > up the full extension. >> > The bits that I'm still working on for the desktop version are AoA >> > inputs >> > outputs, and interface blocks. >> > >> > The only thing I know is definatly missing in this series for ES is >> > support for indirect indexing of samplers, but that didn't seem >> > like >> > something that should hold up the series. >> > >> > Once the SSBO series lands (with a patch that restricts unsized >> > arrays) >> > then all the AoA ES conformance tests will pass. >> > >> > There are already a bunch of piglit tests in git but I've just sent >> > a >> > series with all the patches still waiting review here: >> > http://lists.freedesktop.org/archives/piglit/2015-June/016312.html >> > >> > I haven't made a patch marking this as done yet because currently >> > the i965 backend takes a very long time trying to optimise some of >> > the >> > conformance tests. They still pass but they are taking 15-minutes+ >> > just >> > to compile so this really needs to be sorted out first. If someone >> > with >> > more knowledge in this area than me wants to take a look at this I >> > would >> > be greatful for being pointed in the right direction. >> >> Can you try it with this patch: >> >> http://lists.freedesktop.org/archives/mesa-dev/2015-June/086011.html > > Hi Jason, > > I tried that patch it didn't seem to make any difference, then I > noticed its for fs. The slowdown is currently happening in > vec4_live_variables. I've also noticed other large slowdowns with some > piglit tests I've been working on this time in the register allocate > code.
I just sent an equivalent patch for vec4: http://patchwork.freedesktop.org/patch/52801/ I would love to know if it helps something so that I can put a good justification in the commit message beyond "the same as for FS". --Jason > Once I finish fixing up some bugs with my current patchset I'll start > digging deeper, just thought since it's so noticeably slow it might be > easy for someone with good knowledge of the backend to point out where > I should start looking, or to say your doing this wrong. > > One thing the slow shaders have in common is the use of arrays of > arrays in nested loops so maybe something funny is going on when they > go through the optimisation paths, I haven't spent much time looking at > any of these passes yet so its highly likely they don't work as > expected for arrays of arrays. > > Thanks anyway, > Tim > > >> >> > If useful the series is in the 'gles4' branch of the repo here: >> > https://github.com/tarceri/Mesa_arrays_of_arrays.git >> > >> > Thanks, >> > Tim >> > _______________________________________________ >> > mesa-dev mailing list >> > mesa-dev@lists.freedesktop.org >> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
