--- Log opened Втр Июн 27 00:00:37 2006
00:13 -!- termitor [n=proutage@sab57-1-82-231-109-37.fbx.proxad.net] has joined #nouveau
00:24 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
00:24 < darktama> Lumag: a dump from a clean Xorg didn't reveal the object init either.. you can see RAMHT being modified, but that's it
00:25 < Lumag> damn.
00:25 < darktama> yup
00:26 < darktama> I suspected it might be the kernel module doing it at insmod time, but nvclock dumps of RAMIN before/after insmod show no changes either..
00:36 < Lumag> That's strange. DDX uses RAMIN for objects on nv4x
00:37 < darktama> indeed, which is why it makes no sense (to me) why renouveau can't read it properly
00:37 < darktama> the only other possibility I've thought of is that there's a RAMIN offset reg, like the RAMHT one
00:45 < Lumag> maybe
01:55 -!- stringfellow [n=stringfe@dsl220-96-100.fastxdsl.nl] has quit [Remote closed the connection]
02:00 -!- stringfellow [n=stringfe@dsl220-96-100.fastxdsl.nl] has joined #nouveau
02:12 -!- `Duke` [n=gnu@ANantes-251-1-98-42.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:45 -!- tango_ [n=tex_vim@host-84-220-198-98.cust-adsl.tiscali.it] has quit ["Leaving"]
03:42 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
04:48 -!- termitor [n=proutage@sab57-1-82-231-109-37.fbx.proxad.net] has quit [Remote closed the connection]
05:08 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
11:40 -!- stalkerg [n=stalkerg@ppp83-237-250-97.pppoe.mtu-net.ru] has joined #nouveau
11:44 < stalkerg> hello all
11:59 -!- Duke` [n=gnu@ANantes-251-1-98-42.w86-203.abo.wanadoo.fr] has joined #nouveau
12:00 -!- stalkerg [n=stalkerg@ppp83-237-250-97.pppoe.mtu-net.ru] has quit [Remote closed the connection]
12:00 -!- EdB [n=EdB@ARennes-251-1-65-217.w86-195.abo.wanadoo.fr] has joined #nouveau
13:42 -!- shenki [n=shenki@ppp147-73.lns3.adl2.internode.on.net] has quit ["Cya!"]
15:02 -!- EdB [n=EdB@ARennes-251-1-65-217.w86-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
15:06 < marcheu> darktama: I was wondering if RAMTH is put at another place on 256MB cards. on my 128MB nv44 it's at the usual place
15:06 < darktama> hmm, actually that could be a good explanation
15:07 < darktama> that nv40 dump of yours, is that 256MB too?
15:07 < marcheu> hmm
15:07 < marcheu> I think so
15:07 < marcheu> it's a very high end 6800
15:07 < marcheu> the fastest one actually, so I expect it to have 256
15:08 < marcheu> how does it behave ?
15:08 < marcheu> is the RAMHT at the right place ?
15:08 < darktama> RAMHT seems fine, it's the instances of the objects that don't seem to be where they should be
15:09 < marcheu> oh yeah, it's full of 0x0 too
15:10 < darktama> yup, as is the G70 dump
15:11 < marcheu> yeah, both are 256 I just checked
15:12 < marcheu> I wonder if I could have access to a 256 MB nv30
15:12 < darktama> are there any?
15:12 < darktama> yup, there is
15:13 < marcheu> yeah, memory is cheap
15:15 < marcheu> and you didn't fnd anything by brute forcing the 700000 area ?
15:16 < marcheu> my guess is something along the lines of "since we have plenty of video memory, let's put the instance table in there"
15:16 < darktama> there were a few possibilities (locations that contained 0xXXXX4097).. but, Lumag's code to compare RAMIN before/after object creation only show the hash table being changed
15:43 < darktama> on a related topic, what do we need from the object creation interface?  my current thought is the app tells the drm a class, dma in/out/notifier, and a few flags fields (corresponding to nv_flagsX in the 2D driver) and the drm returns the handle
15:47 < darktama> actually, the DRM may not have to assign handles.. the hashing algorithm and the "context" in the hash table seem to contain the FIFO number the object belongs to
15:52 < marcheu> we simply need to be able to request creation of secure objects
15:52 < marcheu> and I think we should assign handles from DRM, assigning from user space would require to use a lock anyway to avoid races
15:54 < darktama> why would there need to be a lock?
15:55 < marcheu> when you generate the handle, you don't want to collide
15:55 < darktama> I don't think it can, multiple apps here use the 0xbeef3097 at the same time
15:56 < darktama> that's what I was saying about the FIFO number the object belongs to being stored in the "context" part of the hash table
16:13 < darktama> hmm, nv_dma.c doesn't mention where the channel bits are on nv40
16:19 < darktama> marcheu: this is with 3 glxgears running, would you say that those top bits are the channel? http://rafb.net/paste/results/z33fQS95.html
16:29 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
16:31 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
16:54 < marcheu> I still think we should return handles. that way we could blacklist broken objects from the drm
16:56 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
16:59 < marcheu> hmm, so higher 9 bits would be the channel
16:59 < darktama> hmm, fair enough :)
17:00 < darktama> I'm not sure if it's all of the top 9 bits, I doubt it though - as far as we know there's not that many FIFOs
17:00 < marcheu> btw
17:02 < marcheu> (one second, looking at some notes)
17:02 < darktama> that's cool, fighting with udev anyway :)
17:05 < marcheu> so, I lost my notes
17:05 < marcheu> but tat the end of video ram, there are the fifos
17:05 < marcheu> and starting with nv40, there is a little more room that just for the fifos
17:06 < marcheu> there are 64 fifos on nv40 AFAIK
17:06 < marcheu> each is 8kb, and there is 560kb for them total
17:06 < marcheu> so there is 48 "unused" kb there
17:06 < darktama> you're thinking it's used as instance memory?
17:07 < marcheu> yes
17:08 < marcheu> I'm not sure we'll ever be able to program our driver to use it, but we might want to take a look
17:08 < marcheu> and it looks like cards can operate in the older mode anyway
17:09 < darktama> yes, the ddx uses the "normal" way on all cards
17:15 < darktama> btw, we may need to move the code that stomps PFIFO (nv_hw.c, NVLoadStateExt) into drm aswell
17:18 < darktama> it gets called on mode changes, VT switches, and probably other things too.. so a mode change would disable all the FIFOs except the one the ddx uses
17:19 < marcheu> I was thinking we could clean it up 
17:21 < darktama> yup
17:22 < marcheu> hmm
17:22 < marcheu> I've got a number of changes in the ddx
17:23 < darktama> I still think that un-hardcoding the FIFO setup (and using drm to do it) would be a win, though it could be a lot of work.. I'm willing to attempt it though one the drm is capable
17:23 < marcheu> well
17:23 < marcheu> there are 2 ways to do it
17:23 < marcheu> (get to 3d, that is)
17:23 < marcheu> - either write the drm object stuff first, and modify the DDX heavily
17:24 < marcheu> - either hack the DDX to setup some 3D object and use them
17:26 < darktama> we're probably going to have to do the first eventually :)
17:40 < darktama> what changes do you have in the ddx so far?
18:04 < marcheu> lots of bios debugging junk
18:05 < marcheu> hmm one thing though, I replaced the hardcoded regs areas with some #defined ones
18:05 < marcheu> that might be worth comitting
18:06 < darktama> indeed
18:22 -!- Duke` [n=gnu@ANantes-251-1-98-42.w86-203.abo.wanadoo.fr] has quit [Connection timed out]
18:23 -!- Duke` [n=gnu@ANantes-251-1-138-32.w86-210.abo.wanadoo.fr] has joined #nouveau
18:50 -!- Abraham [n=Abraham@38-148.242.81.adsl.skynet.be] has joined #nouveau
20:25 -!- gajownik_away [i=gajownik@zspswidwin.pl] has joined #nouveau
21:02 -!- pmdata [i=patrice@ANantes-154-1-110-153.w86-214.abo.wanadoo.fr] has joined #nouveau
21:04 < pmdata> hello
22:04 -!- _Abraham [n=Abraham@189-146.242.81.adsl.skynet.be] has joined #nouveau
22:06 < marcheu> pmdata: new legacy driver released from nvidia
22:09 < pmdata> ah, will try it (hope it does not crash)
22:09 < marcheu> well, it's still some 71XX
22:11 < pmdata> yeah, not much improvement, beyond supporting newer kernels
22:12 < pmdata> on nvnews, there is a flamewar about the xorg 7.1 support still not present
22:12 < pmdata> (for 8xxx drivers)
22:12 < marcheu> actually, it works mostly fine here
22:13 < marcheu> just setup an option to work around font issues
22:13 < pmdata> I don't know if 1.0-71xx would work with xorg, whatever the version
22:14 < marcheu> yup, it does
22:14 < marcheu> I used Xorg 6.9/7.0 with 71XX on my legacy gf2 gts
22:14 < pmdata> ok
22:16 < pmdata> regarding mipmapping, it does not seem to use hardware to be generated
22:16 < pmdata> but when fsaa is enabled, there is not much difference with how the viewport is setup, beyond the size change
22:18 < pmdata> ah, I should try 960x720 without fsaa, and 640x480 with 1.5x fsaa, to compare stuff
22:18 < pmdata> and 1280x960 without, and 640x480 with 2x
22:19 < marcheu> well, since GF2 uses supersmpling, that would make sense, yes
22:21 -!- Abraham [n=Abraham@38-148.242.81.adsl.skynet.be] has quit [Read error: 110 (Connection timed out)]
22:21 -!- _Abraham is now known as Abraham
22:30 < pmdata> marcheu> do you know what could be the low word in viewport_dims command, the high words seems to be width and height
22:37 -!- Abraham [n=Abraham@189-146.242.81.adsl.skynet.be] has quit [Remote closed the connection]
22:37 < marcheu> nope
22:39 < pmdata> hum, something strange, when I setup a 1280x960 viewport, values don't match in viewport_dims command
22:39 < pmdata> but as I have a 1024x768 resolution, this dimension seems to be clipped to the viewable area
22:42  * pmdata should try adding a pause, to allow moving the window on a screen boarder before the videomode is setup
22:43 < marcheu> it's not drawn on the front buffer anyway
22:43 < marcheu> only the back to front copy is different when the window moves
22:43 < pmdata> hum, even a simple prg without rendering would show us how the context is changed when part is not visible
--- Log closed Срд Июн 28 00:00:37 2006
