<alyssa>
Just two commits touching common code there
<alyssa>
one is absolutely trivial (exporting a function, cherrypicked from jekstrand)
<alyssa>
the other adds some system values modeling transform feedback related state.
<alyssa>
If people prefer, I can vendor those
<alyssa>
although they are not currently vendored -- in principle load_xfb_address and load_num_vertices make sense for any driver/hardware and are needed to lower XFB for any driver/hw
<alyssa>
the actual XFB lowering pass is vendored in that series because I'm not sure how useful it will be to other drivers
<alyssa>
As-is, it's only useful for ES3.1 drivers, since it architecturally can't support geometry/tessellation
<alyssa>
(Lowering XFB with geom/tess may be possible depending how geom/tess are implemented, but that will be greatly hardware dependent.)
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
ppascher has quit [Ping timeout: 480 seconds]
wvanhauwaert has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
sdutt has quit []
sdutt has joined #dri-devel
<jekstrand>
alyssa: Threw you one more comment. I'll RB once that's resolved.
jagan_ has quit [Remote host closed the connection]
ybogdano has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
rgallaispou has left #dri-devel [#dri-devel]
Duke`` has joined #dri-devel
pnowack has joined #dri-devel
pnowack has quit []
yk has joined #dri-devel
<dcbaker>
austriancoder: yeah assign it to marge and let me know it's there so I don't force push over it :)
adjtm has joined #dri-devel
chinsaw has joined #dri-devel
mbrost has joined #dri-devel
chinsaw has quit []
nitish has joined #dri-devel
nitish has quit []
nitish has joined #dri-devel
nitish has quit []
Haaninjo has quit [Remote host closed the connection]
Haaninjo has joined #dri-devel
lumag_ has quit [Ping timeout: 480 seconds]
chinsaw has joined #dri-devel
<jekstrand>
robclark: With isaspec, how do I have a thing which can take on values 0-254 but 255 is special?
<jekstrand>
255 represents NULL in this case
<jekstrand>
Also, can isaspec be used for encoding or is it just for disassemblers?
<jekstrand>
I maybe should have asked that before starting. :)
chinsaw has quit [Ping timeout: 480 seconds]
<robclark>
jekstrand: starting with the easy question, yes it can be used for both asm and disasm, we use it for both in ir3
<robclark>
jekstrand: for 255, there are a couple ways, which one is appropriate mostly depends on how you want the disasm to look..
<robclark>
jekstrand: you can use <override> with different <display> template string, for example
<robclark>
and you can use something like <map name="FIELDNAME">my_fxn_which_does_special_things(src)</map> for encoding values into 0-254+255, if needed
bbrezillon has quit [Ping timeout: 480 seconds]
<jekstrand>
Ok, I think override is what I want
<jekstrand>
At least for now
<jekstrand>
I'm still getting the hang of all this
slattann has quit [Quit: Leaving.]
X512 has joined #dri-devel
<jekstrand>
robclark: What exactly are the semantics of <pattern>?
bbrezillon has joined #dri-devel
<jekstrand>
robclark: It looks like maybe it's used to detect different types of instructions or encodings?
mahkoh has joined #dri-devel
<robclark>
yup, pretty much.. it lets you say that certain bits must be zero or one (or dontcare) for the bitset to match to the bits
maxzor has joined #dri-devel
<robclark>
just in case you didn't notice it, there is src/compiler/isaspec/README.rst .. but if that leaves remaining questions it is probably a sign that it should be spiffed some more
<jekstrand>
Ok, I'll give that a read. :D
<jekstrand>
Is there a way to do it if I it's beter described by an enum? Or is it always a 0/1 pattern?
* jekstrand
should read the docs
<robclark>
pattern is always 1 / 0 / x (the latter we use for bits we haven't figured out or that the hw ignores)
<robclark>
I at least *attempted* to explain all the isaspec things in the readme.. How successful I was, I guess you'll tell me after you read it :-P
<mahkoh>
Hi. I've noticed the following weird behavior in mesa: When using a wayland-egl surface, wl_egl_window_resize has no effect until the next swap call. I'm observing the following weird behavior: Resize a window from 100px width to 200px width to 300px width. Call swap. This causes new 200px width buffers to be allocated in the wayland compositor (via zwp_linux_buffer_params_v1).
digetx has quit [Ping timeout: 480 seconds]
<mahkoh>
I've looked at the source code and I've noticed that update_buffers_if_needed has no effect if there is a back buffer even if the resize field is set to true.
<mahkoh>
(Not sure if this is actually the correct place to ask about mesa issues.)
<jekstrand>
This is fine for mesa issues
<jekstrand>
But be warned that it's after noon in the US on a Friday and most of the window-system folks are in Europe.
<jekstrand>
So they're done for the day. You may not get a response quickly.
<mahkoh>
Alright I might try again on monday.
<jekstrand>
robclark: I think I'm gonna need to support both 128 and 64-bit instructions. :-/
<jekstrand>
robclark: Not yet. Starting with 128-bit-only for now
<robclark>
I think that should be doable without too much more complexity.. or at least easier than completely arbitrary sized instructions
<robclark>
rough idea, for decode, try to match the larger instructions first, then the smaller ones, and be a bit more clever about ptr arithmetic for advancing to next instruction
<robclark>
and similar slightly more clever ptr math for encode
<jekstrand>
Yeah, that's what I was figuring.
<jekstrand>
I'll cross that bridge when I come to it. For now, gotta get the basics working.
<robclark>
you did, btw, remind me that I'd forgotten to submit a presentation proposal about isaspec for xdc..
<jekstrand>
Ooh! You should do that.
<robclark>
yeah, doing that now
X512 has quit [Quit: Vision[]: i've been blurred!]
<jekstrand>
robclark: Is there a way to import one bitset as type but have some bits re-arranged?
mbrost has quit [Read error: Connection reset by peer]
<jekstrand>
robclark: The ISA I'm looking at likes to put abs and neg in random places but I'd like them all to be part of a "src" thing.
digetx has joined #dri-devel
<robclark>
I've just defined different bitsets for those cases (like some instruction encodings have fewer abs/neg options for srcs).. but you could probably also parameterize it and use overrides I suppose (at least if all the permutations have the same size in bits)
flto has quit [Quit: Leaving]
<jekstrand>
Nah, it's where the register number is in one place and abs/neg are somewhere else entirely.
<jekstrand>
RIght now, I just have GRF1, ABS1, NEG1 as fields
<robclark>
ok, we have some of that, and use <param>
<jekstrand>
Right. Yeah, I'm starting to get the feel for thigns, I think.
<jekstrand>
*things
<jekstrand>
robclark: Any way to specify patterns in hex?
<robclark>
hmm, not currently, but wouldn't be opposed to adding something (if it can properly differentiate between the existing 1/0/x characters, ie. 0x1 would be a bit ambiguous
<jekstrand>
Right
<robclark>
mostly didn't do that because most of the patters I've cared about don't fit neatly into multiple of nibbles
<jekstrand>
Could go with the old Intel "h" prefix
<robclark>
yeah, that could work
<jekstrand>
I think my opcodes are 8-bit
<jekstrand>
Well, 12-bit where the top 4 are extra bits to specify encoding
<robclark>
that sounds rather boring compared to different groups of instructions having different sizes opcodes (if they have an "opcode" at all) ;-)
<jekstrand>
Well, I'm not convinced this ISA is actually boring
<robclark>
heheh
<jekstrand>
It seems to be a universe of special cases
<robclark>
ir3 was pretty straightforward back in a3xx days.. but they've gradually added things while mostly keeping things backwards compatible(ish), which has resulted in some odd corners
maxzor has quit []
chinsaw has joined #dri-devel
<jekstrand>
Ugh... The number of ways in which this encoding is messed up...
<jekstrand>
fadd with two register is special because... why? IDK.
<alyssa>
jekstrand: Ack
mahkoh has quit [Quit: WeeChat 3.5]
toolchains has joined #dri-devel
<anarsoul>
so if anyone's curious what was wrong with MSAA on lima yesterday - it missed MSAA resolve in transfer_map(). Now fixed with u_transfer_helper
chinsaw has quit [Quit: WeeChat 3.5]
<alyssa>
ah
<alyssa>
jekstrand: changed to use a system_value
jkrzyszt has quit [Ping timeout: 480 seconds]
flto has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
chinsaw has joined #dri-devel
chinsaw has quit []
chinsaw has joined #dri-devel
chinsaw has left #dri-devel [#dri-devel]
chinsaw has joined #dri-devel
mvlad has quit [Quit: Leaving]
<sravn>
jekstrand: xdc inputs: An overview of the compilers in mesa. I struggle to grasp the picture when you all talk about nir, tgsi, glsl and what drivers uses what
chinsaw has quit []
chinsaw has joined #dri-devel
<sravn>
jekstrand: something that shows how all the gallium drivers and state trackers fit together. So the big picture thing and mesa.
<sravn>
jekstrand: The above as more relevant response to your twitter enquiry for xdc topics (compared to my nirpipe joke on twitter)
chinsaw has quit []
valik has joined #dri-devel
toolchains has quit []
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
valik has quit []
<Kayden>
jekstrand: there's another crazy gpu out there with 128-bit instructions but sometimes 64-bit instructions?
<jekstrand>
sravn: I have thought about writing NIRpipe....
chinsaw has joined #dri-devel
<Kayden>
jekstrand: if not, there's a brw-isaspec branch in my tree that has some initial typing for 128-bit ones, but I was struggling to deal with the lack of uniformity in intel's ISA encoding
<Kayden>
i.e. from a field organization standpoint, it looks like someone chopped every field into 2, sometimes 3 pieces for good measure, put them on a frisbee, threw them across a field, where someone caught them, flipped it over, and packed them into a box however they could get crammed in, with some falling on the floor and just not making it, and hopefully that works for you
<Kayden>
source bits are here, here, and .................. there, but only sometimes, otherwise they're actually there
<Kayden>
for it to be useful as a disassembler, it seemed useful to put related things into a group that could be printed together, but then we ended up parameterizing everything
ahajda has joined #dri-devel
<jekstrand>
Kayden: Yeah... I think the param stuff can be used for that, maybe? I'm still trying to figure it out.
<Kayden>
there were a lot of ways to do everything and some of them worked better than others
<Kayden>
I think I was eventually convinced I could continue on my approach and get something working, but I ceased being convinced that it was going to be easier to write / extend with future changes / cleaner and was definitely harder to read
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
<Kayden>
which is not really a knock against the infrastructure - it's pretty fantastic for a lot of uses
<Kayden>
just, pretending to be organized when there is so little organization gets really messy :)
<Kayden>
I wasn't finding inheritance to be very useful either, as there wasn't a real tree of categories of things
<Kayden>
mix-ins might have worked as a concept
<Kayden>
(are you predicated? are you align1? align16? ok, then you get these bonus fields)
MajorBiscuit has joined #dri-devel
<zmike>
alright fess up
<zmike>
who broke glsl unit tests in ci
<zmike>
this is a judgment free space but I will be judging
<robclark>
Kayden: would mix-ins be static or dynamic (ie. depending on some other bit(s))? If static, I suppose maybe extending to allow multiple inheritance gets you that.. not a thing I've given a lot of thought to, but if there are things that make it easier to support more different hw, then I'm all for it
<HdkR>
zmike: Twas I. I had the knife in the backroom with CI.
<zmike>
no!
<zmike>
HdkR: how could you!
<HdkR>
And I would do it again if I had the chance!
<HdkR>
CI betrayed me first, it was the only appropriate response.
<alyssa>
Kayden: yeah... I have wondered how isaspec would work for any of the 4 ISAs I work on
<alyssa>
I guess with enough slicing and glueing it could work
lumag_ has joined #dri-devel
<alyssa>
But it's not obvious that's better than NIH'ing it multiple times in a row.
MajorBiscuit has quit [Quit: WeeChat 3.5]
<alyssa>
very unsure about AGX, which badly needs a new disassembler
<robclark>
I will say, generating the disassembler, however you do it, is pretty useful for r/e'd isas when it can make unexpected bits stand out.. there were some things that went unnoticed for a while on the ir3 side simply because the hand-rolled disassembler wasn't good enough to flag unknown bits in all possible combinations of encodings
<Kayden>
yeah, I could definitely see that :)
xantoz has joined #dri-devel
<alyssa>
robclark: yeah, for sure
<alyssa>
I am 100% sold on formal ISA definitions and generated disasm/asm/encoding
<alyssa>
Just unsure on whether isaspec's specific implementation of those ideas is appropriate
<alyssa>
for each ISA
<alyssa>
(That answer is likely different for each ISA... Bifrost was never going to share encoding stuff with anyone, it is far too nonsense. Valhall probably could have been isaspec in retrospect. Unsure on AGX.)
<robclark>
I heard enough about the img isa to be pretty sure isaspec isn't a good fit there.. OTOH if there are other ISAs that could use isaspec if we added some feature or another, then I"m all for that
<robclark>
(then again, I should get around one of these days to converting afuc over to isaspec and get rid of one more hand coded assembler/disassembler in src/freedreno ;-))
rpigott has quit [Read error: Connection reset by peer]