Thank you for taking a look Jason! Sorry my bad, I'll make sure to add some comments to v2 at least. Hopefully it'll make editing this portion of the i965 drawing logic a bit easier.
On Fri, Sep 8, 2017 at 4:48 AM, Jason Ekstrand <[email protected]> wrote: > Hey Pam! > > A quick skim through this looks fairly good. I'll be honest, I expected > to have some quick comments on the v1 but I'm not seeing anything > immediately. That said, I've got to think about it fairly hard to convince > myself that it's actually correct. The i965 drawing logic isn't really my > area. > > On Thu, Aug 31, 2017 at 11:26 AM, Ilia Mirkin <[email protected]> > wrote: > >> On Thu, Aug 31, 2017 at 1:45 PM, Bas Nieuwenhuizen >> <[email protected]> wrote: >> > >> > >> > On Wed, Aug 30, 2017, at 14:59, Ilia Mirkin wrote: >> >> On Wed, Aug 30, 2017 at 3:17 AM, Bas Nieuwenhuizen >> >> <[email protected]> wrote: >> >> > So as a random drive-by review, I think the risk in this >> implementation >> >> > is that apps just set maxdrawcount to some high value . If I'm >> reading >> >> > the spec correctly there is no real bound on the value except for the >> >> > max-representable value for the integer. Also AFAIK the AMD and >> NVidia >> >> > implementation don't really get slower if you specify maxdrawcount >> very >> >> >> >> Can't speak for AMD, but this is actually extremely similar (in >> >> principle) to how this is handled on NVIDIA. It's a little cleaner >> >> since there's a nice macro, but since macros can't have a variable >> >> number of arguments, you have to feed it maxdrawcount args. Admittedly >> >> this is the nouveau impl, but I'm almost certain that the blob does it >> >> in a similar way. >> > >> > I thought, you had a macro that looped, but seems that was a >> > misunderstanding on my side. If nvidia does it that way, then I suppose >> > there is little risk of games expecting something more efficient. Never >> > mind my comments then. >> >> There indeed is a macro that loops. However that macro takes a number >> of parameters determined at the time of cmd stream generation. Also >> the indirect draw arguments have to be added into the cmd stream (via >> IB references). Here's how nouveau does it: >> >> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/driv >> ers/nouveau/nvc0/nvc0_vbo.c#n798 >> >> I don't remember if I looked precisely at what NVIDIA does, but I >> definitely can't think of another way. Even if you use the command >> which takes the argument length as a separate word, that won't be >> right since it's count * N arguments. macros can't read arbitrary >> things either, it has to come out of the cmdstream. >> > > I'll agree that this solution is suboptimal. However, it's really the > best we can do without getting crazy. A "real" implementation would > require a self-modifying command buffer which is a sketchy idea in the best > of circumstances. :/ > > _______________________________________________ > mesa-dev mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > >
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
