06:36mardination: anyways now the arbiter, well dependent load is such an interesting construct, that it does not run if the dependent load gets from the dependee, same data as it had before in that register
06:37mardination: so to play with an arbiter, we make a vector register, that does POW and CMP, MIN , MAX or such functionality
06:40mardination: any of the cnoditionals would suite, the mentioned min/max , cmp and also the set functions of arb
06:40mardination: slt, sge and such famililies
07:03mardination: on shader spec 2.0 this translates into having, 16 conditionals that are async on that VLIW, 16 ALUs used from 64 so it leaves 48 arbitary intexable opcodes
07:20jchorin: Hello everybody, I would like to know if using nvagetbios from envytools only for reading the BIOS harms in any way my GPU card, when VFIO is using it?
07:57mardination: now cause i am entirely wired and have no ciggies , i am again brainfreezing under meds, i can not remember what logic i planned for register write and readbacks
08:05mardination: it needs either one or four registers reserved four register state too, depending on how many instructions one needs to be inflight, max 4 for sm spec 2.0
08:06mardination: this is some also some conditional logic, if the opcode included read registers previously written than read if not than not
08:26mardination: neighboring lanes can be accessed with derivatives only, which are probably slow
08:36mardination: ok so POW and MAX for this
08:55mardination: gotta leave, offhand i am very weak in mathematics , I have always been and i do not have my laptop with me an no math book at sight
09:00mardination: the thing is -- in modern programming everything that i read has been done with bitwise operations, most math aside of that i can not offhand remember
12:49thum: is there a GPU that can drive 4x 4k @60Hz with nouveau (no gaming, so 3D perfomance isn't that important)?
12:50karolherbst: thum: uff, I don't even think X handles that all that well right now
12:50karolherbst: there were some fixes in this regard
12:51karolherbst: no idea how well that would work with nouveau to be honest as memory bandwith is a serious issue here
12:51karolherbst: thum: if there is a kepler card which can drive those displays then maybe
12:53thum: karolherbst: thanks
12:55thum: I suppose those cards would require binary firmware, right?
12:56karolherbst: not kepler
12:56karolherbst: but to reclock memory we would need it on newer cards
12:56thum: karolherbst: any hint on what card I should look into (https://nouveau.freedesktop.org/wiki/CodeNames/#NVE0)?
12:56karolherbst: kepler is just the latest gen we can reclock memory
12:57thum: I see, so Kepler is kind of the end of the sweet spot so to speak
12:57karolherbst: thum: well, if you want to buy a new one then I would kind of prefer an AMD one if you want a relible open source driver, if you want some fun, then you can go with nouveau :p
12:57karolherbst: thum: normally the 780 ti is quite capable
12:58thum: well, newer AMD cards require binary firmware. So that's one point for nouveau with kepler.
12:58thum:doesn't mind a little bit of fun
13:00karolherbst: thum: well, we require binary firmware for video acceleration, but only because nobody figured out how to write one ourselves
13:01karolherbst: anyhow, I am sure that nobody ever tested 4x4k on nouveau
13:01karolherbst: and I can imagine that this won't work all that well generally
13:09taliptako: hello i'm having problems with Android Emulator when run with nouveau driver
13:10taliptako: Error is Segmentation fault (core dumped)
13:10taliptako: thats all i got
13:11karolherbst: taliptako: ohh, I think that's due to multithreading issues sadly :/
13:11karolherbst: I have some WIP patches to fix that, still needs more fixes to work with android
13:13taliptako: ah thats bad i thought its something i can fix
13:26karolherbst: it's a lot of work sadly, but most of the stuff is already done, just have to fix some annoying remaining issues :/
13:28taliptako: okay thank you for you work :)
16:59Gigadoc2: huh, seems like the matrix-freenode bridge is broken
17:00Gigadoc2: Anyway, hi, and what I wanted to ask:
17:00Gigadoc2: Can someone give me a pointer as to what the current status of HDMI audio on Optimus notebooks is?
17:00Gigadoc2: I found https://bugs.freedesktop.org/show_bug.cgi?id=75985, but that was a few months ago and I am not sure if anything happened since then?
17:07karolherbst: Gigadoc2: let me guess, the audio device doesn't show up?
17:07Gigadoc2: karolherbst: well, yes and no:
17:08karolherbst: so you have to rescan first and then it shows up or what is the issue you are seeing?
17:08Gigadoc2: It does not show up by default, but I can make it show up. But if I do this, the Nvidia card will not power down anymore, until I remove the audio device again
17:08karolherbst: mhh, well because the audio device is in use by something I guess
17:09karolherbst: or runpm isn't enabled on it
17:09Gigadoc2: Rescan alone does not work, I have to flip a certain pci bit
17:09karolherbst: Lekensteyn: I think that's your domain more or less?
17:09karolherbst: Gigadoc2: ahh, 0x488, right?
17:09Gigadoc2: So, the thing that keeps it awake is pulseaudio, of course. But I do have PM enabled, and that Is why I am asking about the status :)
17:09Gigadoc2: karolherbst: yes
17:10karolherbst: normally we enable that bit... but I think it wasn't completly reliable
17:10karolherbst: Gigadoc2: what laptop is that?
17:11karolherbst: and what kernel are you running?
17:12Gigadoc2: Thinkpad W530, 5.0.5-arch1-1-ARCH
17:13Gigadoc2: The card is a quadro k1000m (i did not want it, but it was not optional), and the external connectors (VGA, miniDP) are hard wired to it
17:13Gigadoc2: I am wondering in particular about the power management when the audio PCI function is "enabled"
17:13Gigadoc2: if that causes the card to never power down again, I would be quite contend with not having the function visible :D
17:14karolherbst: Gigadoc2: I'd assume that runpm is disabled for the audio device
17:14Gigadoc2: For enabling it, I was thinking about a "setpci" in early initramfs, before the nouveau module gets loaded
17:14Gigadoc2: karolherbst: I *think* I enabled it, but I am not sure what the correct switch to look for is
17:15karolherbst: cat /sys/bus/pci/devices/0000\:01\:01.0/power/runtime_status
17:15Gigadoc2: Ok, I will test this very soon and report back
17:15karolherbst: if the audio device is indeed at 01:01
17:15Gigadoc2: currently the device is hidden
17:15Gigadoc2: yes, it is
17:16karolherbst: ohh, actually wrong file
17:16karolherbst: not runtime_status
17:16Gigadoc2: I have to unload noveau to enable it (or is that info wrong?), so I have to close down my sway first :)
17:16Gigadoc2: control should be "on" for pm, right?
17:16karolherbst: control has to contain auto
17:17Gigadoc2: oh, ok
17:17karolherbst: you can echo auto into that file
17:17karolherbst: and see if that makes the gpu suspend again
17:46Gigadoc2: karolherbst: Ok, that was it. I did *not* have runtime pm enabled (I am constantly confusing "on" with "auto"...), and when enabling it, the card does power down as it should
17:46Gigadoc2: Sorry about that :(
17:46Gigadoc2: Though now I'd like to ask whether I should try to report a quirk for this notebook in particular or just try a setpci workaround
17:47karolherbst: no worries, but we need a better way on how to turn the audio device on
17:47karolherbst: mhhh, not quite sure
17:47karolherbst: Lekensteyn might be able to help here
17:50Gigadoc2: btw, now that I have the device on and with power management, I think I'll try out whether HDMI audo now actually works
17:51Gigadoc2: and, just fyi, I was running the proprietary nvidia driver not a long time ago, and it also had the audio function missing
17:51karolherbst: Gigadoc2: thing is, we have to set that pci bit before devices are scanned inside the kernel... so that's a bit tricky to get right. And I don't really know much about that part
17:52Lyude: karolherbst: we should probably make sure that we're actually using device links for the audio device
17:52Lyude: although I'd hope that we would be already
17:52karolherbst: Lyude: well, the issue is, as far as I can tell is, that by default on boot the audio device is disabled
17:52karolherbst: or rather the multi-func bit is disabled on the GPU
17:53Gigadoc2: Since the proprietary driver had the same problem, I also think it is disabled on boot
17:53Lyude: What is the exact issue here? Reading up it looks they were wondering if using the audio device on the nvidia GPU would keep the whole GPU awake
17:53karolherbst: Lyude: no, we solved that one alreay
17:53karolherbst: runpm was disabled for the audio device
17:54karolherbst: issue is, no audio device on boot by default
17:54Lyude: ahh, hm, I think there were some patches that went upstream recently related to this
17:54karolherbst: setpci 0x488 ... on the nv gpu + rescan brings the audio device online :)
17:54Lyude: hm, actually
17:54Lyude: they should be in the 5.0 kernel
17:54Lyude: so I don't think that's relate
17:55Lyude: So what exactly do they have to scan before it appears?
17:55Lyude: also note: I do actually have a W530 in proximity
17:55karolherbst: Lyude: the pcie bus
17:55karolherbst: Lyude: on the gpu there is this 0x88488 reg
17:56karolherbst: bit 0x02000000 has to be enabled
17:56karolherbst: then the audio device will show up on a rescan
17:56karolherbst: 0x88488 == pci.0x488
17:56Gigadoc2: I am doing:
17:56Gigadoc2: setpci -s 01:00.0 0x488.l=0x2000000:0x2000000
17:56Gigadoc2: #close all wayland and x sessions
17:57Gigadoc2: modprobe -r nouveau
17:57Gigadoc2: echo 1 > /sys/bus/pci/devices/0000:01:00.0/remove
17:57karolherbst: Gigadoc2: do you really have to remove nouveau?
17:57Gigadoc2: echo 1 > /sys/bus/pci/devices/0000:00:01.0/rescan
17:57Lyude: so the thing I want to make sure first is that this isn't an issue with the component bind timeout
17:57Gigadoc2: karolherbst: If i don't, all graphics freeze
17:57Lyude: With sound devices and DRM devices, they keep eachother awake through device links and also handle probing for one another through device links
17:57Lyude: so that if one comes up before the other they're -supposed- to still register with eachother
17:58Lyude: can you send me a plain kernel log from a clean boot where the nvidia sound device doesn't appear on it's own?
17:58Gigadoc2: Though I have not yet tried just closing down all wayland sessions and then remove it without removing the module
17:58karolherbst: Lyude: how is the device link stuff retrieved btw?
17:58Gigadoc2: Maybe this is just a problem of GDM and sway
17:59Lyude: karolherbst: it's not, we should be adding it for any audio device that gets detected on the gpu
17:59karolherbst: Lyude: well, how do we detect if an audio device is present then? vbios?
17:59Lyude: because the audio device and the gpu are two different logical devices to the kernel
17:59Lyude: karolherbst: nvidia specific implementation stuff for that I don't know, sorry
17:59karolherbst: I see
17:59Lyude: I would assume pretty much any hdmi should have audio though
17:59Gigadoc2: Lyude: what constitues a clean boot?
18:00Lyude: Gigadoc2: just turn on the machine and run dmesg :p
18:00Gigadoc2: Well, then I can retrieve the logs from the current boot
18:00Lyude: don't scan for the audio device yourself yet
18:00Lyude: that will probably do
18:02Lyude: oh, hm
18:02Lyude: I don't see any mention of device_link in nouveau's src
18:02Lyude: that's probably got something to do with it
18:03Lyude: Gigadoc2: also, what happens if you reboot with nouveau blacklisted, load the kernel modules for the sound device, then load nouveau manually with modprobe afterwards (you'll probably have to do this in fbcon)
18:10Gigadoc2: Lyude: https://cables.five-ey.es/700pwnscms672eup19hb7orf/dmesg
18:11Gigadoc2: I'll reboot like this now, see what happens
18:11Gigadoc2: Also, I completely forgot and this might be very relevant: I have the iommu enabled. I could also try not enabling it and see what happens then
18:12Lyude: Worth a shot but I don't think it'll make much difference
18:12karolherbst: Gigadoc2: can you do "setpci -s 01:00.0 0x488.l" ?
18:13karolherbst: just wondering if it returns 0 or something else
18:13karolherbst: well, on a clean before without having set the value in the first place
18:16karolherbst: Lyude: do you know the command on how to set that reg inside grub?
18:16karolherbst: ohh, same syntax
18:17Lyude: no, sorry
18:17Lyude: btw-trying to figure out where we create the audio device in nouveau atm
18:17karolherbst: Lyude: we only enable the multi-func bit on runpm resume
18:17karolherbst: so that the subdevices appear
18:17karolherbst: and I think that's the culprit here
18:18Lyude: karolherbst: link to the source?
18:18karolherbst: it's just disabled by default and nothing turns it on
18:18karolherbst: "nvif_mask(&device->object, 0x088488, (1 << 25), (1 << 25));"
18:18Lyude: I do believe we also need device links here as well though
18:18Lyude: see drivers/gpu/drm/i915/intel_audio.c
18:19Lyude: karolherbst: so, the other thing I'm wondering - is this a problem on other machines as well?
18:19karolherbst: I think it's quite rare
18:19Gigadoc2: Lyude: Booted with blacklisted nouveau, confirmed the nouveau module is not running (though I can still run a UI on the intel card). But what actually is the kernel module for the nvidia audio function?^^
18:19karolherbst: but I've heard about that issue before
18:19Lyude: as in the multi-func mmio bit gets left on by most vbioses?
18:19karolherbst: Gigadoc2: snd_hda_codec_hdmi
18:20karolherbst: Lyude: yeah
18:20karolherbst: Lyude: well, it's actually a pci register
18:20karolherbst: so you don't need mmio
18:20Lyude: karolherbst: oh-interesting
18:20karolherbst: Gigadoc2: try adding a new grub entry
18:20karolherbst: and add this to it: 'setpci -s 01:00.0 0x488.l=0x2000000:0x2000000'
18:20karolherbst: maybe do this instead:
18:20karolherbst: setpci -s "01:00.0" 0x488.l=0x2000000
18:20Lyude: karolherbst: I will come up with some quick fixes for the device link stuff as well so this can get fixed all at once
18:21karolherbst: not 100% sure on the syntax
18:21Gigadoc2: karolherbst: the setpci returns 0 (00000000), on a clean boot without nouveau
18:21karolherbst: Lyude: yeah.. but I don't think the device link will help us here as there is no pci device yet
18:21Lyude: karolherbst: oh yeah I'm aware
18:21karolherbst: ahh okay
18:21karolherbst: Gigadoc2: okay, then try that grub setpci thing
18:21karolherbst: I am sure that will fix it in a more cleaner way, still a workaround
18:22Gigadoc2: karolherbst: That will be complicated, I am booting efistubs with hand-rolled secure boot^^
18:22karolherbst: Gigadoc2: ohh, no bootloader then?
18:22Gigadoc2: well, sd-boot, which is just an efi application though
18:23karolherbst: no idea how to do that before the kernel loads
18:23karolherbst: except grub
18:23Gigadoc2: an efi application, possibly? But I have no Idea how to write that
18:23karolherbst: well, grub would be one :p
18:24Lyude: karolherbst: suggestion: have them boot into a kernel with nouveau and all of the snd drivers blacklisted, change the pci register you need to change, kexec into another kernel without blacklisting everything
18:24karolherbst: I also used efistub in the past, because I didn't need an initramfs
18:24karolherbst: Gigadoc2: wait.. you do secure boot without full disc encryption?
18:24Gigadoc2: hm, right. Inserting grub into the boot chain would be easy, except for the configuration of grub itself^^
18:25karolherbst: that's ... pointless
18:25Gigadoc2: karolherbst: I do have fde
18:25karolherbst: ohm... how?
18:25Gigadoc2: I have the initramfs rolled into the efi image, signed as a whole
18:25karolherbst: ohh, I see
18:25karolherbst: yeah, that would work then
18:25Gigadoc2: with the systemd efi loader (which just unpacks the initramfs and launches the kernel efistub, AFAIK)
18:25karolherbst: totally forgot about this
18:26Gigadoc2: I am willing to turn off secure boot for testing, or sign the grub binary, I just have to figure out how to manually configure grub then :)
18:26karolherbst: yeah... that will be a bit of fun I guess
18:26Gigadoc2: Lyude: with nouveau blacklisted, the audio function still does not turn up, and loading the module seems to do nothing
18:27Gigadoc2: loading the snd-hda-codec-hdmi that is
18:27Lyude: load novueau after loading it as well
18:27Lyude: we're concerned about seeing what happens if snd_hda_codec_hdmi loads before nouveau
18:27Lyude: But they do both need to be loaded for things to work properly
18:27Gigadoc2: I just did, but same thing unfortunately
18:27karolherbst: Lyude: well the issue here is, that the audio device is still a subdevice of the GPU :/
18:27Lyude: karolherbst: hence device links!
18:28Lyude: in addition to this pci magic
18:28karolherbst: sure, but the GPU decides if there are sub devices or not
18:28karolherbst: we need to do that pci magic somewhere
18:28karolherbst: device pci quirk?
18:28karolherbst: turn it on for all nvidia gpus?
18:28karolherbst: no idea how well that would work in general
18:29karolherbst: collect gpus with that issue and add the sub ids?
18:29karolherbst: no idea what to prefer here
18:29karolherbst: Gigadoc2: I guess you compile your own kernel?
18:29Gigadoc2: karolherbst: No, stock arch for now
18:29karolherbst: a kernel patch might help
18:30Gigadoc2: I am willing to test it :D
18:30karolherbst: Lyude: a DECLARE_PCI_FIXUP_CLASS_EARLY?
18:31Gigadoc2: The EFI shell can not be used to set the magic bits, can it?
18:31karolherbst: we have a patch already somewhere
18:32Lyude: karolherbst: why can't we set this register later?
18:32karolherbst: Lyude: we have something already... quirk_gpu_hda
18:32karolherbst: it does the device linking stuff
18:33karolherbst: but .. on the audio device
18:33karolherbst: Lyude: we have to set it before probing the bus actually
18:33karolherbst: if it gets reprobed, fine to do it later
18:34karolherbst: but I think Lekensteyn would know about the status here as I am sure he write some patches for it at some point
18:38karolherbst: Lyude: worst case, we tell nvidia to deal with that, as it affects their driver as well :p
18:39Lyude: i trust nvidia with nothing
18:39karolherbst: yeah.. me neither
18:41karolherbst: Lyude: but I kind of get the feeling we need something earlier than _EARLY
18:42karolherbst: something like _PROBE and if a quirk was run, the devices are reprobed
18:42karolherbst: but I don't know much about what happens after/before the quirk kinds
18:43Lyude: i don't think that's really the right solution... if we can set the register later, then it's a matter of just not binding the sound drivers until nouveau has actually probed and enabled what's needed for the PCI sound device
18:43Lyude: which basically amounts to teaching the sound driver how to wait until nouveau says it's OK to start probing
18:44Lyude: which should likely happen after the PCI register writes you mentioned
18:44karolherbst: mhh but drivers should bind to newly appearing devices automatically, no?
18:44karolherbst: but anyway, I don't know much about this part of the kernel anyway
18:45Lyude: karolherbst: sort of? I'm not quite sure on that part, I haven't really touched the hda sound stuff either
18:45karolherbst: because we could enable multi-func, and just probe for new devices
18:45karolherbst: and maybe that's all we have to do?
18:46karolherbst: airlied might know that kind of stuff as well
18:46Lyude: karolherbst: let me get this straight btw: the PCI device doesn't come up in lspci until we've done the pci scan, right?
18:47karolherbst: and enable multi-func on the gpu of course
18:47Lyude: also I am suddenly starting to remember how the probing stuff works, I -think-
18:48Lyude: iirc, userspace checks for pci-ids and searches for modules that say they handle said PCI-IDs. If the kernel doesn't see the PCI-ID for the sound card here, then yeah it's likely that adding it later wouldn't do anything because something needs to request that the snd modules get loaded and thus-trigger a reprobe. I think
18:48Lyude: this is all off the top of my head so I may be wrong :)
18:48karolherbst: ohh, yeah, might be that udev does that stuff at runtime
18:52Gigadoc2: karolherbst: completely off topic, but how do you run a secure boot setup _without_ rolling the initrd into the efi binary? How do you prevent an attacker from changing out the initrd or command line parameters? Or can GRUB verify the signature of it's configuration or something like that?
18:56Lyude: grub is the thing that's signed for EFI
18:57Lyude: not the kernel
18:57Lyude: at least in that setup
18:57Lyude: iirc it goes secure boot shim (e.g. grub) → kernel signed with some signature that grub verifies iirc?
18:58ajax: the grub executable contains the pubkey corresponding to the (builder of the) kernel it will deign to load
18:58ajax: and then that kernel enforces module signing
18:58ajax: (again iirc)
18:58Lyude: ahhhh, so I had most of it right then it sounds like
19:12karolherbst: Gigadoc2: you sign it
19:24mardination: but the VLIW case where i have no hw code, the problem is not in the instructions, this is clear to me how to do it, but issue is I do not know again how it schedules, how many warps max in flight, and how many max warps per some units
19:24Gigadoc2: ajax, karolherbst: won't the initrd userland and the cmdline be unverified then?
19:25karolherbst: Gigadoc2: howso?
19:25mardination: and attilagpu has a lot of info, but i have not cleared it out yet from there
19:25mardination: in my mental model
19:25karolherbst: Gigadoc2: grub is signed
19:25karolherbst: and verified by the key stored inside your uefi
19:25karolherbst: grub verifies that the initramfs and the kernel is signed
19:25karolherbst: by the key stored inside grub
19:26Gigadoc2: OK, I did not know that grub could verify anything besides the kernel
19:27airlied: karolherbst, Lyude : I think it's a delibeate decision by bios manufactures to hide the audio device
19:27karolherbst: airlied: why would they want to do something like that?
19:27Gigadoc2: Though, does it verify the cmdline, or it's own configuration
19:28airlied: karolherbst: there was some windows messes up workaround
19:29airlied: I think we'd just have to quirk mf mode early and it should all work out
19:29karolherbst: airlied: uff :/ anyway, the question would be, how can we change the pci config value and get the kernel to reprobe for devices after that?
19:29karolherbst: I thought any of the pci quriks run after probing generally
19:29airlied: change it early :)
19:29karolherbst: uhm.. all
19:29airlied: I think we can reprobe after quirks, I'd have to dig
19:30mardination: https://github.com/attila-gpu/attila-sim/blob/master/src/sim/VectorShader/VectorShaderFetch.h lines 152to156 relevant and https://github.com/attila-gpu/attila-sim/blob/a64b57240b4e10dc4df7f21eff0232b28df09532/src/bgpu/bGPUx1.ini 220-238
19:31airlied: karolherbst: arch/x86/pci/fixup.c I thnik can do it
19:32airlied: I think early fixups happen before
19:32mardination: it says 240 threads maximum on fragment shader, 128 can be active, so it is probably 16warps and 8 active per 4pixel shaders
19:34karolherbst: airlied: ohh, maybe. worth trying out
19:34ajax: Gigadoc2: i think there end up being some cmdline parameters that the kernel refuses to honor if secure-booted, but otherwise i don't understand why you would need to verify the kcmdline
19:35ajax: refuses[*] - if you're running with the secure boot patch we're using, which upstream apparently still hates iirc
19:41mardination: i have like not a bit clue where i am digging on pre terascale 2 archs at least and nv34 did the warp/pixel vector that of 32threads dual scheduled existed there or wavefront that of 64 on r300-r500 etc. absolutely nothing mentioned on the web anymore
19:53Gigadoc2: ajax: I dislike the patch too, tbh: On one hand, most modules or user space looking at the cmdline don't expect the cmdline to be set by an attacker, so there is probably some way of turning of security measures or opening vulnerabilities with the cmdline now or some time in the future. On the other hand, the patch does not allow you to choose the restricted options and their values without bulding the kernel yourself and hand-rolling the
19:53Gigadoc2: secure boot yourself (which is especially annoying if you did not even choose to secure boot yourself, but the vendor forces you to and doesn't allow replacement of the PK)
19:53Gigadoc2: Instead, just signing the cmline seems like a way saner option to me
19:53karolherbst: Gigadoc2: and how do you decide which parameter is safe to set and which not?
19:54karolherbst: there are some parameters you want to be able to change
19:54Gigadoc2: karolherbst: exactly, i don't :D I consider every parameter as potentially dangerous if it can be set by an outsider
19:54karolherbst: just signing the whole thing is reducing the ability to debug the kernel
19:54karolherbst: there are tons of debugging flags to increase verbosity
19:54karolherbst: especially usefull if the screen in front of you is the only output you get
19:54Gigadoc2: But then you sign it yourself from the running, and thus you can change it easily
19:54Gigadoc2: *running system
19:55karolherbst: and if the system never runs because it didn't work in the first place?
19:55karolherbst: you try to install, but kernel crashes
19:57karolherbst: anyway, increaseing the verbosity of kmsg isn't anything we want to prevent even with secure boot
19:58karolherbst: allthough.. you could change the cmdline without physical access
19:59Gigadoc2: ok, that is indeed a problem, how do you allow the user to turn off verification (apart from disabling secure boot itself) whithout re-enabling an attacker to do the same
20:00Gigadoc2: considering that, the patch makes a lot more sense, though I still dislike that it will force users who cannot disable or modify secure boot into the restricted options
20:00karolherbst: Gigadoc2: you do that inside the uefi, no?
20:00karolherbst: if an attacker can get to it, you are screwed anyway
20:00karolherbst: aka physical access == you are screwed
20:01Gigadoc2: yes, secure boot only works if the firmware menu is secured itself. I was thinking about a possibility to allow users with forced secure boot to somehow disable verification by the bootloader/linux
20:01Gigadoc2: well, you would need to open the notebook, but then it is easy :D
20:01karolherbst: bad idea I guess
20:02karolherbst: well, physical access is just something where you have lost already
20:02karolherbst: no point in thinking too much about how to prevent such attacks
20:02Gigadoc2: yes, indeed
20:03Gigadoc2: Though I am thinking about storing a secret in the tpm that identifies the machine to me as a user, before I enter the disk encryption passphrase
20:03Gigadoc2: that would raise the amount of work to be done, as just replacing the device will not work^^
20:03karolherbst: yeah.. as long as it's nothing you spend days on, it's fine to make physical attacks harder
20:03karolherbst: like full disc encryption
20:04karolherbst: it's quite cheap to enable, makes it a lot harder to attack
20:04Gigadoc2: It's only academic anyway, I don't think anybody will target me with a physical attack
20:04karolherbst: Gigadoc2: heh, what about if you give the disc away or something
20:04karolherbst: or the laptop
20:04Gigadoc2: But the patch set mentioned worries me, as it does take away configuration options from people with unsolicited secure boot
20:05Gigadoc2: If i give away the notebook itself, there are conveniently placed spi connectors soldered to the firmware flash below the touchpad
20:05Gigadoc2: it would only take seconds to overwrite my firmware :D
20:06karolherbst: Gigadoc2: no, I meant after you don't need it anymore
20:06karolherbst: because you have a new one or something
20:06Gigadoc2: oh, right, good point
20:06karolherbst: ecure formatting isn't all that secure, but usually that works out alright, just takes a while
20:07Gigadoc2: but, knowing me, i will never give away the working ssds :D
20:07karolherbst: throwing away the key is faster :p
20:07Gigadoc2: i will find a use, and if it is in a 1ghz thin client playing firewall
20:11mardination: it is probably me who is too stupid, expect to read it out soon, frankly there are simd4 and simd16 units
20:26Gigadoc2: I'll see tomorrow (or maybe the day after) that I get the grub PCI hack working and whether that is sufficient
20:42mardination: got it finally. so r600 has 4pixel shader threads, threadgroup=64, vectorlength=64 vectoraluwidth=16 .. r300 4pixelshaders and 4 16 4 respectively
21:30Lyude: Anyone know what the difference between an i2c pad and an i2c bus is on a nvidia GPU?
21:33airlied: pad usually just means the pair of gpios
21:33airlied: don't think there is much distinction
21:33Lyude: ahh, so they both can be DDC lines?
21:34airlied: do the explicitly refer to one thing as pad and one as bus?
21:34Lyude: nvkm seems to
21:36Lyude: Looks like the only i2c related thing that exposes a struct i2c_algorithm is the bus, so I'm going to guess that's the only one I need to make return -EIO while the GPU is asleep
21:36airlied: yeah pads are the lowlevel hw, bus is higher level constuct
21:36Lyude: also seems a bus itself can have a pad
21:37Lyude: mm, that makes sense
21:38karolherbst: Lyude: please keep in mind that one i2c bus is locked down and I don't know if we don't expose it
21:39Lyude: karolherbst: pardon?
21:39karolherbst: one of the i2c busses can't be used
21:39Lyude: note: I am taking away userspace access to i2c stuff when the GPU is suspended, i'm not adding anything :)
21:39karolherbst: yeah, I am just saying that in case you are wondering why one i2c bus behaves differently
21:40karolherbst: since maxwell2 one of them is locked down and can only be access by signed firmware running on the PMU
21:40Lyude: since airlied pointed out while there's usecases for userspace access to i2c busses, none of them really apply to when there's no monitors turned on
21:40Lyude: karolherbst: ahhh, alright
21:40karolherbst: nvidia also behaves quite oddly with those
21:41karolherbst: they expose it.. but as long as there is no "expected" user, they are kind of disabled
21:41karolherbst: like if you poll with nvidia-smi every second, you are free to use them
21:41karolherbst: if not, you aren't
21:41karolherbst: might be due to the same reasons, so userspace does something with them and nvidia only allows it, if that use case is currently there
21:59Lyude: hm, that's new: https://paste.fedoraproject.org/paste/4izYmVG48q12tvrbw5WwIQ just got this while trying to reload nouveau
22:15mardination: it is very interesting, i was so bad at maths always, but it looks like to me things are doable.
22:16mardination: found any last bits about VLIWs
22:18mardination: anyhow to get into business of some sort is quite complex or earn anything there, just still the hobby stuff.
22:25mardination: i have couple of old cards, i am just intending to start to implement this stuff on older cards first, so if it bricks which should not happen though, than does not matter much
22:40mardination: in my opinion , those easy victories or solutions should be taken on, actual graphics programming i do not want to dive into, too subjective and too complex, best to get is a retarded mental stalkers, talking who is crazy and crap that is not tolerable by such outsiders
22:57mardination: nouveaus 3d engine programmer was cristoph bumiller aka calim, who said not genuinly those days that he is quite disgusted about this shit, which seems genuine now, since he really somewhere gone, i think all should bit chill down even when performing some real work or whatever
22:58mardination: you actually do not want to go through a bad brainchemistry and cause problems, this can not be beaten later anymore
23:12mardination: anyhow in attila gpu and wikipedia everything is still explained, srteam core or shader array is composed up to 16 alus each executing 5vliw instructions maximum, this stream core is given also four texture units, and includes stream elements which is akin to one vliw instruction
23:12mardination: they also say on real vliw 5-6 six alus of the 16 can execute simultanously
23:14mardination: so on r300 for instance there is 4alus per one stream core and also one pixel shader coincidely
23:15mardination: and four stream cores grand total
23:26mardination: envytools perhaps somewhere also described it, but i was not able to find.
23:28mardination: did not look longer time into those docs, but i am tired, and will go to sleep.