[PATCH libdrm] etnaviv: Use hash table to track BO indexes

[Wladimir J. van der Laan]

> Maybe you want to look at
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1190
> 
> I updated this patch against mesa master, apparently the libdrm-etnaviv
> bits were folded into mesa now.

Thanks!

> >>  	stream->pipe = pipe;
> >>  	stream->reset_notify = reset_notify;
> >>  	stream->reset_notify_priv = priv;
> >> +	stream->seqno = ++dev->stream_cnt;
> > 
> > Do we have to catch integer overflow here?
> > It's very unlikely for there to have been 2^32 streams, but if it happens it might be good to at least
> > warn.
> 
> I don't think so.
> 
> If you allocated (2^(machine word size))-1 streams, you would exhaust
> your memory long before that. And this can actually roll over, since if
> you were to allocate streams one after the other and then free them,
> their numbers would just increment without colliding.
> 
> I guess what could happen here would be something like, you allocate
> stream #0 , then allocate/free (2^(machine word size)) - 2 streams and
> then allocating the (2^(machine word size)) - 1th stream would end up
> allocating new stream with the same stream count (?).

This is the scenario that I was imagining, in which two separate streams could
collide with the same seq no (resulting in weird glitches in bo tracking), but yes, it
seems very unlikely.

Kind regards,
Wladimir