00:14karolherbst: imirkin_: \o/ https://gist.githubusercontent.com/karolherbst/d2b6fbfacc8b48900bcdad58f48f87b2/raw/789883d792c1ae9e9177d09791d3b923dd87d870/gistfile1.txt
00:14karolherbst: it even makes sense
00:15imirkin: nice
00:15karolherbst: currently wondering if reusing pushbuf_decode makes sense
00:15karolherbst: but it has a lot of mmt stuff in it
00:15karolherbst: maybe it makes sense to extract the bits of the pushbuf format
00:19karolherbst: X_COUNT 0x100000 mhhh
00:20karolherbst: imirkin: do you agree that the copy in that pb is pretty broken?
00:20imirkin: i don't remember tbh
00:22karolherbst: heh.. this is wird
00:22karolherbst: so we have a rect of 0x200 x 0x200.. but X_COUNT is like 0x100000
00:24karolherbst: not even sure if the decoding is correct to be honest...
00:25karolherbst: matches nvc0_m2mf_transfer_rect though
00:25karolherbst: and I am debugging a m2m fail :)
00:26karolherbst: ehhh.. has to be nve4_m2mf_transfer_rect of course
00:33karolherbst: uhhh *sigh*
00:33karolherbst: yeah well.. that has to break of course
00:37karolherbst: yeah....
00:37karolherbst: imirkin: apparently the hw doesn't like if it you copy 100000x1 pixels into a 512x512 rect
00:37imirkin: yeah, it's a 16-bit value iirc
00:38imirkin: or ... 20-bit?
00:38karolherbst: yeah well..
00:38imirkin: annoying.
00:38karolherbst: even then
00:38karolherbst: 100000 > 512*512
00:38karolherbst: or... actually
00:39karolherbst: it's heh...
00:39imirkin: 0x40000
00:39imirkin: but it's copying a byte at a time, so *4
00:39karolherbst: ohh, right
00:39karolherbst: mhhh
00:40karolherbst: anyway, we get this from clover direclty
00:40imirkin: yeah, it needs to split these up i guess
00:40karolherbst: or it could reqest a 512*512 copy
00:41imirkin: or that.
00:41karolherbst: this entire clover is completly mis architectured anyway
00:41karolherbst: that copy is triggered from some destructor of a memory mapping
00:41karolherbst: why...
00:41karolherbst: just why
00:42imirkin: to sync the values back to the bo?
00:42imirkin: it's like a flush, presumably
00:42karolherbst: yeah.. kind of like that
00:42karolherbst: it's just... I tried to find what clover is doing before
00:42karolherbst: but I just couldn't find this
01:00karolherbst: imirkin: mhhhh... so clover calls into transfer_map with { size, 1, 1 }
01:00karolherbst: the question is.. should the state tracker not be dumb or should the driver be able to handle that
01:00imirkin: both? :)
01:02karolherbst: heh.. radeonsi would run into an assert here
01:02karolherbst: assert(box->x + box->width <= resource->width0);
01:02imirkin: why would that assert?
01:02imirkin: box->x is uint32
01:03karolherbst: box->wight is 0x100000
01:03karolherbst: -> is 0
01:03karolherbst: resource->width is 0x200
01:03karolherbst: soo....
01:03imirkin: oh
01:04imirkin: well this is meant to work with like 1d / buffer resources
01:04karolherbst: sure
01:04karolherbst: but now I look into CL images :)
01:04karolherbst: and I have a 0x200 x 0x200 image
01:04karolherbst: which the application wants to copy data into
18:38DanishGuy: Hey so I have a graphics card from my grandfathers old pc, if I recall right the codename for it is NVA3 (GT215), is that of any value to anyone?
18:58DanishGuy: or is it better to just throw out the graphics card?
18:58DanishGuy: welcome back maccraft123
18:58imirkin_: DanishGuy: do you know if it's the DDR5 or DDR3 variant?
18:59DanishGuy: imirkin_ anyway i can check that on it physically or do i need to boot it up to check?
19:00imirkin_: mmmmmmmmm
19:00imirkin_: not sure =/
19:00karolherbst: there might be a model or serial number which might help
19:00imirkin_: ah yeah, model number should do it
19:00imirkin_: in fact frequently the DDR3 vs DDR5 thing will be obvious from the model number itself
19:01maccraft123: imirkin_: hey
19:02maccraft123: im doing mcp78 coreboot ;)
19:02karolherbst: mhh, there are also DDR2 GT215... weird
19:02imirkin_: have fun!
19:03karolherbst: maccraft123: at least you don't have to deal with undocumented memory stuff
19:03maccraft123: karolherbst: undocumented?
19:03maccraft123: southbridge is undocumented too xD
19:03karolherbst: ufff
19:03maccraft123: karolherbst: what
19:04karolherbst: yeah.. no, memory is just always fun
19:04karolherbst: especially on GPUs
19:04karolherbst: but you don't have that issue with mcp78
19:04karolherbst: but I guess even coreboot still uses the GPU vbios to POSTing?
19:04karolherbst: *for
19:05maccraft123: karolherbst: no
19:05maccraft123: this is so wrong
19:05maccraft123: the only thing coreboot does with gpu vbios is to initialize the gpu itself
19:05karolherbst: right
19:05maccraft123: there is no "post" in coreboot
19:05maccraft123: it just initializez
19:05karolherbst: yeah well.. same thing
19:11DanishGuy: imirkin_says on the little sticker it is a geforce GT320 1GB DDR V/D HDMi
19:14DanishGuy: sorry it took a while i could not find my screwdriver
19:17RSpliet: In that case I'd say DDR3
19:17RSpliet: I mean, best way to tell is just boot a live linux distro, I bet nouveau'll tell you
19:18imirkin_: all the google search results say "ddr3"
19:18DanishGuy: oh yeah i meant to type ddr 3
19:18DanishGuy: thought i had
19:18DanishGuy: sorry i am a bit sleepy
19:18imirkin_: lol, no worries
19:19DanishGuy: anyway from what you are telling me i might as well cycle it
19:20imirkin_: yeah, unless you want to keep a spare
19:20RSpliet: They're great for displaying stuff
19:21DanishGuy: displaying? what do you mean?
19:22DanishGuy: also this is my grandfathers old pc it is either that or the motherboard that makes it take about 20 min to boot up
19:23imirkin_: a spare video card, that is
19:33DanishGuy: I think at that point i rather upgrade, i know some people might be happy to have a free spare part, but i am currently using a gtx 980, don't think i would be able to endure on the gt320
19:35imirkin_: hehe
19:35imirkin_: yeah, it's a bit of a difference
19:37DanishGuy: so I will pull out the old harddrives, clean them of their data and then use them elsewhere, there is quite a lot of storage on them, and then the rest will be recycled