> *somewhere* the result of VS (or binning shader if VS is split in two) > needs to be saved for use during the per-tile rendering. Presumably > you have to give the hw a buffer of appropriate/matching size > somewhere, or with enough geometry (and too small a buffer) things > will overflow and go badly.
We allocate (in another part of a driver) the varying_mem buffer, which is where varyings, including gl_Position (i.e. all the output of the VS) get written to after VS and read from by the tiler. That's not this, but it's not clear what this... > I guess if you exceed the size given in .tiler_meta, then hw falls > back to running VS per tile for all geometry (not just geom visible in > the tile), hence big diff in perf for large tile counts and lotsa > geometry. This is possible, although I would expect that would show up in the performance counters as unusually high VS activity (which was not the case...? To be fair, I'm not convinced I'm reading the counters right ^^) _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
