03:46 imirkin: skeggsb: "mmu debug buffers"?
03:49 skeggsb: i don't know what else they're used for, but the mmu redirects accesses to pages marked as "sparse" to them
03:50 skeggsb: nfi why it doesn't just drop writes on the floor, and return 0 without accessing any page at all.. but, it is what it is :P
03:53 imirkin: i guess i made assumptions about where those mmu_rd/mmu_wr things are used for
03:54 imirkin: anyways, that ... kinda makes sense
03:54 imirkin: what if you didn't want sparse reads to return 0's
03:54 skeggsb: haha, true :P
03:54 imirkin: i think i'm going to finally implement that nv17 mpeg thing
03:54 skeggsb: it's a bit weird, prior to gm20x, only gr uses those buffers.. so, non-gr mmu clients read 0xffffffff instead (but, the important part being, don't cause a page fault)
03:55 skeggsb: i *presume* gr would use the debug buffer
03:55 skeggsb: that was beyond the scope of my simple test application though
03:55 imirkin: i need to create a new "submit" ioctl, right? with a buffer of commands + list of associated buffers? something reloc-y maybe?
03:56 skeggsb: probably yes to all of the above... some kind of fencing too
03:56 imirkin:never understood how buffer relocs worked
03:56 imirkin: ah right. hopefully the mpeg engine can write a fence
03:56 skeggsb: relocs are just patches to buffer addresses etc in the command stream
03:56 imirkin: otherwise it could be a quiesce sort of thing waiting for the commands to process
03:57 imirkin: ah right, coz the buffer might get moved, since it won't have a permanent address
03:57 imirkin: [since this is all pre-mmu]
03:57 skeggsb: yep
03:57 imirkin: right-o
03:57 skeggsb: we don't use them at all on nv50 and newer, thankfully
03:58 imirkin: i'm sure i'll bother you with dumb questions again as i get into it
03:58 skeggsb: nv50 has its own annoying bits too, which is why we restrict buffers from only being used in the domains they're flagged with when they're created
03:59 imirkin: the pagesize thing right?
03:59 skeggsb: can't mix small and large pages within certain ranges, so, if a buffer gets moved to system memory, it's virtual address would have to change too if the buffer was large pages to begin with
03:59 imirkin: right
03:59 skeggsb: gf100 solves that by having dual page tables
04:00 skeggsb: which, leads me to my current bit of annoyance in dealing with sparse and keeping things consistent while not angering the mmu :P
04:00 imirkin: would be nice to get sparse buffers/textures support into mesa
04:00 imirkin: the AMD folk already have it
04:01 skeggsb: they're coming mostly as a side-effect, glisse needs support for pascal's new mmu layout, which means i need to finish/push the mmu shit i started forever ago
04:01 skeggsb: sparse and the 64k page issue, come for "free" with that
04:01 airlied: imirkin: they have sparse buffers, don't think anyone has done textures yet
04:01 imirkin: cool
04:01 imirkin: airlied: yeah, i know
04:01 imirkin: buffers are definitely easier
04:01 imirkin: not sure what the difficulty is with textures -- might be something amd-specific
04:02 imirkin: e.g. some engines don't support them or something
04:02 airlied: yeah the SDMA engine can't do sparse
04:02 imirkin: and SDMA is the format-conversion thingie?
04:03 skeggsb: i suspect that's what the mmu debug buffers on nv hw is for actually, nvidia said something about
04:03 airlied: it's the move stuff from system RAM to VRAM as fast as possible thing, not sure it does much format conversion
04:03 airlied: but it can tile/detile etc
04:04 imirkin: ah ok
04:04 skeggsb: ... naive clients being told the request succeeded, and i guess those access the debug pages, but smart clients do better
04:04 mwk: uhhh, do we know anything about vertex program textures on NV40?
04:05 skeggsb: mwk: *very* little beyond the methods used
04:05 mwk: and do we know the methods used?
04:05 skeggsb: i did once.. let me see if i stuck that into mesa or not
04:05 imirkin: hopefully in rnndb?
04:05 imirkin: i thought i remembered seeing them...
04:05 mwk: I just looked in rnndb
04:05 imirkin: VERT_TEX
04:05 imirkin: maybe in the other magical place?
04:06 imirkin: hrmph
04:06 skeggsb: mwk: they start from 0x900
04:06 skeggsb: "documented" in src/gallium/drivers/nouveau/nv30/nv30_winsys.h for some reason
04:07 imirkin: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv30/nv30_winsys.h#n8
04:07 mwk: oh, with accompanying bundle addresses as well, neat
04:08 mwk: BCOL?
04:08 skeggsb: border colour
04:08 imirkin: ah, beat me to it.
04:08 mwk: ah
04:08 mwk: alright, that's a start, thanks :)
04:09 imirkin: heh, replacing the register combiners in nv30.
05:45 mwk: eh, sure would be nice to keep all that crap in one place
05:46 mwk: mmm, a machine readable method list that we could generate docs, headers, hwtests, and who knows what else from
05:46 mwk: time for rnnndb, perhaps
05:46 mwk: this time including a programming language to *precisely* describe all these pesky methods
07:36 mupuf: mwk: I'm curious about how you will define this language
07:36 mupuf: and how you will convert the existing xmls to it :o
07:53 mwk: mupuf: better ask how to convert hwtest C++ into it, cause that's where most interesting information is at currently
07:54 mupuf: hmm, right. Tough work!
12:08 karolherbst: well strictly speaking, xml is machine readable
12:26 karolherbst: mwk: maybe some hw description language might make sense here? Or maybe some kind of query language we could embed into the XML, which can be used for generating test code?
12:27 mwk: ... if I end up with a verilog reimplementation of NV40, somebody will be a bit engry, right?
12:27 karolherbst: why?
12:27 imirkin: mwk: i'm guessing it'll be you that's angry :)
12:28 mwk: well as Bruce Banner said...
12:28 mupuf: ha ha
12:28 mupuf: yeah, we probably do not want something that detailed
12:28 mupuf: but rather the behaviour
12:28 karolherbst: "want"? why not
12:31 karolherbst: it isn't forbidden or anything like this, and I am sure this would be quite a good thing to have something which behaves exactly like existing GPUs
12:32 mwk: hmm I need to cross-ref unknown Curie methods with Tesla once I'm done
12:33 mwk: I think I've seen some of the weirder behaviors before
12:35 mwk: karolherbst: something like a query language is what I'm thinking
12:36 mwk: so that simple behaviors (set bits X-Y of bundle Z to the value of this incoming bitfield translated by this enum) can be described entirely, and hwtest auto-generated
12:36 karolherbst: mwk: maybe we could have something like a way to embed a script saying which registers are changing how or so
12:36 mwk: while complex behavior would just be dealt with via a C++ function call
12:37 karolherbst: mhhh
12:37 mwk: that will handle like 95% of 3D methods
12:37 karolherbst: why not being able to call c++ functions inside the query language?
12:37 mwk: why not indeed? it should be possible
12:37 karolherbst: well, don't have to be all
12:38 karolherbst: we should just have a class with utility functions we could call, like sqrt and much more complex things
12:38 mwk: anyway, the biggest reason why I'd like that stuff to be generated is that I could then instrument such things easily
12:38 karolherbst: yeah
12:38 karolherbst: maybe we could even run nouveau against it then
12:38 karolherbst: being able to put a library instead of the actual hw as a "backend"
12:39 mwk: right now >half of hwtest code for many methods involves just coming up with reasonable test data
12:39 karolherbst: uml with faked GPU, sounds like an awesome project to me
12:39 karolherbst: uhm
12:39 karolherbst: usermode linux
12:39 karolherbst: and then we could run fuzzer on top of that
12:40 mwk: it's a real pain to test method validation properly when you're 99% likely to generate invalid data
12:40 mwk: so any time a method has complex validation behavior I try to come up with sorta-reasonable looking values, then maybe flip random bits to make sure there are no other valid inputs
12:41 mwk: and such data generation can easily be longer than actual checks
12:41 mwk: and GL enum methods are the absolute fucking worst
12:41 mwk: like the blend equation thing
12:41 mwk: it's a method that will only pass if the 32-bit input value is 0x8006, 0x8007, 0x8008, 0x800a, 0x800b
12:42 mwk: ... but, on Kelvin, 0xf005 and 0xf006 are accepted as well
12:42 mwk: you won't get any indication that these are valid until you submit precisely the right 32-bit value
12:44 mupuf: mwk: ...
12:44 mwk: so... I'd want a tag that says "this is a GL enum", and then a hwtest could be auto-generated that checks everything in range 0-0xffff
12:44 mupuf: mwk: but you can't do that for a 32-bit value...
12:44 imirkin: mwk: how about a uint16 type
12:44 mwk: hell, I had no idea there could even be different blending equations until I was REing pre-launch checks and saw that translated values 5 and 6 seem to do shit
12:45 mwk: so I had to look for the corresponding input values
12:46 mwk: and I've run the blend equation test set to do an insnane number of repetitions, took an hour or so
12:46 mwk: and that's with a test that already knows about GL enums and biases to 16-bti values
12:46 mwk: mupuf: well, you can
12:47 mupuf: mwk: in how much time?
12:47 mwk: an exhaustive search of 32-bit value space is very possible
12:47 mwk: except you'd need to do it differently from a full hwtest run
12:47 mwk: a full state load/dump is right out
12:48 mupuf: yep, that part is for sure
12:48 mwk: but if you just set up an initial context, then submit all values in order, only stopping for a moment to check for invalid data interrupts... it's doable
12:49 mupuf: you mean it is doable for one value, but hwat about all the others?
12:49 mwk: uh?
12:49 mupuf: if it takes a year to validate everything
12:49 mupuf: it is not that useful, is it?
12:49 mupuf: I mean, when would you like to run these hwtests?
12:49 mwk: that's why I want many test "formats"
12:50 mwk: normally you'd just run randomized testing
12:50 mwk: but if you want to be extra-sure of input validation on a weird method, it'd sure be nice to have a "scan fucking everything" button
12:51 mupuf: hehe, something to leave the computer run on, while away from the computer for vacation
12:51 mwk: well
12:51 mwk: tbh I have no idea how long it takes to do a full hwtest run right now
12:52 mwk: except that it's rather long
12:52 mwk: a full 3d method check is an overnight business
12:52 mupuf: not so bad!
12:52 mupuf: almost as long as rebooting windows
12:53 mupuf:pressed reboot on his windows box ~15 minutes ago and it just did it. Finally back on a decent OS
12:54 mwk: but the default repetition count just doesn't cut it for many complex methods
12:54 mwk: I'll need a way to tag methods as more or less complex to vary the repetition count reasonably
12:55 mwk: all these lighting parameter methods that just stuff data into XF storage could get a very low repetition count
12:55 mwk: while something with a hellish validation like TEX_SHADER_OP would get *a lot* iterations
12:56 karolherbst: mupuf: do we want to do a proper CI thing for nouveau starting November? when I have, uhm, time for it?
12:56 mwk: I swear, this method is going to give me nightmares
12:56 mwk: that and TEX_FORMAT
12:57 mwk: mupuf: https://github.com/envytools/envytools/blob/master/hwtest/pgraph_class_kelvin.cc#L5022
12:58 mwk: this is data validation for TEX_SHADER_OP
12:58 mwk: part one of it, I mean, the second part is in pre-launch checks
12:59 mwk: here's a fun project, try to write a value generator that will exercise all codepaths here and also generate reasonably-looking deviating values that may happen to be special-cased that we don't know about
13:00 mwk: oh, and just in case you thought of just iterating through all of the 20-bit input space: note the dependence on the DEBUG_L register in there...
13:01 mwk: https://github.com/envytools/envytools/blob/master/hwtest/pgraph_class_kelvin.cc#L692
13:02 mwk: here's another good one, and it's only this short because I extracted the tex format table and stuffed it elsewhere
13:03 mupuf: karolherbst: I am still in the process to get a reasonable one for Intel
13:03 mupuf: but yeah, hopefully, by November, we can have all the bricks set up properly
13:03 karolherbst: well, November is still a bit away, and I could work on that mainly then, you only need to provide whatever you have done by then :p
13:04 karolherbst: and I would go with several testing rigs anyway, so that we don't depend on just one
13:04 mupuf: mwk: checking it out
13:04 karolherbst: no idea what I will be able to come up with hardware wise then
13:05 mupuf: karolherbst: the only thing I can say is that we will need a domain name (which I can provide), and use patchwork for pre-merge results
13:05 mupuf: after that, we need to talk about what we want to achieve
13:06 karolherbst: okay, does your domain provider has some kind of API we could use for stuff like certbot?
13:06 pmoreau: If you guys are in the process of configuring a CI for Nouveau, maybe that will motivate me to work on making my Nouveau testing machine available. -_-"
13:06 mupuf: mwk: wow, this is random
13:06 karolherbst: important if we want to hide stuff behind logins
13:07 mupuf: karolherbst: dude, I have my own private server and I already have certbot for it
13:07 karolherbst: ohh wait, you do this file based challange, right?
13:07 karolherbst: *challenge
13:07 mupuf: sure
13:08 karolherbst: can't do it with mine at home
13:08 mwk: mupuf: sure is, and took some time to come up with
13:08 mupuf: must be hell to write this...
13:09 mwk: I mean, I sort-of knwo what the values involved are
13:09 mwk: at least I narrowed it down to a few guesses
13:11 mwk: mupuf: yep, that is what hell looks like
13:11 mwk: though the pre-launch checks are the worst
13:11 mupuf: almost feels like it could be auto-generated :D
13:11 mwk: with method validation, the success at least depends only on the input value and maybe some debug reg bits if you're unlucky
13:12 mwk: but pre-launch checks check, well, *everything*, and give you a true/false response "everything is ok" or "you fucked up"
13:13 mwk: here's what it looks like for NV20, FWIW: https://github.com/envytools/envytools/blob/master/hwtest/pgraph_class_kelvin.cc#L212
13:13 mwk: I shudder to thing what it looks like on NV40...
13:15 mwk: but oh well
13:15 mwk: we're going to find out
13:16 mupuf: I am surprised you are already at nv20 though
13:17 mupuf: but I guess you did not model the entire pgraph, right?
13:17 mupuf: or was it easier because it was fixed functions?
13:20 mwk: mupuf: I am not modeling everything yet
13:21 mwk: only state setting methods, mostly
13:22 mwk: and btw, fixed function is not exactly easier
13:25 mwk: for t&l, which involves microcoded floating-point alu, the end result is that I have to RE the operations available *and* the program as well
13:25 mupuf: ....
13:26 mwk: the result is in nvhw/pgraph_celsius_xfrm.c
13:27 mwk: it is not for the faint of heart
13:28 mupuf: oh the heck did you figure this out? I hope it is close to all the RFCs for floats
13:29 mwk: it's ieee 754 not rfc
13:29 mupuf: right
13:29 mwk: and it's violated in *many* interesting ways
13:29 mupuf: did you get it to be bit-perfect?
13:29 mupuf: ha ha
13:29 mwk: yes
13:30 mwk: except for local/spot lights, which I'm still working on
13:31 mupuf: you are insane :D
13:32 mwk: yes...
13:34 mwk: anyhow
13:35 mwk: there will be two magical days
13:36 mwk: magical as in hell has overflown, frogs are raining, and dead walk the earth
13:36 mwk: one is when I get to RE the rasterizer; the other, textures
13:37 mupuf: right
13:37 mupuf: maybe you should stick to nv03 then ;)
13:38 mwk: oh and maybe zcull, though that's sorta part of rasterizer
13:39 mwk: mupuf: the entire reason I'm doing Nv40 now and not nv3 is that I've already tried and failed to re nv3 rasterizer
13:39 mupuf: so, you need to level up again in REing?
13:39 mwk: yes
13:41 mwk: and I think I may start with nv20
13:41 mwk: it's not likely to be easier than nv3
13:42 mwk: but nv20 has direct access to many internal pipes and memories
13:42 mwk: these tend to be *very* useful
13:44 mupuf: sounds like a valid reaosn, yes
15:59 mwk: eh
15:59 mwk: fuck that, I'll just start calling all texture methods TEX_CONFIG_A, TEX_CONFIG_B, TEX_CONFIG_C, and so on
16:00 mwk: seems they just started cramming random crap in there
16:00 mwk: alright, soooooo.... how about a poll
16:01 mwk: is python3 a reasonable build-time dependency for all of envytools? y/n
16:04 karolherbst_: y
16:04 karolherbst: mwk: why are you asking though?
16:05 karolherbst: please use env python3 shebangs then though
16:06 mwk: I'm about to start generating parts of hwtest, xml, and docs from a big table
16:06 mupuf: mwk: y for python3
16:07 mwk: if build-time dependencies is a problem, we can always stuff generated files in the repo
16:07 mwk: but that's kind of messy
16:07 karolherbst: can't see how python3 can be a problem
16:12 mupuf: yeah, don;t make it more complex than it needs to
16:32 imirkin_:hates python3
16:33 karolherbst: imirkin_: care to elaborate?
16:34 imirkin_: i like python
16:34 imirkin_: i hate how python3 was done and have avoided using it.
16:34 imirkin_: i esp hate how some people think that python == python3.
16:34 karolherbst: well okay, but any technical reasons?
16:35 imirkin_: none whatsoever.
16:35 karolherbst: okay, I understand this naming thing and that's why I also gave the comment about env python3 thing to be clear about that
17:00 whompy: I typically like arch, but they really screwed up the python 3 mess.
18:10 mupuf: imirkin_: python2 will soon be EOLed, so, better not use it for new stuff
18:16 imirkin_: mupuf: EOL meaning what? no new features? i'm happy with the current set..
18:16 mupuf: imirkin_: security fixes
18:16 karolherbst: the wanted to EOL it years ago already though
18:16 karolherbst: *they
18:16 imirkin_: "security"? like what?
18:16 karolherbst: commits at all
18:16 karolherbst: EOL means: nothing
18:16 imirkin_: fine by me.
18:17 karolherbst: not even bug fixes?
18:17 imirkin_: if anything comes up, someone will release a python-ng
18:17 karolherbst: I don't see any reason why to still use python2 either
18:17 imirkin_: because all my stuff is in python2
18:17 imirkin_: and python3 is weirdly different from python2
18:18 karolherbst: like in a more sane way different?
18:18 karolherbst: also there are converter scripts
18:18 imirkin_: like print requires parens
18:18 karolherbst: yeah
18:18 karolherbst: it makes sense
18:18 karolherbst: print behaves like a function, so it should be one as well
18:19 imirkin_: sure, that's one way to do it
18:19 imirkin_: just ... not the way it was done in python2
18:19 imirkin_: and there's no strong reason to change it other than pissing people off
18:19 karolherbst: yeah well, doesn't make it more sane
18:20 karolherbst: print doesn't behave like a key word
18:20 imirkin_: sure it does... it has all kinds of weird stuff
18:20 imirkin_: like print >>sys.stderr
18:20 imirkin_: and print foo, being different than print foo
18:20 imirkin_: etc
18:20 karolherbst: uhm, that "," thing is a string thing, isn't it?
18:20 imirkin_: no
18:20 imirkin_: "print foo," does not add a println
18:21 imirkin_: while "print foo" adds a println
18:21 imirkin_: er, a newline
18:21 karolherbst: weird
18:23 karolherbst: but this thing is easily ported and I am sure that the python converter scripts already handle most of it
18:23 imirkin_: i'm sure it is
18:23 imirkin_: aka different-for-the-sake-of-different
18:24 imirkin_: and to be clear, i'm a big fan of language improvements
18:24 imirkin_: i thought that "yield" being added in py2.4 was *awesome*
18:24 imirkin_: i also like the set comprehension thing
18:24 imirkin_: i just think that *changing* things is a giant ... annoyance.
18:28 karolherbst: well sometimes a change is to bring more consistency or to remove not so obvious things or things like that, but in the end it nails down to how important is cleaning up vs backwards compatibility
18:29 karolherbst: that integer division thing for example, this is a bigger deal breaker than that print thing
21:59 imirkin_: skeggsb: fyi, NV21 is for nv10+
21:59 imirkin_: the nv4/nv5 thing only returns YUYV/UYVY
22:01 mwk: what the fuck
22:01 mwk: how many texture formats does this thing have
22:01 mwk: if format 0xb8 is valid...
22:02 mwk: well, this is going to be a long night
22:02 imirkin_: mwk: which thing?
22:02 mwk: NV40
22:02 mwk: Curie class
22:02 imirkin_: mmm... it has a bunch
22:03 mwk: I believe it is more properly called a "fuckload"
22:03 imirkin_: shouldn't be THAT many...
22:03 mwk: rnndb only lists 0x26 values, and it's ridiculously incomplete
22:03 imirkin_: 5 bits of formats
22:03 mwk: Rankine is already known to have 0x4f, and it supports every single one of them
22:04 imirkin_: with extra bits for linear and rect
22:04 mwk: and Curie happily accepts formats has high as 0xb8
22:04 imirkin_: are we talking about the same thing?
22:04 mwk: nv10_tex_format in rnndb
22:04 imirkin_: i'm talking about method 0x1a04 & co
22:05 mwk: yes, exactly that
22:05 imirkin_: the second byte
22:05 mwk: sorry, but the format field is 8 bits wide
22:05 imirkin_: ok, but that 8-bit-wide field has bits inside it
22:05 skeggsb: didn't rankine also have separate RECT formats, and curie separates that out to a flag?
22:05 imirkin_: i.e. &0x20 == linear
22:05 imirkin_: &0x40 == rect
22:05 imirkin_: no clue what, if anything, &0x80 means
22:05 mwk: huh.
22:05 imirkin_: and &0x1f is the real format
22:06 mwk: in that case
22:06 imirkin_: which is filled from 1..0x1b
22:06 imirkin_: don't see defines for 1c..1f
22:06 imirkin_: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv30/nv30-40_3d.xml.h#n1691
22:06 mwk: either this thing fails to translate Rankine -> Curie formats
22:06 mwk: or... actually, there is no other possibility
22:07 imirkin_: rankine has explicit RECT formats
22:07 mwk: hmm
22:07 imirkin_: e.g.
22:07 imirkin_: #define NV30_3D_TEX_FORMAT_FORMAT_Z16 0x00002c00
22:07 imirkin_: #define NV30_3D_TEX_FORMAT_FORMAT_Z16_RECT 0x00002d00
22:07 mwk: unfortunate
22:07 imirkin_: (not for all formats, naturally)
22:07 mwk: the hw passes both Rankine 7-bit bigass enum and Curie 5-bit enum + 3 flags in the same register bitfield
22:08 mwk: I suppose the texture units know to interpret that differently based on the active class
22:08 mwk: or, they just screwed up the Rankine-or-Curie emulation, who knows
22:08 skeggsb: does nv4x support rankine too?
22:08 imirkin_: only NV40 supports that, right?
22:09 skeggsb:learns something new every day
22:09 mwk: skeggsb: only NV40, and only the NV35 class
22:09 imirkin_: iirc nv41+ dropped that shit
22:09 mwk: which it calls 0x3597
22:09 skeggsb: does it make up shaders for the fixed-function stuff, or?
22:09 mwk: yeah, it's completely gone on NV41
22:09 mwk: skeggsb: it actually supports this thing in hardware
22:09 skeggsb: wow
22:10 mwk: there's a whole bunch of regs that's gone on NV41
22:10 skeggsb: seems unnecessary :P
22:10 mwk: they deal with fixed-function transform&lighting, register combiners, etc.
22:10 mwk: well, "make up shaders"
22:10 mwk: depends
22:11 mwk: on the vertex side, I think NV20+ cards just have some sort of built-in microcode that gets executed instead of the vertex program if the VP is disabled
22:11 mwk: + the dedicated light coprocessor that is not accessible from VPs
22:12 mwk: but light coprocessor is half-gone on NV30 and completely gone on NV40
22:12 mwk: on the fragment side, I think the reg combiners are just an additional stage after the fragment shader
22:12 mwk: which is, presumably, nuked wholesale on NV41
22:13 mwk: except for the tex shader -> pixel shader translation, which must be implemented somehow to support Kelvin-on-NV30, but that's older stuff
22:14 mwk: skeggsb: FWIW, the VP const memory is actually larger on NV40 [0x220] than on NV41 [0x1d4], probably to support extra stuff for fixed-function
22:16 mwk: so anyway
22:17 mwk: NV30 & NV40 formats stuffed into the same hw bitfield raw
22:17 mwk: I sure hope they actually have different interpretations downstream depending on class
22:17 mwk: it would be a damn shame to have all this NV35 emulation hardware for nothing :p
22:18 imirkin_: well, you know, it *mostly* works... just no textures :p
22:18 imirkin_: does anyone use those anyways
22:22 imirkin_: skeggsb: unrelated - did you not get what you needed by looking at the GP108 mmiotrace in that bug?
22:22 imirkin_: or did you want to poke harder at it?
22:22 skeggsb: imirkin_: i actually forgot there was one, i'll go back and do a quick sweep over it
22:29 mwk: alright, so, 31 valid formats
22:29 mwk: not that bad
22:29 imirkin_: i don't think all are valid
22:29 imirkin_: there are some holes
22:29 mwk: hw accepts everything except 0
22:29 imirkin_: hm ok
22:29 imirkin_: at least for now
22:29 imirkin_: until you try to draw
22:29 imirkin_: and it tells you to go fuck yourself
22:29 mwk: nah, it cannot do that
22:29 imirkin_: [dunno if that happens, just a theory]
22:30 imirkin_: sounds like a challenge!
22:30 mwk: once you pass the checks, it either works, draws random shit, or locks up the pipeline
22:30 mwk: but no errors reported
22:30 imirkin_: INVALID_STATE or some bs?
22:30 mwk: that's a FE check, I'd know about it
22:30 imirkin_: heh ok
22:38 mwk: hmm
22:39 mwk: does it ever accept the tex format if you don't set bit 15?
22:41 imirkin_: if (eng3d->oclass >= NV40_3D_CLASS) {
22:41 imirkin_: ...
22:41 imirkin_: so->fmt |= 0x00008000;
22:41 imirkin_: so yeah, i guess that bit has to be set ;)
22:41 mwk: well then I have a hypothesis
22:41 imirkin_: that coudl be the bit that flips between the 2 modes?
22:41 mwk: this is the "I'm using a Curie format and not a Rankine format" bit
22:42 mwk: Rankine never accepts formats if they have bit 15 set, Curie never accepts them if it's unset
23:07 mwk: well yeah
23:08 mwk: formats 0x9, 0xa, 0xc, 0xd, 0xe, 0x16 are some weirdo kinda format that can only be linear, it refuses swizzling
23:08 mwk: and 0x11, 0x13 seem to be some unknown zeta formats
23:08 imirkin_: note that there are various restrictions about valid combos of things
23:09 mwk: 0xf, 0x17, 0x19, 0x1c-0x1f seem to be plain unknown formats
23:09 imirkin_: like... color + zeta have to have matching bitness
23:09 imirkin_: crazy restrictiosn with the float formats
23:09 mwk: imirkin_: that's for render target formats though
23:09 mwk: and yeah, I know
23:09 imirkin_: oh right, my bad :)
23:09 mwk: I already had a lot of fun figuring out the launch checks for NV20
23:10 mwk:can't wait to do that on NV40
23:10 mwk: and by "can't wait", I mean "fuck me with a spoon"
23:15 mwk: there are probably a lot of interesting restrictions on texture formats too
23:16 mwk: let's see
23:16 mwk: "no color key for DXT"
23:17 mwk: "no aniso for 3D tex"
23:17 mwk: + some ones involving unk bits
23:17 mwk: for Kelvin
23:20 rhyskidd: mwk: Have you seen the new warnings from nvhw/pgraph_celsius_xfrm.c -> https://hastebin.com/atonimotoz.pl
23:20 mwk: eh
23:21 rhyskidd: probably want: https://hastebin.com/fuhesebugo.pl
23:21 mwk: these shouldn't have made it to a commit either way...
23:26 mwk: rhyskidd: thanks for that
23:26 mwk: hard to keep track of which lines should be committed when you're working on like 3 things at once in a common repo :p
23:26 rhyskidd: no problem :) happy that it was easily picked up by the CI and fixed