01:19 soreau: mareko: tarceri: This part seems suspicious to me https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/u_idalloc.c#L81-L85 can anyone explain what it's supposed to be doing there?
01:21 soreau: it seems like buf->data[n] is a 32bit field and it's trying to find a free 'slot' that is represented by a 0 in the field?
14:50 mareko: soreau: yes
14:52 soreau: mareko: so if it were something like efffffff, then it would end up with buf->data[i] |= 1ul << 80000000 ?
14:52 mareko: yes
14:52 mareko: << 31
14:52 soreau: that seems wrong if data is uint32_t *
14:53 mareko: ffs returns 1..32, so bit = 0..31
14:53 soreau: hm
14:54 soreau: mareko: well I'm not sure if you saw my comment on the issue regarding my hunch but it seems like there's an off-by-one or similar bug somewhere
15:01 soreau: mareko: I guess it's not supposed to be return i * 32 + bit + 1; ?
15:01 soreau: well, (bit + 1)
15:09 soreau: I don't think this is the problem but this code seems to be unreachable? https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/u_idalloc.c#L126
17:02 mareko: I don't think I understand that loop
17:20 soreau: it has for (i = base; i < num_elements && cond2 && cond3; i++) if (i == num_elements) ... it would seem like if i < num_elements, it wouldn't break and it would affect base before using it in ret:
17:20 soreau: sadly, i <= num_elements doesn't help :P
17:22 soreau: here max_ids is 0x400000 when I print it in util_idalloc_sparse_reserve() but I was thinking it would be like 32 or something :P