00:38 endrift: imirkin: you around?
01:01 emojimovie: hey guys, proud new owner of an nv3 here
01:32 imirkin: endrift: pong
01:33 endrift: imirkin: so I picked up an FX5200 and I'm suffering from the "phantom" display issue :/
01:33 imirkin: yea, boot with TV-1:d
01:33 endrift: well the problem is I need to reinstall the OS and I uh
01:33 endrift: can't adjust the boot params on a CD I can't even see
01:33 imirkin: erm
01:34 imirkin: ok. well i adjust it in yaboot, and i've only ever netbooted it
01:34 endrift: oh netboot
01:34 imirkin: in any case, what's the issue with that phantom display btw?
01:34 endrift: I'm currently screwing with openfirmware and it's...not fun
01:34 imirkin: does it get picked as the primary or something dumb?
01:34 endrift: yeah it gets picked as the primary
01:34 imirkin: that's odd.
01:34 endrift: so I literally cannot see OF or yaboot or anything until Linux comes up
01:35 imirkin: errrr
01:35 imirkin: yaboot is way before linux
01:35 endrift: yeah I know
01:35 imirkin: which should be using effectively offb
01:35 endrift: I can't see the yaboot screen to select which OS to boot
01:35 imirkin: you're saying the *mac* picks the tv output as the primary??
01:35 endrift: so I have to mash x if I want to boot into macos
01:36 endrift: # cat aliases/screen
01:36 endrift: /pci@0,f0000000/NVDA,Parent@10/NVDA,Display-A@0
01:36 endrift: Display-A does not exist
01:36 imirkin: right
01:36 imirkin: i know very little about OF
01:36 endrift: so it does not turn on the actual screen until after the OS boots
01:36 imirkin: i do know that the GPU should come with its own OF blob in its rom
01:36 endrift: hmm
01:36 imirkin: did you get a mac FX 5200?
01:36 endrift: well assuming I get this working, I had another question about this card
01:36 imirkin: or did you get a random one?
01:36 endrift: yeah
01:36 endrift: it has the ADC connector on the back
01:37 imirkin: ADC = ?
01:37 endrift: so unless someone reflashed it it should be the OF blob
01:37 endrift: Apple Display Connector
01:37 imirkin: mine has 2x DVI
01:37 endrift: ah
01:37 endrift: that would have been nice
01:37 imirkin: lol
01:38 imirkin: so i suspect that Display-A is the ADC?
01:38 endrift: I might stick the old card back in and reinstall the OS
01:38 endrift: yep
01:38 imirkin: but i know quite little about OF
01:38 imirkin: or macs
01:38 imirkin: i just know they got lots of endians
01:38 endrift: If only I could get the 6800 Ultra working in nouveau
01:38 endrift: hmm
01:38 imirkin: while intel boxes have few endians
01:39 endrift: I'm curious if nouveau supports OGL2 on the FX line?
01:39 imirkin: it does not
01:39 endrift: Since I know that's done on the driver side for FX
01:39 endrift:nods
01:39 endrift: well I have an ATI card in the mail :/
01:39 endrift: guess I'll keep poking at OF on my own then
01:40 endrift: worst case scenario I just won't be able to see OF/yaboot
01:40 imirkin: it'd require a ton of faking to get GL2 to *truly* work on FX
01:40 imirkin: like ... you'd need a whole swrast pipeline to fall back to ;)
01:40 endrift: yeah I figured
01:40 imirkin: since it doesn't support the full array of blending or texturing options required
01:40 endrift: I'm perplexed that driver GL2 is even a thing
01:40 endrift: for the FX that is
01:41 imirkin: it gets super-slow once you fall off the fast path cliff
01:41 imirkin: or so i've heard - i haven't played much with it myself
01:41 endrift: I tried using compiz on an FX5200 like...8 years ago
01:41 endrift: it was not a nice experience
01:42 imirkin: you basically have to know exactly what it supports
01:42 imirkin: and make sure you don't use anything it doesn't
02:23 endrift: bleh, I got it to boot off of the second display...but only when I put the 6800 Ultra back in
02:23 endrift: is there anything I can do to get my hands dirty with actual kernel debugging to try to fix NV40?
02:24 imirkin: i don't remember much about what wasn't working on it...
02:30 imirkin: oh hm, interesting. endrift, if you can, 'lspci -vvvvvnn -d 10de:' the devi
02:30 endrift: it's not plugged in atm
02:31 endrift: I can get back to you on that at...some point, but I'm kinda tired of debugging this for today heh
02:31 imirkin: the thing i'm thinking of is this: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/subdev/instmem/nv40.c#L245
02:48 endrift: imirkin: this isn't the exact error I get (I found this one on Google) but it's the same class:
02:48 endrift: nouveau 0000:f0:10.0: gr: intr 00100000 [ERROR] nsource 00000010 [LIMIT_COLOR] nstatus 04000000 [PROTECTION_FAULT] ch 1 [0008e000 Xorg[853]] subc 4 class 009f mthd 0308 data 04380780
02:48 endrift: I know LIMIT_COLOR is in it
02:48 imirkin: rrrright...
02:48 imirkin: you get those protection faults
02:49 imirkin: which basically means we messed something up
02:49 endrift: I take it that's this line? https://github.com/skeggsb/nouveau/blob/231d609c4d7a5d8cf29fdca30c694b0a3f26757a/drm/nouveau/nvkm/engine/gr/nv40.c#L274
02:51 imirkin: heh, that's the line that prints the error
02:51 imirkin: but that's just reporting what the hw is telling us
02:51 endrift: well yes I got that
02:53 endrift: googling it it all seems to be subc 4 class 009f mthd 0308
02:54 imirkin: that's coz that's the "go do things" method
02:54 endrift: ah
02:54 imirkin: interesting.
02:54 imirkin: ok, so i see one potential issue
02:54 imirkin: when you get a chance, nvapeek 1540
02:55 imirkin: ctxnv40.c has a hardcoded number of vs, while the imem reserved memory thing gets it out of 1540
02:56 imirkin: and the context getting stomped would def explain away any issues when executing gr methods
02:58 endrift: imirkin: how can I figure out my device->chipset to check if it's returning the right value?
03:00 imirkin: hm?
03:00 imirkin: your device->chipset == 0x40
03:00 endrift: ah ok
03:00 endrift: because it's an NV40?
03:01 imirkin: it's almost like those names aren't random :)
03:01 endrift: :P
03:01 endrift: I was confused by 0x67 being in there but now I see it in the table of NV40 chips
03:02 endrift: alright, I'm gonna eat dinner and when I get back I'll see what I can do
03:03 imirkin: 0x67 is a NV67 aka ... i forget
03:03 imirkin: MCP67
03:03 imirkin: something like that
04:35 endrift: imirkin: nvapeek 1540 returns 00013f0f
04:35 imirkin: ok, so that's 6 bits, which is what the hardcoded thing is too iirc
04:36 endrift: yeah the value that's hardcoded is 6
04:39 endrift: imirkin: I have the output from lspci -vvvvvnn -d 10de:, what in it are you looking for?
04:41 imirkin: the list of bars
04:41 endrift: bars?
04:44 endrift: nouveau 0000:f0:10.0: pci: failed to acquire agp
04:44 endrift: hmm
04:45 imirkin: Region 2: Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
04:45 imirkin: etc
04:46 endrift: Region 0: Memory at a2000000 (32-bit, non-prefetchable) [size=16M]
04:46 endrift: Region 1: Memory at b0000000 (32-bit, prefetchable) [size=256M]
04:46 endrift: Region 2: Memory at a1000000 (32-bit, non-prefetchable) [size=16M]
04:48 imirkin: ok, so same as mine.
04:49 imirkin: [well, same as the NV44A that i have plugged into my desktop]
04:49 imirkin: i was just hoping there'd be something odd in there
04:51 endrift: oh well, maybe I can put more time into it later
04:53 imirkin: ftr, 009f = NV15_BLIT, and 0x308 is the last register you write before it actually performs the blit operation
04:55 imirkin: and LIMIT_COLOR just means it's running over on the destination... maybe
04:55 imirkin: and 04380780 means a 1920x1080 blit
05:01 imirkin: and it could be something as sad as the original NV40 having "extra" bigendian mode bugs that later chips don't have. i think some people have gotten some of the PCIe-based ones to work
05:01 imirkin: endrift: btw, just to triple-check - you are using a 4K-page kernel, right?
05:02 endrift: Imirkin: yep, that was my first step
05:03 imirkin: hope the ATI board works better. although from what i hear, they're not exactly perfect either.
05:05 imirkin: unfortunately the g5's 6800gt boards on ebay go for $50+, so well above my "i'll get the hw to help debug it" budget
05:06 imirkin: whereas this is the board i have - http://www.ebay.com/itm/Apple-Powermac-G5-ONLY-630-4862-PC-AGP-DVI-Video-Graphics-Card-Nvidia/322508889351 - a much more affordable $15 :)
05:27 endrift: Here's hoping. Thanks anyway
10:32 RSpliet: tstellar: thanks. I'm still undecided whether this is a cool feat to have or disruptive to the concept of portability of OpenCL, but I'm glad it's there :-)
10:55 marmistrz: pmoreau, ping
11:19 RSpliet: this is IRC. Don't ask to ask, just ask
11:35 pmoreau: marmistrz: pong
11:36 pmoreau: RSpliet: We will have to see how they merge OpenCL in Vulkan
11:40 marmistrz: pmoreau, did you hear about HIP?
11:40 marmistrz: https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP
11:41 pmoreau: I have
11:42 marmistrz: Does this change anything for our plans with OpenCL + nouveau?
11:43 pmoreau: But I haven't really looked into it. Nor in running CUDA with Nouveau, but I might do that over the summer
11:43 marmistrz: For example, would we want to support HIP directly or just implement OpenCL and ask AMD to support OpenCL @ Nvidia
11:44 pmoreau: HIP seems to mainly target CUDA programs. I am not sure whether you can convert OpenCL code with it
11:45 pmoreau: bbiab
12:06 pmoreau: "HIP allows developers to convert CUDA code to portable C++." doesn't sound like it supports OpenCL, and it has to be done by the developer rather than the driver, so we will still need to support OpenCL.
12:07 tstellar: I think it would be easier for nouveau to just support CUDA directly.
12:07 pmoreau: That doesn't mean we shouldn't support HIP, but not instead of OpenCL and CUDA.
12:08 pmoreau: Besides, "What is Hip" https://www.youtube.com/watch?v=oAatPPEaZDA
12:08 tstellar: HIP converts CUDA to another lanugage called hcc, so really you'd need to support hcc.
12:09 pmoreau: Ok
12:10 tstellar: Also, on NVIDIA all the similar lanugages, like OpenMP, OpenACC communicate with the hardware using he CUDA API.
12:11 pmoreau: Good to know! I haven't really looked into them, and never played with OpenACC.
12:12 pmoreau: SYCL, on the other hand, used OpenCL, doesn't it?
12:12 RSpliet: I think SYCL is a Khronos thing, so likely
12:26 pmoreau: It will be interesting to learn more about "We are also working to converge with, and leverage, the Khronos Vulkan API — merging advanced graphics and compute into a single API.” (link: https://www.khronos.org/news/press/khronos-releases-opencl-2.2-with-spir-v-1.2)
12:36 RSpliet: pmoreau, tstellar: For clGetDeviceInfo, when querying the size of a char[] param, is param_value_size_ret guaranteed to contain the size of the string including the NULL terminator?
13:01 pmoreau: RSpliet: I would assume so
13:03 pmoreau: But it's not explicit in the spec (at least, not for the 1.0 one)
13:46 RSpliet: not for 2.2, I checked :-)
13:54 phoenixz: Hi there! I'm planning to buy a new graphics card and since its going to be a rather large investment for me, I'd like to be sure that, before I buy it, I know that it works :) Could anybody please tell me if "Gigabyte Geforce Gtx1050 Ti Oc 4gb Gddr5 Windforce2" would work? Based off the GeForce® GTX 1050 Ti chipset, it has 3 HDMI outputs (I want to connect 3 monitors to it).. Would this work with nouveau and / or the nvidia binary driver?
13:56 imirkin: nvidia blob driver supports all the nvidia hw afaik
13:56 imirkin: if you're looking for hardware that works well with open drivers, i highly recommend AMD
14:14 imirkin: skeggsb: wow, that's a lot of code to shuffle around!
14:14 skeggsb: yep...
14:14 skeggsb:curses nvidia
14:17 imirkin: did you forget to fold some patches, or was it just a multi-step conversion and you want to preserve the steps?
14:17 imirkin: ("implement a common supervisor x.y")
14:17 skeggsb: i wanted to preserve the steps so it's bisectable
14:18 skeggsb: that whole process is stupidly complicated and subtle
14:19 imirkin: ah nice. i like bisectable :)
14:19 imirkin: esp for "rewrite the world" commits
14:19 skeggsb: trust me, it came in really handy tracking down bugs while i re-tested the whole world
14:20 imirkin: do you have an idea of what sorts of issues this resolves?
14:20 skeggsb: it mostly just splits out the stuff that touches OR to be on its own, so we can refer to them independantly of the display paths themselves
14:21 skeggsb: nvidia split the whole concept into two as of gm20x, we've been keeping them identity-mapped up until now
14:21 imirkin: right, that's the technical end of it...
14:21 imirkin: and on the user end of it, this comes out as ...
14:21 skeggsb: fdo#100676 ;)
14:22 imirkin: right, so that's one example
14:22 imirkin: are there other situations you think may be helped/etc?
14:23 imirkin: is this just that one GP104 board that was weird?
14:23 skeggsb: it'll help various >=gm20x multi-head scenarios
14:23 skeggsb: all of mine have at least one set of overlapping display paths that need it
14:24 imirkin: ok, and the old behavior in such situations would be ...
14:24 skeggsb: if a user with >=gm20x plugs displays into the "wrong" two connectors, it'd blow up before, just like that bug
14:24 imirkin: ah ok
14:24 imirkin: so basically people with multiple displays on >=gm20x seeing DISP blowups should try this out?
14:24 skeggsb: yeah, i'd recommend that
14:25 skeggsb: there's fixes for a few other subtle issues that people likely won't normally hit either
14:25 imirkin: ok cool. hopefully that advice will be passed on while you get your deserved rest ;)
14:25 skeggsb: like, unplugging a MST display, and plugging a HDMI/DVI display into the same connector afterwards
14:25 skeggsb: that'd have blown up before, it won't now
14:25 imirkin: yeah, i'm sure that's a real common use-case :)
14:26 imirkin: actually probably not THAT crazy for the laptop dock situation
14:26 skeggsb: dual-link DVI on new (>=gm20x? maybe just gp10x) boards will work too, that was also subtly busted due to nvidia slightly changing vbios behaviour
14:26 skeggsb: imirkin: oh.. speaking of.. i've had quite a few f25 people complain about the 1.0.14/5 nouveau update breaking their dock ;)
14:31 imirkin: why would anything in 1.0.14 break their dock?
14:31 imirkin: oh, because previously it didn't support their hw at all?
14:31 skeggsb: yep
14:31 imirkin: ok, well if you promise to test stuff for me, i can write a patch
14:31 imirkin: or if you can find someone to promise to test stuff for me
14:32 skeggsb: i can probably manage to test it for you
14:32 imirkin: ok cool, will try over the weekend then.
14:44 skeggsb: imirkin: btw, those mesa patches i sent a while back (fix transfer of larger rectangles with DmaCopy...)... beyond piglit, i've not got any "real" games beyond xonotic etc to test with
14:45 skeggsb: would you be able to give it a spin and merge if it's ok?
14:50 RSpliet: skeggsb: how can you possibly claim "I know what's going on here" based on that picture :-D
14:51 skeggsb: RSpliet: hm?
14:51 RSpliet: FDO #100676, the one that made you rewrite all that display code
14:52 skeggsb: the log was the bigger give-away :P
14:53 skeggsb: Apr 14 10:39:17 inori kernel: 0220 1 nv50_sor_update
14:53 skeggsb: Apr 14 10:39:17 inori kernel: 00000904
14:53 skeggsb: Apr 14 10:39:17 inori kernel: 0220 1 nv50_sor_update
14:53 skeggsb: Apr 14 10:39:17 inori kernel: 00000102
14:53 skeggsb: in the same modeset
14:53 skeggsb: (they're both touching SOR1, for two different displays)
14:53 RSpliet: ah fair. Ah this is one of those dual-link displays...
14:54 skeggsb: nope
14:54 skeggsb: two displays, one on macro 1 link 0, one on macro 1 link 1
14:54 skeggsb: we treated macro==sor prior to the recent patches
14:54 skeggsb: because, that's how it was prior to gm20x
14:54 RSpliet: ah right
14:55 RSpliet:doesn't know all the levels of redirection on display HW. Don't bother explaining now though, I should be at work
14:55 RSpliet: *indirection
15:08 jamm: thanks hakzsam, pmoreau !
15:21 pmoreau: jamm: You're welcome :-)
15:27 karolherbst: mwk: do you know if I have to do anything on a falcon before setting a breakpoint?
15:36 phoenixz: imirkin: well in all honesty, I don't care about open or closed at this point, I'll just be happy if it works at all :)
15:39 phoenixz: And since for AMD I cannot find the right combo price - functionality... If it will work, then I think I'll go for Gigabyte Geforce Gtx 1050 Ti G1 Gaming 4g 4gb
16:05 xen: skeggsb: thank you for the notification, i'm going to test it on the weekend
18:21 marmistrz: pmoreau, maybe the Nouveau developers could talk with the HIP developers and ask them to implement OpenCL backend too
18:21 marmistrz: One of the arguments may be that nouveau is targetting for OpenCL
18:23 marmistrz: Second: that it's a way to target Intel GPUs too (ofc, they could use Vulkan)
18:23 marmistrz: will getting SPIR-V give us an easy way to get Vulkan on nouveau too?
18:28 RSpliet: marmistrz: http://gpuocelot.gatech.edu/ seems to be an academic project to translate ptx to LLVM. Perhaps that can be leveraged for CUDA support in Mesa
18:33 jvesely: why would you need ptx to llvm?
18:33 jvesely: you can just use clang CUDA frontened and get llvm directly
18:34 RSpliet: jvesley: that's assuming binaries ship with PTX, not CUDA C++
18:37 jvesely: ah, guess I only considered FOSS sw :)
19:36 pmoreau: marmistrz: Yes, as shaders in Vulkan are uploaded as SPIR-V binaries (and, starting in OpenCL 2.1, kernels must be uploaded as SPIR-V binaries as well).
19:37 airlied: Vulkan SPIR-v and OpenCL SPIR-V are not the same thing though :)
19:37 pmoreau: Well, yes
19:38 pmoreau: At least in Vulkan 1.x
19:38 pmoreau: Given that Khronos is planning to merge OpenCL and Vulkan in a single API
19:45 airlied: pmoreau: that isn't actually their intent
19:45 airlied: it got overstate in the news
19:45 airlied: their intent is to move OpenCL towards a Vulkan-like API
19:46 airlied: or investigate that direction
19:46 mangix: official quote: The OpenCL working group has taken the decision to converge its roadmap with Vulkan, and use Vulkan as the basis for the next generation of explicit compute APIs – this also provides the opportunity for the OpenCL roadmap to merge graphics and compute.
19:57 marmistrz: That sounds good. And what do you think about talking with the HIP developers?
19:58 marmistrz: Could the nouveau devs do something like that
20:00 RSpliet: marmistrz: what does that bring us that's valuable? If it's CUDA, we'd better work on a PTX front-end and just support it proper. If it's single-source C++ dev, then there's already SYCL
20:01 RSpliet: either way let's first get something *functioning* before committing to all those fancy APIs
20:02 karolherbst: are there any plans on AMDs side to somehow improve their current Mesa OpenCL support or will they just stop to care and go with their fancy new thing?
20:03 marmistrz: RSpliet, I've just looked at SYCL and it seems great
20:03 marmistrz: but with HIP there is single source for CUDA and AMD
20:04 marmistrz: So it's a workaround for nvidia spewing out crappy OpenCL compilers just to prove CUDA's superiority
20:04 marmistrz: it's just saying: we're working on OpenCL (we're doing this anyway) and could you please support OpenCL too (possibly when we're done)
20:05 marmistrz: I don't say anything about committing! let the HIP folks work on HIP, and let us work on OpenCL
20:05 RSpliet: yes, which is difficult enough right now, but a work-in-progress
20:06 tstellar: marmistrz: The HCC compiler (which is what HIP uses used to support OpenCL, but it was deprecated). I don't think there is any advantage of trying to target HIP/HCC versus just trying to support cuda directly.
20:07 marmistrz: I don't want to target HIP
20:07 marmistrz: I'd like HIP to reuse what we'll do anyway
20:07 marmistrz: Just use OpenCL as a backend, just as it uses CUDA now
20:11 tstellar: marmistrz: I don't think HIP developers are going to want to bring back OpenCL support. A cuda state tracker for mesa is a more realistic goal in my opinion and a better technical solution.
20:11 marmistrz: tstellar, but we won't have nvcc anyway
20:12 marmistrz: CUDA depends on a lot of compiler magic
20:12 tstellar: marmistrz: clang can compile cuda code.
20:12 marmistrz: if clang can compile cuda code, what prevents us from running it under nouveau?
20:13 tstellar: marmistrz: lack of a cuda state tracker and ptx->nvidia isa compiler.
20:14 RSpliet: tstellar: or at least ptx->tgsi, or ptx->spir-v :-P
20:14 tstellar: RSpliet: Yeah ptx->nvidia for some values of ->
20:14 RSpliet: ptx->llvm or ptx->nir in the pipeline?
20:15 mangix: karolherbst: no plans for mesa
20:15 tstellar: RSpliet: not that I know of.
20:16 tstellar: RSpliet: I wonder if ptx->spir-v exists somewhere that seems reasonable that someone would want that.
20:20 karolherbst: mangix: oh well
20:27 karolherbst: yay, finally having my own web server running
20:27 karolherbst: http://mini.karolherbst.de/nouveau/devs/
20:29 karolherbst: mupuf: now I have the infrastructure to have my own reator setup, just no hardware, but this should come soon as well
20:30 karolherbst: I could make my tesla GPU available, but currently everything runs on that computer
22:59 ptx0: trying to get 2560x1080 resolution with my new monitor and nouveau driver isn't going so well
23:00 ptx0: so i've got these "DDC generated modelines" appearing in xorg log that seem to contain the one i want but i can't copy and paste it into xorg.conf