[Libre-soc-bugs] [Bug 961] NLnet 2022 Libre-SOC "ongoing" milestone 2022-08-107 (approved, MoU TBD)
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Thu Aug 31 14:56:52 BST 2023
https://bugs.libre-soc.org/show_bug.cgi?id=961
--- Comment #21 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #19)
> (In reply to Jacob Lifshay from comment #18)
> might be a good idea to double-check given that there is no evidence
> that brd (etc.) have been completed,
there's a whole bug dedicated to brh/w/d with commit logs:
https://bugs.libre-soc.org/show_bug.cgi?id=1119
it is completed.
> and to give ghostmansd a full
> and explicit list https://bugs.libre-soc.org/show_bug.cgi?id=1147#c0
he has the full list now.
> > As mentioned on IRC, I don't think we should assign more budget to
> > Vectorised-Immediates since I think it should be lower priority than #1025
>
> it's part of the spec and it gets a "one-shot" opportunity to present
> EVERYTHING. therefore it cannot be "de-prioritised".
except that there are much higher priority things than Vector-Immediates,
because I know Vector-Immediates are a bad idea the way they are now, they
require massive invasive changes to the entire fetch decode pipeline, if you
thought 64-bit instructions PO1 make the fetch/decode pipeline a pain, you
haven't seen anything yet. I would never implement them. And no, they cannot be
treated as a branch instruction, because that *skips* reading all instruction
data between the branch and the target, where does your immediate data come
from now?!
Therefore, if you want them, I think they should be left for much later, if
they don't end up in the next version of the specification, no problem, just
wait for the version after that. That's exactly what will happen with Texture
loads and triangle rasterization instructions anyway, which are actually widely
used and known to be implementable, since every 3D GPU ever implements them (if
it doesn't, I wouldn't call it a 3D GPU).
>
>
> > therefore, I think we should take the leftover budget from bug #737
>
> there isn't any
>
> > and bug #1035
> > * bug #1146 gets EUR 1000
>
> **NO**. i have said this several times now.
> there is too much going on already.
but this allows us to test large sw on a fpga (what we've been trying to do for
many months and failing due to gram not working), i think this is higher
priority than many of the other tasks in this grant.
>
> adding additional tasks places completion in jeapordy as it reduces
> available budget for those tasks.
assigning the budget instead to #1025 would just be creating new different
tasks
such as implementing fp comparison.
In summary, I'm now proposing moving EUR 4000 from #1035 to #1025.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list