00:26 plutoo: are commands issued generally async?
00:26 plutoo: for example with 0xb0b5
00:26 plutoo: is there a way to block until it finishes?
00:40 imirkin: commands are dispatched in order to each engine
00:40 imirkin: the engine can do whatever the fuck it wants
00:41 imirkin: engines will have fence-writing commands, which can be used to figure out when the internal queue is "done" (since it has processed the fence-writing command)
00:41 imirkin: some very complex engines will have a "Wait For It" type of command which will basically gum up the internal works and prevent further parallelism.
00:42 imirkin: (basically upon hitting such a command, the engine will complete all outstanding work before processing further commands)
00:42 plutoo: like a barrier
00:42 imirkin: yes.
00:43 imirkin: this is obviously not what you want in 99.9% of cases
00:44 plutoo: i'm issuing a request to SUBC_COPY but i don't observe the copy
00:44 imirkin: right
00:45 plutoo: *except* when another app takes foreground, it starts copying
00:45 imirkin: look at nvc0_transfer.c
00:45 imirkin: it attaches a fence
00:45 imirkin: and then if push comes to shove, will wait on that fence
00:48 plutoo: https://github.com/anholt/mesa/blob/master/src/gallium/drivers/nouveau/nvc0/nvc0_transfer.c#L332
00:48 plutoo: i'm doing this exact sequence
00:48 plutoo: are you saying the dma engine is stuck waiting on a fence?
00:49 imirkin: right, but there are functions which call that function
00:50 imirkin: in nouveau_buffer.c (look for ->copy_data calls)
00:50 imirkin: in one case we do a nouveau_bo_wait right after, which will wait for the auto-fence that the kernel inserts to complete
00:50 imirkin: in another case, we attach a fence to the resource - nouveau_fence_ref(nv->screen->fence.current, &buf->fence)
00:50 imirkin: this happens for sub-allocated objects
00:51 imirkin: and then other logic will automatically wait on such a fence
00:51 imirkin: in theory
00:52 plutoo: ic
00:52 imirkin: note that on kepler+, the COPY2 engine actually sits inside of PFIFO
00:52 imirkin: good times.
00:53 imirkin: while the COPY0/1 engines are on PGRAPH, and are "more" asynchronous
00:53 skeggsb: it doesn't, really. the method interface for it does, the hw that processes the commands are separate
00:53 skeggsb: there used to be a falcon on the copy engines to handle that, but they moved it
00:54 imirkin: and in our infinite genius, we decided to make a different interface than what the blob did
00:54 imirkin: skeggsb: someone was having trouble with accel on one of those NVS 410's or whatever (dual nv43's)
00:54 skeggsb: we can still change that, we don't have userspace that uses it (not really..) fortunately
00:54 plutoo: but you need to tell the copy engine which syncpt to increment when finished?
00:55 plutoo: i don't see that happening
00:55 imirkin: skeggsb: validate_ttm was failing
00:55 imirkin: with the zaphodheads + xinerama setup
00:55 imirkin: once he added heads on the second gpu
00:56 imirkin: plutoo: yeah, like i said, it's a bit implicit
00:56 imirkin: nouveau_buf_fence inserts a fence into the cmdstream and attaches a reference to it in the buffer
00:56 imirkin: actually it seems like that we end up attaching the wrong kind of fence there...
00:56 imirkin: but the hw isn't infinitely async.
00:56 imirkin: so it probably works out
00:58 plutoo: only way i see this working is cmdstream actually being stalled by copy
00:59 plutoo: i see in nvidias blob they do the same thing
00:59 plutoo: so ...
01:04 imirkin: well, again, this stuff ain't magic
01:04 imirkin: pfifo dispatches commands
01:04 imirkin: but the thing that receives commands doesn't have infinite asynchronicity
01:05 imirkin: so a fence command right after the copy will end up waiting on the copy
12:01 rhyskidd: any willing reviewers of https://github.com/envytools/envytools/pull/125 ?
12:01 rhyskidd: VBIOS support for DisplayPort BIT table
13:20 imirkin: pmoreau: fyi, nv30 is part of the gallium nouveau driver and supports nv3x/nv4x. nouveau_vieux is for nv2x and older.
13:20 imirkin: the division is along the "shaders" vs "no shaders" line. (one could argue that nv20 had shaders, but it'd be a weak argument.)
13:20 pmoreau: Ah, didn’t know that, thanks!
13:22 pmoreau: I think I always missed the nv30 folder in src/gallium/drivers/nouveau
13:22 imirkin: nv50 / nvc0 are a lot more tied together due to codegen being used by both
13:22 imirkin: and also because the hw didn't change a *ton* between nv50 / nvc0 at the api level
13:23 imirkin: but e.g. the pushbuf encoding changed, so it'd be a bit tough to make a single driver for both
13:24 pmoreau: Okay
13:26 pmoreau: karolherbst: I’ll send the updated series soon (been tweaking it a bit this morning while waiting for some tests to complete).
13:26 imirkin: [and actually all the varying setup is totally different... nv50 is super-flexible and impossible to use, nvc0 is nice and sane]
13:27 pmoreau: Ah ah ah! Too much flexibility being a bad thing :-)
13:27 karolherbst: pmoreau: nice
13:27 imirkin: (but of course it's flexible in the wrong places, so you still end up with unsupportable details)
13:28 pmoreau: Was it quite different from nv4x regarding varyings?
13:28 karolherbst: pmoreau: you will keep the C -> spirv changes still seperated, right?
13:29 pmoreau: Yeah, I’ll update my add_clover_spirv_backend_v1 to work with the clover_spirv_series_v5
13:30 karolherbst: nice
13:30 pmoreau: Feel free to include those patches in a series adding OpenCL SPIR-V support to NIR, or a follow-up series getting everything together.
13:31 karolherbst: yeah, I think it won't happen this month though
13:31 karolherbst: this should be one of the last patches
13:31 karolherbst: not quite sure
13:31 karolherbst: I will create some branch today to have a minimal set of patches needed for some HMM tuff
13:31 karolherbst: wondering how many spirv_to_nir patches I will end up needing
13:32 karolherbst: but there is still some mess ups regarding structs somewhere
13:32 pmoreau: Okay
13:35 imirkin: nv4x has a pretty fixed-function-style varying setup
13:35 imirkin: i.e. certain outputs are for this, others for that. actually a lot like nvc0 :)
13:36 imirkin: except no generic varyings
13:36 imirkin: only texcoords
13:36 imirkin: that's as generic as it got
13:44 karolherbst: pmoreau: there is no way for you to join any khronos stuff, right?
13:44 pmoreau: karolherbst: Unless I pay the $15,000, doesn’t seem like it.
13:44 pmoreau: However
13:45 pmoreau: With all the ray tracing stuff, and it possibly coming to Vulkan, that gives quite a good incentive to have the university join Khronos.
13:46 karolherbst: :)
13:46 karolherbst: well but that means you are able to join next year the earliest
13:46 pmoreau: But I don’t know when that will happen, especially with my supervisor being away at Occulus Research in Seattle for a year.
13:46 karolherbst: ;)
13:47 karolherbst: first discussion, then there has to be a budget for this -> next year and then somebody actually has to start the process, so mid next year sounds reasonable :p
13:47 pmoreau: Well, technically I’ll have access to it in a month or so, but I won’t be able to use it for Nouveau stuff.
13:48 karolherbst: huh?
13:48 karolherbst: well you wouldn't, you just would use it for opencl stuff :p
13:49 pmoreau: imirkin: I was wondering whether they decided to have something quite generic, flexible with nv50 because nv4x was too constrained/did work for what they were thinking for new generations. And after running their experiments, decided on which subset was enough.
13:50 pmoreau: karolherbst: :-D It should work for llvm-spirv, OpenCL CTS and SPIRV-Tools, and I was planning to do that.
13:50 karolherbst: ;) right
13:50 karolherbst: I can do the nouveau related stuff anyway
13:52 pmoreau: Indeed, you can :-)
13:55 karolherbst: so, the calls starts in around 30 minutes. You are fine with the llvm-spirv branch I showed to you, right?
13:56 karolherbst: imirkin: quick review for those limms patches?
13:57 pmoreau: karolherbst: Is the plan to cut all the LLVM, non-SPIRV, bits in a pull request?
13:57 karolherbst: pmoreau: what pull request?
13:58 karolherbst: I think we will just use that branch and push it somewhere nice
13:58 pmoreau: None that I know of, I am talking about the future here: how do you plan to get rid of all non-SPIRV bits? Or are you planning to keep everything?
13:58 karolherbst: dunno
13:58 karolherbst: not decided yet
13:58 karolherbst: well
13:58 pmoreau: Hum, okay
13:59 karolherbst: we will go for a tool based thing
13:59 karolherbst: this is decided
13:59 karolherbst: and I hope we can decide on the code base today
13:59 karolherbst: how/where we push it? dunno
14:01 pmoreau: Why am I asking that? If we use the same approach as tomeu and hopetech took, to extract only the commits touching the SPIR-V bits, then we don’t have to carry all the history of the other bits in the repo, making it smaller and faster to clone, compared to having a commit that nukes all the other bits but they are still taking space in Git.
14:02 pmoreau: But yes, otherwise I am fine with that branch.
14:02 karolherbst: yeah
14:02 karolherbst: I guess having a small repsitory is a good idea
14:02 karolherbst: maybe we just force push onto master
14:03 karolherbst: or create a new repository
14:03 karolherbst: I would prefer the latter
14:03 hopetech: I think that we are going to have a small repo.
14:05 pmoreau: Cool
14:06 pmoreau: A new repo is “nicer”, but do you name it LLVM-SPIRV, just to confuse everyone, between SPIRV-LLVM and LLVM-SPIRV? :-D
14:07 karolherbst: sure
14:07 karolherbst: what else?
14:08 pmoreau: Hum, can’t find a better name
14:09 pmoreau: Anyway, that’s not up to me to find it ;-)
14:17 hopetech: pmoreau: http://www.commitstrip.com/en/2015/10/27/one-of-the-coders-hardest-problems/?
14:17 pmoreau: So true :-/
14:21 karolherbst: just use random names
14:23 karolherbst: "unknown nir_op vec8" nice...
14:23 karolherbst: that will be fun
14:25 karolherbst: pmoreau: I think robclark nearly got all basic tests to pass...
14:25 pmoreau: Awesome!
14:26 karolherbst: non global memory is still broken though
14:26 karolherbst: that kind of stuff isn't that trivial
14:26 karolherbst: because of the generic pointer stuff
14:27 karolherbst: we are thinking about adding support for fat pointers in nir and depend on optimization to optimize the type away
14:27 karolherbst: like a pointer would be a vec2 { ptr, type }
14:28 karolherbst: and in generic cases you end up with switch (type) {global: store/load_global local: store/load_local ....}
14:28 pmoreau: And you need generic because of 2.0, which is needed for SVM, right?
14:28 karolherbst: yeah, kind of
14:28 karolherbst: we can do the SVM bits without that stuff though
14:28 karolherbst: but
14:29 karolherbst: if we want to have OpenCL 2.0 we have to deal with generic pointers
14:29 karolherbst: and we kind of want to I guess
14:47 karolherbst: pmoreau: guess what the issue now is :D
14:47 karolherbst: finding a name
14:47 pmoreau: \o/
14:52 pmoreau: karolherbst: https://github.com/pierremoreau/mesa/tree/clover_spirv_series_v5 and https://github.com/pierremoreau/mesa/tree/add_clover_spirv_backend_v2 it hasn’t been compiled tested yet, but it should hopefully still work. Going to compile test them tonight.
14:55 karolherbst: nice
14:55 karolherbst: will test it after I am done testing my rebased stuff on your v4 stuff :D
14:59 pmoreau: Rebase all the way :-D
15:08 karolherbst: !
15:15 karolherbst: work_dim is 32 on nv hw, right?
15:15 karolherbst: ohh wait, that was the other thing
15:16 karolherbst: subgroup_size is 32
15:19 pmoreau: 32 threads make a warp, right. I think you are right, and a subgroup in OpenCL is a warp in CUDA.
15:20 karolherbst: I am talking about get_work_dim though
15:21 karolherbst: this is the number of dimension used in clEnqueueNDRangeKernel
15:23 pmoreau: Ah, get_work_dim won’t go above 3 :-D
15:27 karolherbst: yeah
15:28 karolherbst: pmoreau: maybe it is a good idea to defer part of the compilation until the kernel is actually launched
15:28 karolherbst: so that we could optimize those constants away
15:28 karolherbst: "constants"
15:28 karolherbst: pmoreau: build errors
15:28 karolherbst: btw
15:28 karolherbst: error: 'process_program' is not a member of 'clover::spirv'
15:28 karolherbst: and other things
15:29 pmoreau: Duh
15:30 pmoreau: karolherbst: Look at spirv/invocation.hpp, that should be an easy fix. Hopefully more is not needed
15:31 pmoreau: I updated the branch with that fix.
15:32 karolherbst: pmoreau: also, could you appy a little fixup to my ICD patch? https://github.com/karolherbst/mesa/commit/00c9fa70565025de7440a91dfaba3f977f928df9
15:32 karolherbst: the src/gallium/state_trackers/clover/api/dispatch.hpp change
15:32 karolherbst: void -> cl_command_queue
15:33 pmoreau: I’ll change the return type in dispatch.hpp
15:33 karolherbst: nice, thanks!
15:33 pmoreau: You didn’t wanted me to squash the patch you just linked with the ICD patch, right? Just update the header file
15:34 karolherbst: just the header file
15:34 pmoreau: Okay
15:34 karolherbst: next time I will create a patch you could actually squash in
15:34 karolherbst: if I don't forget
15:35 pmoreau: No worries, I just wanted to be sure I understood you correctly.
15:35 karolherbst: pmoreau: ../src/gallium/state_trackers/clover/spirv/invocation.cpp:576:85: error: invalid initialization of reference of type 'const string& {aka const std::__cxx11::basic_string<char>&}' from expression of type 'clover::spirv::process_program(const std::vector<char>&, const clover::device&, bool, std::__cxx11::string&)::<lambda(const char*)>'
15:36 karolherbst: ../src/gallium/state_trackers/clover/spirv/invocation.cpp:673:79: error: invalid initialization of reference of type 'const string& {aka const std::__cxx11::basic_string<char>&}' from expression of type 'clover::spirv::link_program(const std::vector<clover::module>&, const clover::device&, const string&, std::__cxx11::string&)::<lambda(const char*)>'
15:36 karolherbst: and other places as well...
15:36 karolherbst: let me write a patch
15:37 karolherbst: uhh
15:37 pmoreau: I must have done something really dumb
15:38 karolherbst: pmoreau: there are other non trivial compile errors
15:38 karolherbst: you might want to look into yourself
15:38 karolherbst: pmoreau: also, we want to have a new repository by the end of this week
15:39 karolherbst: so we should be able to do some nice pull requests soon
15:39 pmoreau: Technically I just did some copy/pasting when solving the conflict, so I’m guessing I just messed up where I copy pasted and some closing '}' is now misplaced.
15:39 pmoreau: Ah, great!
15:55 pmoreau: karolherbst: Found the bug you mentioned: I change the definition of is_valid_spirv but forgot to update the callers in the spirv backend.
15:55 karolherbst: ahh
16:01 pmoreau: karolherbst: Both branches updated with your fix to dispatch.hpp, and fixed the call to is_valid_spirv. Hopefully it should compile now.
16:03 karolherbst: pmoreau: 11 disabled tests: FAILED 21 of 84 tests.
16:04 karolherbst: most fails to unsupported memory types
16:08 pmoreau: Running test_basic?
16:08 karolherbst: yeah
16:08 pmoreau: Not too bad! And what are those unsupported memory types?
16:08 karolherbst: private and constant
16:08 karolherbst: mainly
16:09 pmoreau: Okay
16:09 karolherbst: I think local works just fine
16:09 karolherbst: and some alignment issues
16:09 karolherbst: ohh
16:09 karolherbst: local doesn't seem to work as well
16:09 karolherbst: oh well
16:09 karolherbst: with that fixed we should get below 10 fails
16:10 pmoreau: Fyi, the OpenCL WG is looking into fixing the SPIR-V environment to not use generic with OpenCL 1.2: https://github.com/KhronosGroup/OpenCL-Docs/issues/7
16:10 karolherbst: we want to support it anyway
16:10 karolherbst: but mhh
16:10 karolherbst: generic pointers are kind of weird
16:11 pmoreau: Agreed
16:26 karolherbst: pmoreau: I get a CL_INVALID_PROGRAM_EXECUTABLE in clCreateKErnel :(
16:26 karolherbst: but the compile and link didn't fail
16:26 pmoreau: Sadness
16:27 karolherbst: yeah
16:28 pmoreau: Can you dump the SPIR-V, just to check that that part still works?
16:30 karolherbst: pmoreau: ../src/gallium/state_trackers/clover/api/program.cpp:60:44: error: invalid conversion from 'const void*' to 'const char*'
16:30 karolherbst: pmoreau: ../src/gallium/state_trackers/clover/api/program.cpp:62:43: error: cannot convert 'const string {aka const std::__cxx11::basic_string<char>}' to 'size_t {aka long unsigned int}' for argument '2' to 'bool clover::spirv::is_valid_spirv(const uint32_t*, size_t, const string&, const notify_action&)'
16:30 karolherbst: it is with the old stuff
16:31 pmoreau: Ugh, of course
16:31 karolherbst: mhh, but nothing gets compiled indeed
16:31 karolherbst: clover only dumps the cl file
16:32 pmoreau: I had forgotten to update is_valid_spirv in the SPIR-V backend, but while addressing that, I decided to change its definition, and of course forgot to update the code calling it in api/program.cpp --"
16:32 karolherbst: duh...
16:32 karolherbst: compile failed
16:32 karolherbst: okay, now how to get the compile fail message
16:33 pmoreau: Ugh, I changed the definition of is_binary_spirv, not is_valid_spirv. Anyway, patch incoming soon.
16:33 pmoreau: Hum, no, looks like I did.
16:35 pmoreau: There should be some information in the BUILD_LOGS
16:35 pmoreau: Alternatively, just run it with gdb, and do `catch throw` to break on any throw, which should happen if something goes wrong.
16:38 karolherbst: nice ./example_list.h:5:2: error: unknown type name 'uint32_t'
16:39 karolherbst: "Type 7 is missing" this is a usefull error message
16:40 karolherbst: pmoreau: hum, struct within a struct
16:40 karolherbst: isn't that legal in clc?
16:41 pmoreau: It should be legal
16:42 karolherbst: so yeah
16:43 karolherbst: doesn't work that well
16:43 karolherbst: ::extract_kernels_arguments
16:44 pmoreau: I probably didn’t try struct within structs as argument.
16:44 karolherbst: yeah, probably
16:45 karolherbst: guess void* pointers will do now
16:45 karolherbst: uhhh
16:45 pmoreau: Could you send me the SPIR-V please? I’d like to have a look at it, and try the code against it while trying to fix the bug
16:45 karolherbst: pmoreau: is there a nice way to use global and so on in C programs?
16:46 karolherbst: pmoreau: https://gist.github.com/karolherbst/4725ae39b7f013b311c6050d0eb557de
16:47 pmoreau: As in define a global pointer in your C program and pass it to the kernel via clKernelSetArg?
16:47 karolherbst: pmoreau: no
16:47 pmoreau: Thanks
16:47 karolherbst: literally declare a global pointer
16:47 karolherbst: #ifdef magic
16:47 karolherbst: so I can share the declaration between OpenCL C and C
16:47 pmoreau: Ah
16:48 karolherbst: __OPENCL_C_VERSION__
16:48 pmoreau: `global int* foo;` does not work?
16:48 pmoreau: Ah no, you want the ifdef magic stuff
16:48 pmoreau: Hum
16:48 karolherbst: nice, works
16:49 pmoreau: Good to know
16:49 karolherbst: #ifdef __OPENCL_C_VERSION__ #define global global #else #define global #endif
16:49 karolherbst: [DEBUG] At word No.25: "Duplicate non-aggregate type declarations are not allowed. Opcode: TypePointer id: 7"
16:49 karolherbst: duh
16:49 karolherbst: https://gist.github.com/karolherbst/3182b5edc3b1392e5fc3c7dc6123674c
16:50 karolherbst: this thing can be really picky sometimes
16:51 pmoreau: Well, it does its job :-)
16:52 karolherbst: ...
16:53 karolherbst: so no linked lists and no void, now things are getting challenging
16:54 pmoreau: Well, we need to fix SPIRV-LLVM to not emit twice the same forward pointer type
16:54 karolherbst: why would it even matter
16:54 pmoreau: Okay, so I do not handle OpTypeForwardPointer at all.
16:54 karolherbst: I would fix the spec for such a silly thing
16:57 pmoreau: You would end up with even weirder behaviour: two types are different, no matter what. So you couldn’t do `your_frst_pointer = your_snd_pointer` because those are different types.
16:58 karolherbst: comparing pointers if you want to compare value is the wrong thing to do to begin with
16:58 pmoreau: Sure
16:58 karolherbst: but yeah, I can see that it might cause some issues somewhere
16:59 pmoreau: (Thought it was an assignment in my example, not a comparison: there was only one '=')
17:07 pmoreau: karolherbst: I updated the patches to handle OpTypeForwardPointer as well. Not 100% sure about the implementation, but it should do the job for now.
17:08 karolherbst: well okay, but that llvm-spirv bug is more annoying right now
17:10 karolherbst: pmoreau: https://github.com/karolherbst/HMM-examples
17:10 pmoreau: You could try to comment out the SPIR-V validator, and hope nothing breaks inside the spirv_to_nir
17:11 karolherbst: mhh
17:11 karolherbst: that's an idea
17:11 pmoreau: Great idea for the repo! I’ll need to try it out tonight now. :-/
17:12 karolherbst: pmoreau: I also have some aptches to port yours to CL2
17:12 karolherbst: but I cheated using #define CL_HPP_ENABLE_PROGRAM_CONSTRUCTION_FROM_ARRAY_COMPATIBILITY 1 :D
17:13 pmoreau: Wow, wth is that define from?
17:19 karolherbst: CL2.h
17:19 karolherbst: #define CL_HPP_TARGET_OPENCL_VERSION 200 is another one you might want to set :)
17:21 pmoreau: Yeah, if doing OpenCL 2.0 stuff, which I haven’t done just yet.
17:56 karolherbst: pmoreau: I've added simple FMA example which should just work with the HMM stuff
17:56 karolherbst: pmoreau: https://github.com/karolherbst/HMM-examples/blob/master/fma.cpp :)
17:57 karolherbst: pmoreau: you basically just need glisse kernel hmm branch and my mesa nouveau_nir_spirv_opencl_v3
17:57 karolherbst: branch
18:32 pmoreau: karolherbst: Okay, good.
18:33 pmoreau: Hum, I think I have a regression with the latest stable kernel. :-/
18:33 karolherbst: pmoreau: anyway, it still works :D Had to reboot to my HMM kernel to verify it
18:35 karolherbst: pmoreau: I think we need to add a PIPE_COMPUTE_SVM_SUPPORT = {0,1,2,3} cap
18:35 karolherbst: 0: no SVM 1: SVM with alloc + map 2: SVM with alloc 3: transparent SVM
18:36 karolherbst: and if it is set to 3 we can implement clSVMAlloc with malloc
18:36 karolherbst: and things like that
18:36 pmoreau: For some reason, Nouveau gets initialised super late, like after the login greeter started X :o
18:36 karolherbst: uhh
18:36 karolherbst: weird
18:38 pmoreau: I won’t be able to test much if I can’t even get a VT up with Nouveau
18:41 karolherbst: uhh
18:41 karolherbst: pmoreau: what kernel are you booting?
18:41 pmoreau: 4.15.10
18:41 karolherbst: mh 4.15.9 should be fine
18:41 karolherbst: but
18:41 karolherbst: I don't use nouveau as main
18:42 imirkin_: which hw is this?
18:42 pmoreau: (stock Arch Linux kernel)
18:42 pmoreau: Tested on both GM206 and GP102
18:45 pmoreau: I’ll try downgrading to an earlier version, and if that doesn’t work, I’ll share some information, but I couldn’t find anything interesting there.
18:45 orbea: karolherbst: imirkin_ just wanted to point out that beetle-psx now requests a 3.3 core profile instead of 3.1. I suppose the reason why it was requesting 3.1 was because someone decided to try to cheat the version requirement without really discussing it with other people...it was using 3.3 originally.
18:45 karolherbst: pmoreau: how often did you boot on the .10 kernel?
18:46 karolherbst: orbea: I see
18:46 karolherbst: orbea: so it uses some 3.3 features?
18:46 imirkin_: orbea: cool. 3.2 would work too (at least in principle, i dunno what all it actually requires)
18:46 orbea: karolherbst: Yea, it uses at least 3.2 or 3.3, not really sure
18:47 karolherbst: pmoreau: next thing: support in CMake for *.cl files :D
18:47 imirkin_: afaik there's some weirdo format issue that prevents GL 3.3 from being exposed on big-endian r600 setups
18:47 pmoreau: karolherbst: Good question, I am not sure. I installed it Friday evening, and I am pretty sure I booted it a few times during the weekend.
18:48 orbea: might be worth looking at 3.2 closer, we went with 3.3 because that was the original intent
18:52 karolherbst: pmoreau: I know that some stuff can be delayed in drm for whatever reason
18:52 karolherbst: orbea: usually it is worth checking what gl* calls are made and what features are used in the glsl shaders
18:52 imirkin_: of course big-endian r600 isn't a *super* common use-case
18:53 orbea: the retroarch/libretro people usually prefer more portable when possible :)
18:53 karolherbst: 1.0 is more portable :p
18:53 orbea: :P
18:54 imirkin_: it's the 2_10_10_10 format iirc which messes it up? or something.
20:38 freekzak: Hi people. GT216M [GeForce GT 330M] on a macbook pro 6,1 with debian 9 installed. when I install nouveau drivers after reboot I get a black screen. I end up installing the distro again. Google steps I found had no success. Any ideas ?
20:38 imirkin_: pastebin dmesg
20:39 freekzak: I'm on fresh install system now without nouveau drivers installed.
20:39 freekzak: using intels card
20:43 freekzak: imirkin_, what exactly r u suggesting ?
20:45 imirkin_: i'm suggesting that you provide a pastebin with the contents of dmesg
20:46 imirkin_: one would need to see if there are any errors reported to further diagnose
20:47 freekzak: but I have installed the system from scratch so I have no such log
20:47 imirkin_: ah ok
20:47 freekzak: r there any steps to do it right from the beggining ?
20:47 imirkin_: without specific errors, i don't know i can be of much help
20:48 karolherbst: freekzak: uhh, I think those were the weirdo laptops
20:48 karolherbst: freekzak: like if you install in bios mode, you have nvidia as the only GPU
20:48 karolherbst: are you sure you use intel?
20:50 freekzak: pci@0000:01:00.0 display GT216M [GeForce GT 330M]
20:50 freekzak: pci@0000:00:02.0 display Core Processor Integrated Graphics Controller
20:50 freekzak: without any nvidia drivers on the system ...
20:51 freekzak: 01:00.0 VGA compatible controller: NVIDIA Corporation GT216M [GeForce GT 330M] (rev a2) (prog-if 00 [VGA controller])
20:51 freekzak: Subsystem: Apple Inc. GT216M [GeForce GT 330M]
20:51 freekzak: Flags: bus master, fast devsel, latency 0, IRQ 32
20:51 freekzak: Memory at b2000000 (32-bit, non-prefetchable) [size=16M]
20:51 freekzak: Memory at a0000000 (64-bit, prefetchable) [size=256M]
20:51 freekzak: Memory at b0000000 (64-bit, prefetchable) [size=32M]
20:51 freekzak: I/O ports at 3000 [size=128]
20:51 freekzak: Expansion ROM at b3000000 [disabled] [size=512K]
20:51 freekzak: Capabilities: <access denied>
20:52 freekzak: 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 18) (prog-if 00 [VGA controller])
20:52 freekzak: Flags: bus master, fast devsel, latency 0, IRQ 33
20:52 freekzak: Memory at b3400000 (64-bit, non-prefetchable) [size=4M]
20:52 freekzak: Memory at 90000000 (64-bit, prefetchable) [size=256M]
20:52 freekzak: I/O ports at 4130 [size=8]
20:52 freekzak: Capabilities: <access denied>
20:53 freekzak: Kernel driver in use: i915
20:53 freekzak: Kernel modules: i915
20:57 freekzak: ok that is strange
20:57 freekzak: freekzak@debian:/sys/firmware/efi$ lspci -vnnn | perl -lne 'print if /^\d+\:.+(\[\S+\:\S+\])/' | grep VGA
20:57 freekzak: 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 18) (prog-if 00 [VGA controller])
20:57 freekzak: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT216M [GeForce GT 330M] [10de:0a29] (rev a2) (prog-if 00 [VGA controller])
20:58 freekzak: Any controller with [VGA controller] at the end is your currently active GPU right ?
21:04 freekzak: anybody ?
21:06 freekzak: cheers
22:08 lachs0r: hello. I’m having issues with NV50 cards (9800GT, 210, 8400GS) and recent-ish kernels (4.15.9 in this case). 100% cpu usage in a kworker process associated with nouveau. proprietary garbage causes system instability, so I’m trying to use nouveau, which otherwise works well enough for my use case :)
22:09 imirkin_: lachs0r: which kworker's getting stuck?
22:09 imirkin_: you can get backtraces ... somehow
22:09 imirkin_: (with perf maybe?)
22:09 imirkin_: or via /proc/<pid>/stack
22:10 lachs0r: I did look at perf a few days ago. I can take a look in a few minutes (just took the whole thing apart to swap GPUs…)
22:10 imirkin_: there's a bug in 4.15
22:10 imirkin_: not 100% sure what the various failure cases are
22:10 imirkin_: fixed by https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.16-rc6&id=da5e45e619b3f101420c38b3006a9ae4f3ad19b0
22:11 imirkin_: a lot of VM stuff was redone in 4.15
22:12 lachs0r: then maybe I should try a HEAD kernel
22:19 lachs0r: okay, problem persists in 4.16.0-rc6-1.ga98eb00
22:21 lachs0r: cat /proc/763/stack
22:21 lachs0r: [<0>] 0xffffffffffffffff
22:21 lachs0r: hmm.
22:21 imirkin_: i like it
22:28 karolherbst: yeah, that happens sometimes
22:28 karolherbst: lachs0r: try ct it more often
22:28 lachs0r: debug kernel now
22:28 karolherbst: sometimes you see stuff
22:28 lachs0r: spams the log with this: https://0x0.st/sB8P.txt
22:28 imirkin_: ok ... so it's some EDID failure
22:29 lachs0r: well the display device is some chinesium hdmi → eDP converter with firmware that pretends to be a TV
22:30 imirkin_: ok
22:30 imirkin_: so erm ... from a nvidia gpu standpoint, is it HDMI? or DVI?
22:31 imirkin_: are these GT215+ gpu's, or earlier ones?
22:31 imirkin_: 210/8400gs came in GT218 version (although 8400GS was also G84 and G98). dunno about 9800GT offhand.
22:32 lachs0r: 9800gt should be g92
22:32 imirkin_: and probably without HDMI?
22:32 lachs0r: with hdmi
22:32 imirkin_: huh, ok
22:32 imirkin_: well, as it happens, i have a G92 plugged in at home
22:32 lachs0r: only the 8400gs doesn’t have hdmi
22:32 imirkin_: it has dual-dvi though
22:33 lachs0r: 03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)
22:34 lachs0r: indeed it stops if I pull the HDMI plug
22:35 imirkin_: so i dunno whose "fault" it is
22:35 lachs0r: I can try a different display
22:35 imirkin_: it feels like the HPD is constantly triggering
22:35 imirkin_: which would mean that we're not properly clearing somethign or ... something.
22:38 lachs0r: okay, no issues with a different display
22:41 lachs0r: so what can I do now?
22:41 imirkin_: crying is popular
22:41 imirkin_: you could run nouveau with nouveau.debug=disp=debug
22:41 imirkin_: and see a bit more of what's going on
22:42 imirkin_: you could also force the edid
22:42 lachs0r: I’d be fine with the latter :D
22:42 imirkin_: which should avoid at least some of the troubles
22:42 lachs0r: can you remind me how I can extract the EDID and force it?
22:43 imirkin_: you can get the edid from /sys/class/drm/cardN-conn/edid
22:43 imirkin_: and then you force it by doing ...
22:44 imirkin_: drm_kms_helper.edid_firmware=VGA-1:edid/your_edid.bin (or without the connector: bit of it)
22:45 lachs0r: okay. I assume it needs to be in the initrd, then?
22:46 imirkin_: it needs to be accessible when nouveau loads, i think.
22:46 lachs0r: alright I’ll just put it there
22:47 imirkin_: so ... depends how your setup is setup
22:47 lachs0r: (opensuse tumbleweed)
22:47 imirkin_: i make a point of not learning anything about crazy distro setups
22:47 lachs0r: wise choice
22:52 imirkin_: i know why distros use initrd's, but i dunno why people continue the practice with self-built kernels
22:55 lachs0r: well I’m not using self-built kernels, so… :D
22:55 imirkin_: ah
22:55 lachs0r: also, this still plays a role in LUKS setups with encrypted /boot I believe
22:58 lachs0r: (last time I used a self-built kernel was when I had a new laptop and the touchpad didn’t work… luckily only the firmware revision had to be added to the known ones for that device)
23:00 imirkin_: yeah, i have a static initrd for that
23:00 imirkin_: i never update it
23:19 lachs0r: well, forcing the EDID avoids the problem
23:20 imirkin_: yay
23:21 imirkin_: would be nice if we were better at handle such error cases
23:23 lachs0r: yeah, definitely. would also be nice if people wrote good display firmware :D
23:23 lachs0r: I only ran into this because I decided to recycle an old laptop display and put it on a tray inside an audio rack
23:24 lachs0r: no onboard graphics there and I only had old nvidia cards
23:27 lachs0r: where do I start if I want to try to fix this?
23:29 imirkin_: https://github.com/skeggsb/nouveau/tree/master/drm/nouveau/nvkm/engine/disp
23:29 lachs0r: (and thanks for the pointers)
23:29 imirkin_: it's all quite confusing
23:30 imirkin_: esp when you're not deeply familiar with how the pieces fit together
23:30 imirkin_: but ... even when you are.
23:30 lachs0r: that’s what I was afraid of
23:30 imirkin_: first thing is to figure out which thing is being dumb
23:31 imirkin_: focus on the G92 first
23:31 imirkin_: or ... probably doesn't matter
23:31 imirkin_: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/disp/nv50.c#L479
23:31 lachs0r: fwiw you can get those display controllers on aliexpress. I can’t find the exact one I got (mine was a little cheaper), but this looks very similar: https://www.aliexpress.com/item/HDMI-DVI-VGA-Audio-LCD-controller-board-work-for-15-6inch-B156XW02-LP156WH2-1366X768-LCD-panel/32816508767.html
23:31 imirkin_: this is where the supervisor interrupt comes in, i think with an HPD
23:31 imirkin_: (among other things)
23:32 imirkin_: of course the actual edid calls are elsewhere
23:32 lachs0r: (hm no, no dvi on mine. oh well)
23:33 imirkin_: hpd gets handled here https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/disp/conn.c#L33
23:33 imirkin_: the idea would be to enable enough debugging to see this stuff
23:34 imirkin_: you can just boot with nouveau.debug=debug
23:34 imirkin_: (without forcing the firmware0
23:34 imirkin_: er, edid
23:39 lachs0r: okay, taking notes. going to poke at this next time I feel like ripping out my toenails
23:46 imirkin_: there are funny interactions with nv50_display.c a few directory levels up too
23:46 imirkin_: it all starts to make sense when you get an appreciation for how incredibly complex getting a picture up on the screen is
23:47 imirkin_: but ... that comes after much failure in ones life :)
23:50 lachs0r: I’m used to it at this point. everybody gets video playback wrong, too (and hardware decoding causes nothing but trouble before you even get to that point)
23:51 imirkin_: at some point i need to get back to 12bpc hdmi...
23:57 lachs0r: btw, what happened to nvidia’s attempt to force their device memory allocator down our throats again? looked very much like “please implement this for us so we don’t have to change our driver model. we’ll even consider maybe throwing a crappy nouveau patch over the wall!” to me :)
23:57 imirkin_: i didn't look closely enough
23:57 imirkin_: i'm letting other more involved people evaluate it