13:32 snail: hi, i have a geforce 7200 gs (nv46, g72), and i have some trouble with it. i'm investigating if it's a driver issue or hardware damage (or both?)
13:32 snail: one problem i have is a lot of mesa demos render incorrectly. for example gears, gearbox, geartrain, engine in display list mode. morph3d even crashes after some time (a few seconds). they have in common that the shapes become spiky and look "inverted"
13:32 snail: other programs also have distortions, like texture corruption in xonotic, texture warping in minecraft, and epilepsy-warning webgl in firefox
13:33 karolherbst: snail: is it an AGP card?
13:33 snail: it's a pcie card
13:33 karolherbst: mhh, strange
13:34 karolherbst: what desktop are you using?
13:34 snail: i'm using i3wm on nixos unstable
13:34 karolherbst: the GL driver for those old GPUs was never really that great, but normally basic things should work more or less...
13:35 karolherbst: mhh
16:01 imirkin: snail: probably GL driver issue
16:01 imirkin: however things used to work just fine for simple things
16:01 imirkin: texture warping in minecraft is something that's been reported
16:01 imirkin: i might recommend trying an older mesa version
16:01 imirkin: to see if these are (semi-)recent breakages
16:01 karolherbst: imirkin: thing is.. I tried glxgears and it worked for me :/ but I bet something really odd is up
16:02 imirkin: karolherbst: on which gpu?
16:02 karolherbst: nv43
16:02 imirkin: nv44 is slightly different
16:02 karolherbst: yeah, but that's nv46
16:02 imirkin: nv43 uses the nv40 curie class, there's a nv44 curie class too
16:02 karolherbst: ohhhh
16:02 imirkin: i forget which one nv46 has
16:02 karolherbst: okay...
16:02 imirkin: i assume the nv44 one though
16:02 karolherbst: mhh
16:02 karolherbst: maybe I have another nv4x GPU...
16:03 karolherbst: quadro FX 3450 ehh nv41
16:04 imirkin: i have that one ... nv43 iirc
16:06 karolherbst: I should make a list ...
16:07 imirkin: nv44 are super-common
16:07 imirkin: they were like the cheap-o geforce 6200's
16:07 karolherbst: doesn't help if I don't have one :D
16:07 imirkin: which cleverly advertised GART as VRAM :)
16:07 imirkin: so it looked like a bigger number
16:07 karolherbst: GeForce 7600 GT mhh
16:07 karolherbst: G73
16:07 imirkin: that'll use the nv44 class
16:08 imirkin: probably
16:08 karolherbst: wow.. that one is loud
16:08 imirkin: you can look in the driver
16:08 karolherbst: yeah.. still booting
16:09 karolherbst: yeah well...
16:09 karolherbst: seems broken
16:09 karolherbst: imirkin: the 7600 doesn't show up as a pcie device :(
16:10 imirkin: lol
16:10 imirkin: pretty sure that's not a nouveau problem
16:11 imirkin: does it have an extra power connector?
16:12 karolherbst: ehh.. maybe?
16:12 karolherbst: ohh wait
16:12 karolherbst: I think it works in a different slot
16:12 karolherbst: the fan got slower
16:13 imirkin: oh yeah, i've seen that
16:13 karolherbst: it spins down :)
16:13 imirkin: the fans on esp the quadro's a pretty intense
16:13 karolherbst: nouveau 0000:02:00.0: NVIDIA G73 (04b100a2) \o/
16:13 imirkin: coz they're the samller fans
16:13 imirkin: so they spin extra fast to make up for it
16:13 karolherbst: so.. not sure if cleaning of the dust helped or using a different slot
16:13 imirkin: we'll never know
16:14 karolherbst: oh wow...
16:14 karolherbst: it made strange noises
16:14 imirkin: like the ghost of christmas past?
16:15 karolherbst: mhh, now it works in a different slot as well as it seems
16:15 karolherbst: nah.. more like cracking
16:15 karolherbst: but could be the fan
16:16 karolherbst: okay.. let's see how that goes
16:17 karolherbst: DCI active :)
16:17 karolherbst: imirkin: I don't know why.. but even those old GPUs give me something to display in UEFI mode...
16:18 karolherbst: imirkin: OpenGL renderer string: NV4B
16:18 imirkin: that's expected
16:18 imirkin: (also see the code from above)
16:19 imirkin: "NVIDIA G73 (04b100a2)" -- that 4b isn't just there for decoration :)
16:19 karolherbst: ahh
16:19 karolherbst: so it would use the nv44 class, or not?
16:19 imirkin: not sure
16:20 imirkin: would have to rtfs
16:20 imirkin: #define CURIE_4097_CHIPSET 0x00000baf
16:20 imirkin: #define CURIE_4497_CHIPSET 0x00005450
16:21 imirkin: gets matched against 1 << (chipset & 0xf)
16:21 imirkin: so that's the 0x800 bit
16:21 imirkin: which is on 4097 =/
16:22 karolherbst: yeah... I check with gdb just to be super sure.. but yeah
16:22 karolherbst: it didn't show any artifacts
16:22 imirkin: nv4a would be 4497 ;)
16:22 imirkin: as would nv4d?? but there's no such chip... weird.
16:22 imirkin: oh no. nv4c.
16:22 imirkin: yeah
16:22 imirkin: nv4a and nv4c are 4497
16:22 imirkin: nv4b is 4097
16:22 imirkin: either add or subtract one to the chip id ;)
16:23 karolherbst: p/x oclass: 0x4097 :(
16:26 karolherbst: soo.. no luck I guess :(
16:27 karolherbst: imirkin: I'll ask my manager on tuesday... then I can ask if I can just buy one from RHs money :D
16:27 imirkin: and if not, may be ok to splurge yourself, i suspect you can swallow the 10E expense?
16:28 karolherbst: I guess
16:28 karolherbst: :D
16:28 karolherbst: I have no idea how much those cost
16:28 imirkin: they cost more in shipping than they do in GPU :)
16:28 karolherbst: I suppose
16:29 imirkin: e.g. https://www.ebay.com/itm/203529490315?hash=item2f634d8f8b:g:3t0AAOSwoBtg9MHN
16:29 imirkin: (obviously don't get this one...)
16:29 imirkin: Turbo Cache!
16:29 imirkin: (aka GART)
16:29 karolherbst: ahh
16:30 karolherbst: wasn't that a mixed one or so?
16:30 imirkin: hm?
16:30 karolherbst: apparently they have a small VRAM chip on board
16:31 karolherbst: but I find mixed information
16:32 imirkin: yeah, they do
16:32 imirkin: can't do scanout from GART :)
16:32 imirkin: so gotta have some vram
16:32 karolherbst: ahh
16:32 karolherbst: so I guess we just treat them without any VRAM from userspace more or less
16:33 imirkin: depending on your preference, you can also get a PCI variant of a NV4A board (which is NV44A - "AGP", but pci in this case)
16:33 karolherbst: ehh.. right.. I don't have AGP or PCI
16:33 imirkin: nah - they have a legit amount of vram
16:33 imirkin: like 64mb
16:33 karolherbst: only PCIe :)
16:33 imirkin: but just not what you might expect from the advertising
16:33 imirkin: ah ok
16:33 imirkin: there are some pcie nv3x's and even nv17's
16:34 karolherbst: mhh maybe mupuf could ship some GPUs over to me
16:46 glennk: imirkin, if i remember correctly all the pcie nv3x boards had a agp<->pcie bridge chip on them
16:46 imirkin: yep
16:47 glennk: and then the agp nv4x cards had the same bridge flipped upside down
16:47 imirkin: some yea
16:47 imirkin: but there was a nv44a which was "native agp"
16:56 karolherbst: imirkin: mhh.. looking at the code there are two differences between the 40 and 44 class
16:56 imirkin: index buffer iirc
16:56 imirkin: maybe something else dumb
16:56 karolherbst: that's one
16:57 karolherbst: the second one is in draw_elements
16:57 karolherbst: if (eng3d->oclass == NV40_3D_CLASS && index_size > 1 && !info->has_user_indices) { huge block }
16:57 karolherbst: but there is an else...
16:57 imirkin: that's ... index buffers
16:57 karolherbst: still...
16:57 karolherbst: ahh
16:57 karolherbst: true
16:57 imirkin: has to get the indices *somehow*
16:58 imirkin: the deal is that nv40 *had* them, and nv44 *didn't*
16:58 imirkin: (index buffer from vram or whatever)
16:58 imirkin: which is weird but wtvr
16:58 karolherbst: yeah.. besides that the code looks the same
16:59 karolherbst: maybe something in regards to screen->base.vidmem_bindings and screen->base.sysmem_bindings changed
16:59 imirkin: karolherbst: try forcing it
16:59 imirkin: i.e. make that condition always false
16:59 imirkin: should work on nv40 class
16:59 karolherbst: you mean try it out on my nv4x boars and see if that breaks
16:59 imirkin: just won't be as efficient
16:59 karolherbst: mhhh
16:59 karolherbst: okay
16:59 karolherbst: worth a try
17:00 glennk: video boars borking about
17:04 imirkin: yes, delicious video boars
17:04 imirkin: quite yummy
17:04 imirkin: along with some fava beans and a nice chianti...
17:07 karolherbst: imirkin: yep.. looks broken to me
17:07 imirkin: woohoo
17:07 glennk: didn't nv4x also have pretty limited vertex shaders, no branching if i remember correctly
17:08 imirkin: glennk: DX9
17:08 imirkin: i forget the precise capabilities
17:08 imirkin: nv4x has more than nv3x ;)
17:08 karolherbst: now which bug was it :D
17:10 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5061
17:10 glennk: imirkin, i think it was basically the same as nv3x, but added a texture sampling with no filtering instruction
17:11 karolherbst: okay... now how to bisect that thing
17:11 karolherbst: ohh 20.3.5 was fine..
17:11 karolherbst: then that's easy
17:12 karolherbst: Rebasing (3425/11986) :3
17:21 karolherbst: nice
17:21 karolherbst: 20.3.5 works :)
17:21 karolherbst: okay
17:21 karolherbst: let's go
17:21 karolherbst: (with my patch to force the path I mean)
17:27 karolherbst: ehhh
17:28 karolherbst: hitting a different bug while bisecting where the entire window stays black :(
17:28 karolherbst: hope that doesn't interfer
17:30 karolherbst: imirkin: it feels like unitialized memory
17:41 karolherbst: imirkin: https://gitlab.freedesktop.org/mesa/mesa/-/commit/dc995adec5ef36dbda43d9dd7f698ff8d6a70f2c
17:41 imirkin: oh fk
17:41 imirkin: more fallout from the min index thing?
17:41 imirkin: grrr
17:41 karolherbst: it seems
17:41 imirkin: let me look at the code
17:41 imirkin: see if i can spot the obviously-missing bit
17:41 imirkin: hold on
17:42 imirkin: let's see if i can ever remember the issue
17:42 imirkin: gimme a few
17:43 imirkin: did you bisect it to that precise commit?
17:43 karolherbst: yes
17:43 karolherbst: "# first bad commit: [b8ede10e2515ab71976e828561c00bf78339c1b6] vbo/dlist: create an index buffer in compile_vertex_list" the hash is different because I rebased on my patch forcing the path
17:44 imirkin: ok sec
17:44 karolherbst: it smells like uninit memory to me though
17:44 karolherbst: as the rendering is always different
17:44 karolherbst: and differs more between commits than between runs
17:44 imirkin: no, this is starting to use indexed rendering where there previously was not
17:45 karolherbst: ahh
17:45 imirkin: so i'm looking to see what's dodgy
17:45 imirkin: ugh, this is all so radeon-focused
17:46 karolherbst: so more like it's just triggering a bug we already had or something?
17:46 imirkin: mmmaybe
17:46 imirkin: yea
17:46 imirkin: let me see where this commit is
17:46 imirkin: could you print out the value of index_bias?
17:46 imirkin: at the top of nv30_draw_elements
17:46 karolherbst: on main or on top of that commit?
17:47 imirkin: doesn't matter
17:47 karolherbst: ehh where is index_bias?
17:47 karolherbst: ehh wait
17:47 karolherbst: wrong file
17:48 imirkin: nv30_vbo
17:49 karolherbst: 0
17:49 imirkin: ok
17:49 imirkin: not some random value? ok
17:49 imirkin: that might be a concern for another day
17:49 imirkin: although i guess it's well-guarded in draw elements
17:49 imirkin: so it should be fine
17:50 imirkin: what about the value of info->index_bounds_valid ?
17:50 karolherbst: seems to be true
17:51 karolherbst: so the only values containing garbe seems to be min_index and max_index, but we don't use them I think
17:52 imirkin: wait what
17:52 imirkin: index_bounds_valid means ... min/max index are valid
17:52 karolherbst: heh..
17:52 imirkin: what are the literal values of min/max index?
17:52 karolherbst: they change
17:52 karolherbst: min_index = 0, max_index = 161
17:52 karolherbst: min_index = 162, max_index = 325
17:53 imirkin: that sounds pretty reasonable.
17:53 karolherbst: min_index = 325, max_index = 366
17:53 imirkin: yea
17:53 karolherbst: min_index = 734, max_index = 815
17:53 imirkin: all sounds right
17:53 karolherbst: okay
17:53 imirkin: not garbage.
17:53 karolherbst: okay..
17:53 imirkin: i mean ... maybe not RIGHT, but not wrong either :)
17:53 imirkin: ooh, maybe we don't deal with it?
17:54 karolherbst: it seems we don't
17:54 imirkin: what is the value of "start" in nv30_draw_elements?
17:54 karolherbst: 0
17:54 imirkin: oh right.
17:54 imirkin: duh.
17:54 imirkin: can you look at the logic here:
17:54 imirkin: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv30/nv30_vbo.c#n513
17:55 imirkin: let it set the data pointer
17:55 imirkin: and then look at what's in data
17:55 imirkin: (it'll be uint16's or 32's depending on info->index_size
17:55 karolherbst: has_user_indices is false :)
17:55 imirkin: yea
17:55 imirkin: that's expected
17:55 imirkin: coz they upload the user indices to the gpu
17:55 imirkin: so that we can fetch them right back
17:55 karolherbst: so data is garbage, no?
17:55 imirkin: good use of effort.
17:55 imirkin: why?
17:56 imirkin: it maps a gpu resource
17:56 karolherbst: ohh
17:56 karolherbst: we assign
17:56 karolherbst: duh, missed that
17:56 imirkin: what's info->indeX_size?
17:56 karolherbst: 4
17:56 imirkin: or just index_size rather
17:56 imirkin: and is shorten true or not?
17:56 imirkin: i bet it's true
17:56 karolherbst: true
17:57 imirkin: wait what
17:57 imirkin: oh heh
17:57 imirkin: i guess that works
17:57 karolherbst: p/x (uint32_t[32])data
17:57 karolherbst: $26 = {0x5560b480, 0x5555, 0x5559f6d0, 0x5555, 0x5559efa0, 0x5555, 0x0, 0x0, 0xffffe170, 0x7fff, 0xffffd5b0, 0x7fff, 0xf71a2fa7, 0x7fff, 0x1, 0x0, 0x0, 0x0, 0x4, 0x0, 0xf71a2c76, 0x7fff, 0x1, 0x0, 0x5556d2a0, 0x1, 0xffffd5c0, 0x7fff, 0x0, 0x0, 0xffffd760, 0x7fff}
17:57 imirkin: uhhhhhm
17:58 imirkin: now THAT is gargbage.
17:58 karolherbst: ehh
17:58 imirkin: what's min_index?
17:58 karolherbst: wait
17:58 karolherbst: I forgot an *
17:58 karolherbst: p/x *(uint32_t[32]*)data
17:58 karolherbst: $29 = {0x2de, 0x2df, 0x2e0, 0x2e1, 0x2e2, 0x2e3, 0x2e4, 0x2e5, 0x2e6, 0x2e7, 0x2e8, 0x2e9, 0x2ea, 0x2eb, 0x2ec, 0x2ed, 0x2ee, 0x2ef, 0x2f0, 0x2f1, 0x2f2, 0x2f3, 0x2f4, 0x2f5, 0x2f6, 0x2f7, 0x2f8, 0x2f9, 0x2fa, 0x2fb, 0x2fc, 0x2fd}
17:58 karolherbst: so what should I dump exactly?
17:58 imirkin: and min_index is like 734?
17:58 karolherbst: yes
17:59 imirkin: and what's count?
17:59 karolherbst: 42
17:59 imirkin: can you print the whole thing?
17:59 imirkin: i.e. t[42]
17:59 karolherbst: p/x *(uint32_t[42]*)data
17:59 karolherbst: $32 = {0x2de, 0x2df, 0x2e0, 0x2e1, 0x2e2, 0x2e3, 0x2e4, 0x2e5, 0x2e6, 0x2e7, 0x2e8, 0x2e9, 0x2ea, 0x2eb, 0x2ec, 0x2ed, 0x2ee, 0x2ef, 0x2f0, 0x2f1, 0x2f2, 0x2f3, 0x2f4, 0x2f5, 0x2f6, 0x2f7, 0x2f8, 0x2f9, 0x2fa, 0x2fb, 0x2fc, 0x2fd, 0x2fe, 0x2ff, 0x300, 0x301, 0x302, 0x303, 0x304, 0x305, 0x306, 0x307}
17:59 imirkin: ok cool
17:59 karolherbst: max_index is 815 though in case it matters
18:00 imirkin: well wtvr
18:00 imirkin: that's slightly odd, but i dunno how it's calculated
18:00 imirkin: can you just force shorten=0? pretty sure that's not it
18:00 imirkin: but also don't want to be second-guessing myself
18:01 karolherbst: inside nv30_draw_vbo?
18:01 imirkin: doesnt matter
18:01 karolherbst: k
18:01 karolherbst: that just makes it like terrible slow _and_ broken
18:02 karolherbst: *terribly
18:02 imirkin: woohoo!
18:02 imirkin: on the right track then
18:02 imirkin: heh
18:02 imirkin: tbh that's just weird
18:02 imirkin: shouldn't matter
18:02 imirkin: shorten is just an optimization
18:02 imirkin: to emit data as U16 vs U32
18:02 karolherbst: oops
18:02 karolherbst: nouveau 0000:01:00.0: fifo: CACHE_ERROR - ch 3 [glxgears[61013]] subc 7 mthd 1710 data 00000000
18:02 karolherbst: I guess I need to reboot
18:02 imirkin: nah
18:03 karolherbst: let's see if it recovers
18:03 karolherbst: ehhh...
18:03 karolherbst: nope
18:03 karolherbst: the GPU seems to crash
18:03 imirkin: weird
18:03 karolherbst: nouveau 0000:01:00.0: gr: intr 00100000 [ERROR] nsource 00010000 [DMA_VTX_PROTECTION] nstatus 05000000 [INVALID_STATE PROTECTION_FAULT] ch 3 [000f7000 glxgears[61021]] subc 7 class 4097 mthd 1810 data 0c030021
18:03 karolherbst: nouveau 0000:01:00.0: gr: intr 00100000 [ERROR] nsource 00040000 [DMA_WIDTH_B] nstatus 05000000 [INVALID_STATE PROTECTION_FAULT] ch 3 [000f7000 glxgears[61021]] subc 7 class 4097 mthd 1ff4 data 00000001
18:04 imirkin: 1ff4 = NV40_3D_VP_RESULT_EN
18:04 imirkin: that means things got messed up
18:05 karolherbst: sure, but the machine also doesn't like to reboot :)
18:05 imirkin: i don't get what the problem is tbh
18:05 karolherbst: random stuff
18:05 karolherbst: don't worry about it
18:06 karolherbst: ahh now it rebooted
18:06 imirkin: i mean the problem we're trying to fix here :)
18:06 karolherbst: ahh
18:06 karolherbst: I mean.. gnome is broken for a reason I guess
18:06 karolherbst: :p
18:06 karolherbst: might be just that one
18:06 imirkin: coz it starts with a "G" :p
18:06 karolherbst: yeah... but it also misbehaved quite vertex like
18:07 imirkin: yeah
18:07 imirkin: i'll be honest
18:07 imirkin: i do have a faint recollectino of an undebugged issue in that area
18:07 karolherbst: now the gears are colorful
18:08 imirkin: ?
18:08 karolherbst: well not single colored
18:08 karolherbst: but.. rainbow colored
18:08 karolherbst: still mainly green/blue/red
18:08 imirkin: maybe BEGIN_NI04 doesn't work?
18:08 karolherbst: but they also are a bit more rainbow like
18:08 imirkin: that'd be wild
18:08 karolherbst: ehh
18:08 karolherbst: I know why it's slow
18:09 karolherbst: https://gist.githubusercontent.com/karolherbst/95ca1f449b4aa4797c018fdc4908c962/raw/ab07c51cab9b4f8e8ca68756c4d160e1808883c9/gistfile1.txt
18:09 imirkin: that's probably not helping
18:09 karolherbst: "bool shorten = false;//info->max_index <= 65535;" is what I changed
18:09 imirkin: 1810 = VB_ELEMENT_U32
18:09 imirkin: so the system works...
18:10 imirkin: but the value
18:10 imirkin: is quite high
18:10 imirkin: can you printf the values you're uploading in there?
18:10 karolherbst: OHHHHHHH
18:10 imirkin: i think there's a sync issue of some sort
18:10 karolherbst: wait
18:10 karolherbst: that run was weird...
18:10 imirkin: subc 7 class 4097 mthd 1810 data 00020000
18:10 imirkin: that's a very high value.
18:10 imirkin: for an index
18:10 karolherbst: so I told about that issue while bisecting where the window stayed black?
18:10 imirkin: yes
18:10 karolherbst: I had it for like 10 seconds now
18:10 karolherbst: "[ 239.764968] nouveau 0000:01:00.0: fifo: CACHE_ERROR - ch 3 [glxgears[1539]] subc 7 mthd 1710 data 00000000" got printed
18:10 karolherbst: and now it started to render
18:11 karolherbst: and nouveau stopped printing it
18:11 imirkin: 1710 = VTXBUF(n) i think
18:11 karolherbst: rendering is still wrong though
18:11 imirkin: hold on
18:11 karolherbst: but thats without disabling shorten
18:11 imirkin: i think there's a problem
18:11 imirkin: that we an fix
18:11 imirkin: but that is not directly related to any of this
18:12 karolherbst: I'll move over to main though
18:12 imirkin: grrr
18:12 imirkin: no
18:12 imirkin: (i mean, no we can't fix it)
18:12 imirkin: coz it's not a problem :)
18:13 karolherbst: ohh
18:13 karolherbst: main fixed something with shorten
18:13 karolherbst: info->index_bounds_valid && info->max_index <= 65535;
18:13 imirkin: ye
18:13 imirkin: oh, that's what i was looking at
18:15 snail: hi, i haven't been following the conversation, i was busy trying to get an old mesa to test
18:15 snail: 17:10:19 <karolherbst> https://gitlab.freedesktop.org/mesa/mesa/-/issues/5061
18:15 snail: the screenshot looks exactly like what i'm getting
18:16 karolherbst: snail: yeah, we are already debugging it :)
18:16 karolherbst: I managed to hit this on my GPU by cheating
18:24 imirkin: karolherbst: so yeah, i have vague recollections of this map on cpu + stick into pushbuf strategy running into problems sometimes
18:24 imirkin: but i never quite worked it out
18:24 imirkin: on nv50 i try to wait on fences
18:24 imirkin: perhaps we need to do that here
18:24 imirkin: there could be an upload "in progress" (i.e. in a local pushbuf)
18:24 imirkin: but ... nouveau_resource_map should take care of that
18:25 imirkin: yeah, it does a textureCnouveau_buffer_sync()
18:25 imirkin: which waits on some fences
18:25 imirkin: perhaps it waits on the wrong ones?
18:26 imirkin: fence_wr is supposed to get set when the gpu is writing
18:26 karolherbst: mhh
18:28 imirkin: hmmmmmmmmmmmmmmm
18:28 karolherbst: could be actually
18:28 imirkin: nouveau_copy_buffer
18:28 imirkin: if (likely(dst->domain) && likely(src->domain)) {
18:28 imirkin: but if it's not
18:28 imirkin: it uses util_resource_copy_region
18:28 imirkin: which in turn will use the driver's transfer stuff
18:29 imirkin: which does NOT seem to set the fence/fence_wr things
18:29 karolherbst: :O
18:29 imirkin: and i think domain == GART = "0"
18:29 imirkin: ah no. huh, weird
18:30 imirkin: vram = 1, gart = 2
18:30 imirkin: 0 must be those weird "user" buffers
18:30 imirkin: that i never quite fully understood
18:30 imirkin: maybe they do get used on nv30 though?
18:30 imirkin: worth tracing
18:30 karolherbst: well...
18:30 karolherbst: adding the fence refs doesn't do much though
18:55 karolherbst: imirkin: yeah.. anyway, if you got other ideas you can ping me, but today I won't do more debugging. Maybe I'll find something tomorrow or so though
18:55 imirkin: ok
18:55 imirkin: i got some stuff to do
19:24 glennk: screen->base.vidmem_bindings |= PIPE_BIND_INDEX_BUFFER in nv30_screen_create, is that really valid for nv40? i vaguely recall that generation not being able to pull index data from vram at all
19:24 karolherbst: glennk: for nv40 it is
19:24 karolherbst: not for previous gens nor nv44
19:25 karolherbst: so there was this small range of GPUs where this is valid
19:25 karolherbst: and this path actually works
19:27 glennk: also are u8 indices really supported on those chips?
19:28 karolherbst: no idea about the details
19:28 karolherbst: just that this path works :)
19:42 imirkin: glennk: as immediates, sure
19:43 imirkin: glennk: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv30/nv30_vbo.c#n368
19:43 imirkin: :)
19:43 imirkin: not 100% what one might expect
19:45 glennk: is the nv40 logic for u8 correct there?
19:45 glennk: looks like its u16/u32 only?
19:46 imirkin: yes
19:46 KitsuWhooa: :p
19:46 KitsuWhooa: whoops, sorry, wrong channel
19:47 glennk: imirkin, oh right, the check for index_size > 1