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