00:00mupuf_: skeggsb: http://cgit.freedesktop.org/~mperes/nouveau/commit/?id=7acc888229184ffff2c89a7eab41e2a3de3073be
00:06skeggsb: mupuf_: i'll pick it up shortly, thanks
00:07mupuf_: skeggsb: thanks...
00:07skeggsb: my concern now is that all the testing of it working is pretty useless :P
00:07mupuf_: skeggsb: I think karol did not use my patch but his own fixed version....
00:07skeggsb: ah, alright
00:08skeggsb: in any case, it's not like this is code that we hit by default, given that pretty much every bit of pm stuff we have is partially broken/incomplete - the code additions are still a good step towards fixing that :)
00:09mupuf_: I did not manage to test the patch again, just checked the REing
00:09mupuf_: I can try to reclock the gm107 though
00:09mupuf_: that should work .... ish
00:10skeggsb: imirkin: yeah, i discussed the partial-ness of the headers in person while i was in sc, and expressed a *strong* desire to either have all #define'd or all hex, not a eye-burning mix of both
01:23karolherbst: mupuf_: kubast2 has the same problem with his GPU :O
01:23mupuf_: karolherbst: the voltage?
01:23karolherbst: also only 0 in the header
01:24karolherbst: just saw it now
01:25karolherbst: mupuf_: okay
01:25mupuf_: karolherbst: you can push this kind of fix directly. If you need an ack, just said the patch on irc
01:26karolherbst: just wanted a review for this, otherwise I would have pushed it :p
01:27karolherbst: I am really sure of these two more bits though
01:27karolherbst: I think I somehow understand the table now
01:27karolherbst: if the header is decleared fully
01:27karolherbst: you don't need any entries at all
01:27karolherbst: if the header isn't complete, you use the entries
01:28mupuf_: yes, sounds like it
01:28mupuf_: but we need to check what takes precedence
01:29karolherbst: sometimes the header is parsed wrong though
01:29karolherbst: like this: -- Mode GPIO, Base voltage 825000 µV, voltage step -12500 µV, acceptable range [825000, 1212500] µV --
01:29karolherbst: the step shouldn't be negative obviously
01:32karolherbst: mupuf_: okay, only two kepler vbios with the 0 values in the header in the repo
01:32mupuf_: karolherbst: time to issue another call for vbioses?
01:33karolherbst: well, not for this issue
01:33karolherbst: I think I got it already :D
01:33mupuf_: or add vbioses from here: https://www.techpowerup.com/vgabios/
01:33mupuf_: but they seem to be extracted in a weird way
01:33karolherbst: I think they are used for flashing
01:33mupuf_:would rather avoid receiving hundreds of email with vbioses
01:34mupuf_: it took me an entire week of work last time to sort through them
01:34karolherbst: are all maxwell cards pwm based?
01:34mupuf_: that is a good question
01:34mupuf_: I do not have sufficient evidence to even consider the question
01:34mupuf_: don't want to be biased
01:36karolherbst: seems like nvd* cards are the first one with version 0x50
01:37karolherbst: or rather nvd7
01:38karolherbst: mupuf_: any complaints? https://github.com/karolherbst/nouveau/commit/a23cdce8aef69a95851f200ebd414d4a01a20e84.patch
01:39mupuf_: yes, we do not make a patch for nouveau until we actually know what is going on
01:39mupuf_: I know it is frustrating though
01:40mupuf_: look at the situation with the power sensor
01:40mupuf_: I though I had everything covered on the vbios side ... and I was wrong
01:41karolherbst: I see
01:44karolherbst: mupuf_: so in fact we could fake a vbios with such a table and see what the blob is doing
01:47vita_cell: I must to give gtx650 to my friend back, so, I will install gtx770, will I have some problem with already installed patched nouveau?
01:48karolherbst: the 770 should just work
01:48vita_cell: nothing to modify?
01:48karolherbst: can you do some 0f testing with it though?
01:49vita_cell: I will do, when I install it
01:49karolherbst: vita_cell: this branch is actually the stuff for linux 4.4, and there is a nice patch for gddr5 memory
01:49vita_cell: I will get geforce 7300gt too, if you want to extract vbios or something
01:49karolherbst: so you would most likely get problems with the stock module
01:49vita_cell: and I will get gtx460oc too
01:50karolherbst: well I don't care much about a 7300gt myself
01:50karolherbst: and 460 is fermi, mhh
01:50karolherbst: that might come in handy later maybe, don't know if I do stuff for fermi myself
01:51vita_cell: I tested gtx650 fully reclocked (0f) with piano test(some minutes) and playing games, and I think that it stable
01:51vita_cell: tested with glmark2 too
01:51vita_cell: works very well
01:51karolherbst: very good
01:52karolherbst: mupuf_: wanna update the kernel on reator at some point?
01:52vita_cell: so, worked well "for me"
01:52karolherbst: mupuf_: not important for me right now, I just noticed there is still the 4.2 rc kernel
01:52vita_cell: Do you think that 7300gt it is wasting time?
01:53karolherbst: difficult question
01:53vita_cell: when I tryed gtx460, this one doesn't work well, and I only could to put my monitor with 99hz
01:53karolherbst: vita_cell: ahh right
01:54karolherbst: there are some patches for that
01:54karlmag: karolherbst: not sure if you saw (or answered) my question regarding vbios the other day. I tested a couple of methods to extract (as descriped on the DumpingVideoBios page on the wiki); "using /sys" and the "cat /sys/.../vbios.rom" Ended up with differently sized files in those to dumps. Is that to be expected?
01:54karolherbst: should be better with my branch though
01:54vita_cell: 7300gt it is a no muscle card(weak)
01:54karolherbst: karlmag: sadly yes. I always cat the vbios.rom file from debugfs
01:54karolherbst: and this works
01:55karolherbst: vita_cell: imirkin has done some stuff for the pixel clock on fermi cards
01:55karlmag: karolherbst: ok.. Well.. I may be able to extract vbioses for various cards, but possibly not using the preferred method though.
01:55karolherbst: vita_cell: you should check that 460 card with your installed module and see if its better
01:55vita_cell: this stuff will be included in newer nouveau?
01:55karolherbst: karlmag: well, vbios files are only usefull when there is an actual issue
01:55karolherbst: vita_cell: with 4.4, yes
01:55karlmag: yeah, you did mention that.
01:56karlmag: I wouldn't know, really :-P
01:56karolherbst: vita_cell: ohh wait
01:56karolherbst: vita_cell: there are patches for 4.3 already
01:56vita_cell: I using 4.3
01:57karolherbst: but I think they are for higher resolutions
01:57karolherbst: but you have the 4.4 changes already
01:57karolherbst: so just try out the fermi card
01:57vita_cell: 1920x1080 144hz
01:57karolherbst: and report back if it does more than 99hz now
01:57karolherbst: with fermi?
01:57karolherbst: I mean with the gtx 460
01:58vita_cell: I using 1920x1080 144hz, with 460 1920x1080 99hz(more hz gives me a grey screen)
01:59karolherbst: vita_cell: yeah, just try the 460 card out now with your newely installed nouveau.ko file and check if that changes anything
01:59vita_cell: I will test, but I will have gtx460 back tomorrow or this night, and I will test what you want
02:00karolherbst: vita_cell: ohh wait, as it seems the patch isn't there yet
02:00karolherbst: yeah well anyway, if you get probelms with that, ask imirkin he did some work for this recently and if you get not the stuff which is actualy supported by the card, he might help
02:00vita_cell: only Kepler and gt2xx cards can be reclocked?
02:02RSpliet: and some older cards... but mileage may vary
02:03RSpliet: should work for most G200s, expect it to work for many G94s, G96 and G98 with GDDR3
02:03vita_cell: yes, gddr3 better for these cards
02:03RSpliet: mostly because... I don't have a DDR2 card to work with :-P
02:05vita_cell: something to do with gt520?
02:05RSpliet: that's Fermi
02:05RSpliet: see http://nouveau.freedesktop.org/wiki/CodeNames/
02:05vita_cell: yes, I have it my favourites
02:06RSpliet: no worries :-)
04:45karolherbst: mupuf: which model was your maxwell card again?
04:46karolherbst: mupuf: anyway, the card requiring more than 1.2V seems to be right
04:46mupuf: GM107? Isn;t there only one?
04:47karolherbst: 7 for desktop though
04:47karolherbst: 745, 750, 750 Ti
04:47karolherbst: and some quadros
04:48mupuf: it is a 750, not sure if it is TI or not
04:49mupuf: check the vbios
04:49mupuf: it should tell
04:50karolherbst: doesn't matter, I just try to figure out if a voltage above 1.2V is used by the blob or not
04:50karolherbst: for that I just read about maxwell overclocking a bit, because voltage is like always mentioned there :D
04:52karolherbst: it seems your card really is capped at 1.2V
04:52karolherbst: even overclockers never go above 1.2V with a 750
04:52karolherbst: but around 1.18V
04:52karolherbst: or something
04:53karolherbst: pmoreau has/had a maxwell with 1.275V max pwm value in the repo
04:53karolherbst: so I think this part is right
04:53karolherbst: and the nv124 also hash 1.275V
05:14karolherbst: mupuf: the thing is, it all makes somehow sense in the vbios, except that the voltage map table has entries higher than supported by the voltage table :/
05:20mupuf: which is fine
05:20mupuf: it just means you can never get to them
05:20vita_cell: vbios it is a binary?
05:21vita_cell: so, you can't modify it and reflash to the GPU
05:22mupuf: we sure can
05:22mupuf: we don't even need to flash the gpu
05:22mupuf: we have cool tools :p
05:22vita_cell: all you doing is see how vbios.rom works?
05:22mupuf: well, we have a tool to dump the vbios
05:22mupuf: and we use it to improve our understanding ... and add more support for it in the tool
05:22mupuf: nvbios is the name
05:23vita_cell: I give gtx650 vbios to karol
05:23mupuf: nvafakebios is to upload the bios to the card ... without flashing it
05:23mupuf: and nvagetbios is to get the vbios
05:23mupuf: that's it
05:23vita_cell: I think that it is very difficul to modify something in binary file
05:24vita_cell: I can understand nothin inside a binary file
05:24mupuf: nvafakebios allows you to change whatever value you wan
05:25vita_cell: how I can run it (already compiled and installed nouveau-master) and see what is?
05:26vita_cell: sudo nvafakebios?
05:33karolherbst: mupuf: so then the cstep => voltage map entry thing might be wrong then?
05:36pmoreau: karolherbst: Talking about the Titan X I guess? I don't think I uploaded my 960's VBIOS yet.
05:36karolherbst: pmoreau: think so
05:36karolherbst: but there are also entries higher then voltage table
05:37karolherbst: pwm max: 1275000
05:37karolherbst: map table: 1281250
05:37pmoreau: There are a few tables that aren't parsed correctly / uses an unknown version in that VBIOS.
05:38karolherbst: yeah I know, I try to figure out what exactly is wrong
05:39pmoreau: I'll try to get the missing information to push GM120 into envytools (and fix the chipset declaration order) before leaving this evening.
06:35karolherbst: mupuf: pmoreau maxwell card: base voltage 600090 µV
06:35karolherbst: this looks somehow.. odd
06:50mupuf: karolherbst: does not sound too crzy
06:52karolherbst: sometimes I simply can't get why somebody thinks 600090 is better than 600000 :D
06:55RSpliet: I doubt whether hardware is accurate enough to provide voltages at a 90µV granularity
07:45mwk: there, now we're all properly doomed
07:57karolherbst: vita_cell: first rule on IRC: if something burns, just speak it out :p
07:58karolherbst: just don't poke people
07:58karolherbst: looks good
07:59karolherbst: try out 0a and 0f
07:59vita_cell: this is 770
07:59karolherbst: mupuf: it would be interessting to know what happens if you go above the max value in the pwm, does the voltage decreases agian or just stay at max?
07:59vita_cell: 0e and 0f looks the same
07:59karolherbst: yeah, they mostly are the same
08:00mupuf: karolherbst: super simple to check
08:00mupuf: nvawatch d610
08:00karolherbst: mhh right
08:00mupuf: nvawatch -t d610
08:00karolherbst: what is d610? tempereature?
08:00mupuf: no, it is the GPIO status
08:01mupuf: well, GPIO 0's status
08:01karolherbst: nvawatch just prints a lot of values
08:01mupuf: yes, now put the duty to 100%
08:01mupuf: it will stop changing
08:01karolherbst: right :D
08:01mupuf: and when you go above div, you will see
08:02karolherbst: well, can anything happen with my gpu? usually it operates below 1V
08:03karolherbst: or is it fine as long as I keep a eye on the temperature?
08:04vita_cell: 0a works fine AC: core 1032 MHz memory 1620 MHz
08:13vita_cell: no changes beetwen 0e and 0f, core gets 1032mhz, this is normal?
08:14mupuf: karolherbst: don't worry about this kind of stuff, it is fine as long as it does not get too warm
08:14imirkin: vita_cell: core should have gone up to 1215... i guess more voltage fail.
08:14imirkin: vita_cell: but more importantly... no crash?
08:15vita_cell: yes, karolherbst modified nouveau.ko, low voltage for my gtx650, but this is not enoguht for 1215mhz
08:16vita_cell: no crash with all levels, gtx650 or gtx770, I had no crashes
08:16vita_cell: but, 770 it is hotter
08:17karolherbst: imirkin: well there are voltage issues with some kepler cards
08:18karolherbst: for some voltages there are no match for the gpio combinations
08:19imirkin: karolherbst: aka "voltage fail" :)
08:20vita_cell: is here some command to se how much memory I have? (gddr5)
08:23imirkin: dmesg | grep RAM
08:24karolherbst: mupuf: :D
08:24karolherbst: it stops to change with 0x5c
08:27karolherbst: mupuf: okay, above div means, max value
08:27karolherbst: 0x68 had a similiar power consumption as 0x60
08:27karolherbst: and 0x58 had a much smaller one
08:31vita_cell: [ 3.917332] nouveau 0000:01:00.0: DRM: VRAM: 4096 MiB
08:32mupuf: karolherbst: why don't you check with the gpio? That is the only good way of checking
08:32karolherbst: mupuf: as I said, it stops changing after 0x5c
08:32mupuf: that is fun
08:35karolherbst: but the power consumption is still increasing after 0x5c
08:36karolherbst: maybe the value changes too fast for the mmio space?
08:36RSpliet: *is perfectly aligned with MMIO read-out speed :-P
08:37RSpliet: maybe you can get PDAEMON to gather some histogrammy statistics
08:37karolherbst: as if I care enough about that to actually do that
08:37RSpliet: just a wild and wacky idea
08:37karolherbst: yeah I know
08:38karolherbst: just wanted to check what happens above the div value
08:38karolherbst: and as it seems ti clamps to div
08:38karolherbst: mupuf: anyway that is somehow good news, because the core will run stable, bad news, because some cards might be hotter
08:38karolherbst: like yours
08:40vita_cell: I don't know if it is much difference, but I am on i7 2600 on z77 PCIe3.0 board, I broke my i5-3570k
08:40vita_cell: so my board supports PCIe3.0, but my i7-2600 doesnt
08:41karolherbst: doesn't matter here
08:41karolherbst: there are just some issues with voltage in nouveau and this has to be tackled at some point
08:43vita_cell: I think that my gtx770 hasn't enough voltage, but not sure
08:44vita_cell: it needs a bit more I think
08:44vita_cell: GPU Base Clock : 1058 MHz and GPU Boost Clock : 1110 MHz
08:44vita_cell: Asus gtx770 4gb gddr5
08:45karolherbst: vita_cell: I won't be able to help you with that, because the problem is far bigger than the other one, and I won't be able to fix it anyway with my own gpu
08:45vita_cell: no problem karol, you helped me a lot already
08:52karolherbst: mupuf: what needs to be done for this one voltage issue? (the 0 header thingy)
08:53vita_cell: it is normal some coil-whine when benchmarking or playing games right?
08:53vita_cell: I got louder coil-whine using gtx970
09:09nullbyte_: why nouveau currnet doesnt support geforce gtx 970?
09:10imirkin: nullbyte_: GM20x (GTX 950+) requires "secure" firmware to be uploaded. we have neither the firmware, nor the process for uploading it.
09:12nullbyte_: where can i get that firmware
09:12mwk: nullbyte_: basically the GM20x GPUs are locked up like a damn iphone
09:12mwk: and well
09:12karolherbst: mwk: as weaks as?
09:12nullbyte_: hmm.. i need official drivers support...
09:12mwk: if you have a lot of time, skills, and patience, you could probably extract them out of the blob... but then you'd also have to write acceleration support for nouveau
09:13nullbyte_: yes understand you
09:13mwk: karolherbst: good question.
09:13mwk: I should take a look some day
09:13mwk: but there's a lot of scary crypto
09:14mwk: I have no idea how the current model works, but as of GT21x the security was quite watertight
09:14RSpliet: imirkin: didn't gnurou publish several (unsatisfactory) patches to implement firmware upload?
09:14mwk: except GT21x only locked you out of the video decoding crypto keys, not the whole damn GPU
09:14RSpliet: or were they incomplete?
09:15imirkin: RSpliet: for GM20B, yes. but insufficient for desktop. and still no firmware.
09:15RSpliet:glares at gnurou
09:15RSpliet: ... again >_>
09:16karolherbst: I am pretty sure it would be really easy to do plain text attacks on the key, and maybe that's the reason they don't publish the firmware :D
09:16mwk: karolherbst: uh, no
09:16mwk: I really do mean watertight
09:16mwk: plain text attacks on AES128 are not exactly easy
09:16karolherbst: no algorithm is watertight
09:16mwk: besides, the firmware is not encrypted, it's just authenticated
09:17karolherbst: but I am no crypto expert either, so mhh
09:17karolherbst: mwk: ohh so there is only a signature to it?
09:17mwk: karolherbst: want to have a shot at cracking AES? be my guest
09:17mwk: with custom IV, I think
09:18karolherbst: they really use cbc for that?
09:19karolherbst: no, My mistake
09:19mwk: disclaimer: I haven't looked at GM20x, I'm just saying how it works on the secure falcons up to GM107
09:19mwk: but there's almost certainly no difference
09:21karolherbst: mwk: I am pretty sure they use 256 bit by now
09:22mwk: karolherbst: any reason for that?
09:22karolherbst: 128 becomes rather weak by now
09:22mwk: that'd require redesigning most of the falcon crypto system
09:22mwk: uh, no
09:22mwk: 128 for symmetric cipher is quite strong
09:23karolherbst: yeah, but for AES there are attacks to reduce it to 126 bits :D
09:23karolherbst: not much, but well
09:23mwk: the 256/192 variants actually have *worse* attacks
09:24RSpliet: given the compute power of say... a Titan X, how much time would it take to break it?
09:25mwk: oh, just a few billion years
09:25RSpliet: that's long enough I reckon...
09:25imirkin: perhaps we can use a future gpu to crack the encryption on an older gpu ;)
09:26mwk: oh wait, no
09:26mwk: a few billion years would be more like a 72 bits key
09:26mwk: a 128 bits key would be... no, just don't bother
09:26karolherbst: mwk: why?
09:26karolherbst: I am pretty sure a few billions was for 126 bit keys
09:27mwk: karolherbst: ok, so quite honestly
09:27mwk: you're *not* going to crack AES, just forget it
09:27karolherbst: I know
09:27mwk: if you do, I'd be more worried about patching all my machines and regenerating all my certificates and all my everything than a damn GPU firmware
09:28karolherbst: and I would fear of my life
09:28mwk: you may, however, crack it the good old iphone way
09:28mwk: security bugs in software, or hardware for that matter, are not unheard of
09:28karolherbst: that was the way I was thinking
09:29karolherbst: mwk: what happens when invalid stuff is put unto those falcons?
09:29mwk: you have an advantage here, AES-CMAC is based on symmetric cipher, so the key you need to sign stuff *is actually on the GPU*
09:29mwk: worst case, you buy an electron microscope. and you're in business
09:29mwk: what's a few million dollars for a free driver, after all
09:30karolherbst: doesn't have universities have stuff like that?
09:30mwk: *shrug* maybe
09:30RSpliet: if you write a paper in return on the nasty attacks you can now do on a GPU...
09:30RSpliet: I'm sure CERN would be more than happy to help in exchange of your soul
09:31mwk: karolherbst: oh, and if you do that, be sure to send me a photo, I'd gladly learn *exactly* how some GPU units work
09:32mwk: and as for your question
09:32mwk: when invalid stuff is put unto these falcons, they (surprise surprise) lock up and don't talk to you any more
09:33karolherbst: I am sure you can teach them a leason and force them to talk to you again :p
09:33mwk: you can reset them via the good old PMC_ENABLE register, but this causes them to wipe all sensitive data from data memory, code memory, whatever
09:43mlankhorst: ooh fun with pwms :D
09:43mlankhorst: driving my led strip
10:51karolherbst: I should do something with my to do list
10:52imirkin_: you should do it ;)
10:52imirkin_: or add to trello
10:52karolherbst: well three entries are stuff I just wait to be merged :/
10:53karolherbst: four actually
10:53imirkin_: ping early and often
10:53imirkin_: eventually ben will either merge or kickban
10:54karolherbst: I have to write a bot for that though
10:54karolherbst: he is lucky that I am not here while he works :/
10:55imirkin_: i think kick-banning the bot will weigh a lot less on his conscience :)
10:55karolherbst: and I should get my tor stuff working again :/
10:56karolherbst: ohh right
10:56karolherbst: I know what I could do
10:56karolherbst: handle stuff right while the gpu is off
10:56karolherbst: but for that
10:56karolherbst: my card needs to go off reliable
10:58karolherbst: imirkin_: what is the difference between nouveau_pmops_suspend and nouveau_pmops_runtime_suspend ?
10:58imirkin_: my guess is that one is for suspend and the other is for runtime suspend
10:58imirkin_: just a theory :)
10:58imirkin_: (suspend = suspend-to-ram/suspend-to-disk. runtime suspend = acpi poweroff of gpu)
10:59karolherbst: well I could just lookup what the dev_pm_ops struct does :D
11:01karolherbst: I think nouveau missuses runtime_suspend a bit
11:01karolherbst: maybe it is fine though
11:01karolherbst: okay, anyway
11:06karolherbst: imirkin_: nouveau_pmops_runtime_suspend doesn't get called here
11:06karolherbst: but I get pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, hda bios codec supported
11:06karolherbst: and VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG0.PEGP handle
11:07imirkin_: karolherbst: do you have runpm=0? :)
11:07imirkin_: o well
11:07karolherbst: I've added runpm=1 to be sure
11:08imirkin_: karolherbst: btw, do you need to retest stuff with this change? http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=a539a9802af38236101de6ae8d9b827544de0f72
11:08karolherbst: orr wait
11:09karolherbst: ohhh mhhh weird
11:09karolherbst: because it worked for me or not?
11:11karolherbst: you are right
11:11karolherbst: it actually change something
11:11karolherbst: ahhhh that explains stuff :D
11:52imirkin_: karolherbst: didn't you say you had problems with undervoltage?
11:52imirkin_: karolherbst: perhaps this is why :)
11:55vesim_: when video decoding will be available for VP6?
11:55imirkin_: vesim_: send patches :)
11:55imirkin_: afaik no one's even looked at it
11:56imirkin_: beyond determining that it was a rather different engine
11:58vesim_: closed drivers sucks so much...
12:05imirkin_: open one's ain't exactly great on maxwell either
12:07vesim_: but chromium and cinnamon doesn't support closed :P
12:14karolherbst: imirkin_: yeah I figured
12:56moochmcgee: Hey, how would you guys feel about an nVidia shader simulator?
12:57moochmcgee: Basically, it would run shaders meant for a certain type of nvidia card through emulation
12:57moochmcgee: allowing easy testing of new compiler features
12:57moochmcgee: of course, this would have to render via software on the CPU.
13:01imirkin_: moochmcgee: positively ;) any debug tools are better than no debug tools
13:01imirkin_: my current approach to this is staring really hard at the source shader and compiled shader
13:01imirkin_: until either my eyes bleed or the bug pops out, whichever comes first
13:02glennk: afaik several such projects exist
13:02moochmcgee: i figured i'd start with the tesla isa
13:02moochmcgee: glennk: mind pointing me to one of them?
13:03moochmcgee: tesla is probably easier than anything earlier or later, at least!
13:03moochmcgee: since it's only one isa, and it's simpler than the later isas
13:03imirkin_: not really
13:03imirkin_: tesla has 4 diff variants
13:03glennk: https://www.multi2sim.org/ would be one of them
13:03imirkin_: vertex, geometry, fragment, and compute
13:03imirkin_: they all have slightly different encodings
13:04imirkin_: at least for the 4-byte ops
13:04moochmcgee: i thought tesla was unified shaders?
13:04imirkin_: what do you want me to say
13:04imirkin_: i know how it works, not the marketing around it :p
13:04imirkin_: also g and maybe s access only from compute
13:10moochmcgee: is it possible to just plain hook a specific mmio space and just outright fully simulate a tesla card?
13:12moochmcgee: this would make it possible to test the entire driver at once without even using a real card!
13:13imirkin_: you could certainly create a fake pci device that redirects all mmio to userspace...
13:14moochmcgee: how would i go about doing this?
13:16imirkin_: no easy way if that's what you mean
13:16imirkin_: actually probably creating the device in qemu might be the easiest thing to do
13:17mwk: moochmcgee: emulating a GPU, while a fun enterprise, would take more time to write than full-featured nouveau...
13:18moochmcgee: mwk: well, at least i can use it to preserve the hardware
13:18moochmcgee: btw, can you help me find the win95 driver sanity check?
13:18mwk: what sanity check?
13:18moochmcgee: i'm having lots of trouble getting my emulation to pass it
13:19moochmcgee: According to the DOSBox-X author, most Win9x drivers have sanity checks in them.
13:19moochmcgee: And for some reason, the driver is rejecting my emulation.
13:19imirkin_: mwk: he's making a riva128 emulator
13:19moochmcgee: oh yeah
13:19moochmcgee: i thought he knew that though
13:19mwk: yeah, I know
13:19moochmcgee: i also plan to emulate the riva tnt
13:20mwk: riva128/tnt are perhaps at the edge of what is possible to emulate by a single-man team...
13:21moochmcgee: well, i've got vesa working
13:21moochmcgee: high res quake never looked so slow!
13:21moochmcgee: anyway, i'm thinking my problems are in my rma code
13:23moochmcgee: as win9x drivers like to seemingly write to crtc reg 38h many times in a row without any rma access between them, i think there's at least some problems there
13:23mwk: hmm, wasn't that I2C...
13:23moochmcgee: now, out of necessity, my rma code deals in writing one byte at a time
13:23moochmcgee: it's rma
13:24moochmcgee: you told me yourself how this register worked.
13:24mwk: ah right, rma
13:30moochmcgee: what's wrong?
13:36mwk: moochmcgee: honestly, it's been a long time since I looked at that
13:37mwk: there's not much implemented there obviously, something like mmiotrace would be helpful to figure out where the driver gives up
13:37mwk: but one important thing about the emulator...
13:37mwk: when handling MMIO, do *not* think in terms of bytes
13:37moochmcgee: well, i kinda have to
13:37moochmcgee: that's how the emulator was designed
13:37mwk: it's a PCI bus, and you have to deal with it in terms of 32-bit words, perhaps with byte enables
13:38mwk: I'm sorry, that's not how nv3 works
13:39mwk: there are registers where reads have side effects, writes have side effects, ...
13:39mwk: you may get something working by artificially assembling 4 byte accesses into one word access for internal use
13:40mwk: but you have to have the code organised in terms of words
13:40mwk: and the only exceptions to that are VRAM access and VGA regs
13:42moochmcgee: but the bios reads mmio regs 16 bits at a time!
13:48mwk: the bios uses RMA window
13:49karolherbst: imirkin_: okay, seems to be better now
13:49imirkin_: karolherbst: cool :)
13:49mwk: which assembles the 8-bit or 16-bit accesses into internal 32-bit accesses
13:49imirkin_: rma = rmw?
13:49mwk: Real Mode Access
13:49karolherbst: imirkin_: but if you think about it: my card runs pretty stable at 0.84V already, and the blob uses 0.98V
13:49imirkin_: oh. not at all then ;)
13:49karolherbst: I am actually surprised how well that worked so far
14:01moochmcgee: mwk: alright, i guess i'll rewrite it to work that way
14:04moochmcgee: basically, it'll handle 8-bit and 16-bit reads by reading the whole word
14:05moochmcgee: and it'll handle 8-bit and 16-bit writes by reading the word first, and then doing a masked write
15:22imirkin_: happy to do the same for gf100+... need sample traces though
15:26pmoreau: imirkin_: What did your patch change? I still seem to get the same output for compute from demmt
15:26imirkin_: pmoreau: it should print the shader, for example
15:27imirkin_: pmoreau: and decoded TSC/TIC data
15:27hakzsam-: pmoreau, search for CP_START_ID
15:27hakzsam-: and enjoy! :)
15:28pmoreau: Ah!!! :-)
15:31hakzsam-: imirkin_, I'll try to send you a trace for gf100+ tomorrow
20:45imirkin: well... i've been able to repro the VA leak
20:45imirkin: bin/teximage-colors --benchmark GL_RGBA8 -fbo -auto -- does 2x as many maps as unmaps.
20:46imirkin: hm should probably double-check it's not the test leaking...
21:31imirkin: urgh. ok, that's a problem specific to these tests that do lots of texture transfers and no actual drawing =/
22:52imirkin: wtf is shaders/orbital_explorer.shader_test ? and why is it crashing my compiler :) [and more importantly, what did i change since 11.0...]
23:00imirkin: wtf! since when does st_glsl_to_tgsi emit RET ops??