14:34 hakzsam: mupuf_, Hey, I RE'd lot of HW events on gf108 this w-e but I really need VT-d for multi-pass events because they are very painful... https://github.com/hakzsam/re-pcounter-tools/blob/master/hwdocs/pcounter/gf100/gf108.rst
14:34 mupuf_: hakzsam: oh, my new laptop has support for it
14:35 mupuf_: that was unexpected given that it is an i5
14:38 hakzsam: mupuf_, oh, you could install qemu-kvm and do the process for me :P
14:38 mupuf_: ;)
14:39 mupuf_: I found a flat but I still live in a youth hostel, so not the best way for me to be available and ready to work
14:39 hakzsam: I'll try to buy a REator this month, btw
14:39 mupuf_: I should be able to settle down in the next 2 weeks
14:39 mupuf_: ah ah
14:39 hakzsam: good news forthe flat
14:40 mupuf_: yep! Hopefully, I'll be able to have 100MB+ internet connection. Time will tell ;)
14:40 mupuf_: anyway, going to bed, I need to arrive early at work tomorrow
14:40 hakzsam: great :)
14:40 mupuf_: take care, all of you.
14:40 mupuf_: (Helsinki has been nothing short of amazing so far)
14:41 hakzsam: thanks, you too, see you mupuf_
16:29 imirkin: what's the 'access' argument to nouveau_bo_wait supposed to signify? i can never get that straight...
16:30 skeggsb: the type of access you want to do from the *cpu*
16:30 imirkin: basically i want to wait for the gpu to finish writing to a BO... what do i ask for? BO_RD? or BO_WR?
16:30 imirkin: ok, so BO_RD. i don't actually want to access it from the cpu though... although perhaps i should, and avoid this nonsense.
16:31 imirkin: this is nv50_query.c:nv50_query_pushbuf_submit
16:31 skeggsb: it's intended for cpu/gpu sync, if you want to read from the cpu, it'll only wait for gpu writes to finish
16:31 skeggsb: if you want to write, it'll wait for all gpu activity to finish
16:31 imirkin: hm ok
20:44 night199uk: hey
20:44 night199uk: anyone know if andy from nvidia has any plans to release docs on the ‘BIT’ tables in the vbios?
20:44 night199uk: i just pinged an email to opengpudocs to ask
20:44 night199uk: wondering if anyone already had anything outside of what’s documented in code in envytools/nouveau
20:45 night199uk: i’m currently working through some code that uses the ‘d’ (seems to = ‘DisplayPort’ table)
20:46 night199uk: heh
20:47 night199uk: Delivery to the following recipient failed permanently:
20:47 night199uk: open-gpu-doc@nvidia.com
20:47 night199uk: 550 #5.1.0 Address rejected.
20:47 night199uk: :-/
20:47 night199uk: says it all
20:48 imirkin: there's a followup -- that's the wrong address
20:48 imirkin: gpu-public-documentation@nvidia.com
20:49 imirkin: you can look at how nouveau parses the various tables... there's the 'nvbios' tool in envytools, as well as the kernel source... they're not 100% in sync, unfortunately
20:49 night199uk: oh, thanks
20:49 night199uk: imirkin: yup, that’s what i’ve done so far
20:49 night199uk: in this case i’m looking at the ‘d’ table
20:49 night199uk: which is in neither it seems
20:49 imirkin: what information are you trying to find out?
20:50 night199uk: well, its the other way round really
20:50 night199uk: i’m working on the hackintosh nvidia efi drivers
20:50 night199uk: i have the efi drivers that parse the ‘d’ table
20:50 imirkin: dp.c: if (!bit_entry(bios, 'd', &d)) {
20:51 night199uk: oh duh - my bad
20:51 night199uk: let me go double check
20:51 night199uk: that looks like nouveau?
20:51 imirkin: yeah, it's nouveau
20:51 night199uk: is that recent?
20:51 night199uk: tx
20:51 night199uk: my sources are a bit out of date
20:51 imirkin: nope, not really
20:51 imirkin: subdev/bios/dp.c
20:51 skeggsb: what do you want to know about it?
20:52 night199uk: let me go look at the sources first and see if that answers my questions
20:52 night199uk: :-)
20:52 night199uk: save you some time
20:52 skeggsb: we parse/use pretty much all of it
20:52 night199uk: i’m trying to interpret what i see in the EFI driver
20:52 night199uk: cool
20:52 night199uk: yeah, i guess this is very important for displayport support
20:53 skeggsb: yes, it's the link control scripts and other related stuff
20:53 night199uk: basically the Nvidia Mac EFI drivers generate a bunch of NVRAM variables by parsing the various tables in the card
20:53 night199uk: NVCAP/display-cfg etc
20:53 night199uk: that indicate to the Mac the ‘layout’ of the nvidias etc
20:54 night199uk: i’m trying to reverse engineer that generation
21:22 Manoa: hi everyone
21:24 Manoa: I've been reading around about the recent developments in the performance of games running on wine in linux with some patches that make d3d9 games run faster than their native OpenGL equivalents (albeit not by much) which is a staggering achievement by itself
21:26 Manoa: I have a linux box with a GT 210 and I am looking forward to checking out what it can do when 3.19 gets out, this box isn't much of a multimedia machine it mostly used as a server, but when the graphics stack is there im sure many things will become possible which were not before
21:29 Manoa: I also have a "monster" machine for gaming but that one is not running linux at the moment, I used to be a hardcore gamer and I am hoping that in the future I can use linux as my gaming platform
21:29 imirkin: Manoa: atm you will get the best performance out of the nvidia blob drivers
21:31 Manoa: for GT 210 or for the monster ?
21:31 imirkin: for pretty much everything
21:31 imirkin: depending which card the GT210 is, 3.19 may gain manual reclocking support for it
21:32 imirkin: which could improve things
21:33 Manoa: I prefer manual really
21:33 Manoa: this monster needs rebooting every week or so because the nvidia windows drivers reclocking is so broken
21:34 Manoa: right now my monster card is stuck at 400 mhz and there is nothing I can do about it but reboot
21:34 Manoa: that is something I dislike very much
21:35 Manoa: but from watching the video today it seems that nvidia has the same problem of freezing clocks at load that you have
21:36 Leftmost: imirkin, I may give ARB_copy_image a shot.
21:37 imirkin: Leftmost: cool. so the complexity there is the swizzling
21:37 imirkin: Leftmost: basically you might have two textures with internal format of GL_RGBA8, but one could be backed by PIPE_FORMAT_RGBA8 and the other by PIPE_FORMAT_BGRA8
21:37 imirkin: Leftmost: so you need to "make that right" when copying
21:38 imirkin: ARB_texture_view gets away with not dealing with this bs because it only works on textures allocated through glTexStorage, so some modicum of sanity can be applied, but with glTexImage it tries to pull all sorts of clever shenanigans that end up in these crazy situations
21:39 imirkin: Leftmost: however you could just use something like the blit path if there's no funny business like that, and then do something terrible to deal with that annoying situation
21:40 Leftmost: Okay, I can keep that in mind.
21:40 imirkin: er, actually the blit path would probably handle that. but it won't handle reinterpreting R16 as R8G8 or whatever. and then there's the question of what happens when it's R32 -> BGRA8 vs R32 -> RGBA8. good times.
21:42 Leftmost: I may have a lot of questions as I go along, but is there a function in particular that would be useful for getting a sense of what I need to touch to implement this?
21:44 imirkin: not really. you may want to ask questions in #dri-devel btw
21:53 Leftmost: Laptop shopping right now and considering picking up a T440p with Optimus. May be a while before I could hack on that at all, though.
21:53 imirkin: Leftmost: meh, get it to work with llvmpipe, that's probably enough to have it work on most drivers
21:55 Leftmost: I meant hacking on the laptop's card and/or PRIME.
21:55 Leftmost: I have a couple systems around with cards that can run gallium drivers.
21:56 imirkin: cool