--- Log opened Пнд Июл 31 00:00:02 2006
00:39 -!- qfire is now known as qfire_away
00:39 -!- qfire_away is now known as qfire
00:39 < marcheu> no idea about the number of 2D clip planes
00:40 < marcheu> but I guess 4 is enough for everyone if they are axis-aligned
00:42 -!- qfire is now known as qfire_away
00:43 -!- qfire_away is now known as qfire
00:43 -!- qfire is now known as qfire_away
00:43 -!- MrAsd [n=MrAsd@host72-56.pool877.interbusiness.it] has joined #nouveau
01:08 < lumag_offline> How can I find the offset of the linear fb of the screen?
01:15 < lumag_offline> another hangup :(
01:26 -!- stringfellow_ [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
01:34 < pmdata> lumag> isn't it the color buffer offset?
01:35 -!- MrAsd [n=MrAsd@host72-56.pool877.interbusiness.it] has quit [Remote closed the connection]
01:36 < lumag_offline> I
01:36 < lumag_offline> Yup. But how to find it from non-X server program?
01:37 < pmdata> this is a problem, you can't use the nv driver outside of X
01:38 < lumag_offline> If there would be some magic printf in the DDX, that would be ok for now :)
01:39 < pmdata> did you try to compile the kernel driver with -DDEBUG? it adds some msg
01:39 < lumag_offline> you mean drm driver? I thought ebug printk's are toggled by debug parameter of drm.ko
01:39 < lumag_offline> debug
01:43 -!- pmdata [i=patrice@ANantes-154-1-30-53.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:47 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
01:48 < marcheu> Lumag: you simply want to know the fb adress ?
01:49 < marcheu> Lumag: it's in /var/log/Xorg.0.log
01:49 < marcheu> (--) NVIDIA(0): Linear framebuffer at 0xD0000000
01:49 < marcheu> it's a physical adress, though
01:49 < Lumag> no:) the offset of the color buffer that it's used for screen output
01:49 < marcheu> ah
01:49 < marcheu> the crtc offset
01:50 < Lumag> yup
01:57 -!- ElAngelo [n=ElAngelo@merlin.ugent.be] has joined #nouveau
01:58 -!- EdB_ [n=EdB@ARennes-251-1-18-155.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
01:59 < marcheu> so you can't read the register ?
01:59 < ElAngelo> is there anything a non programmer can do for this project atm?
01:59 < Lumag> marcheu: what register?
01:59 < marcheu> Lumag: NV_PCRTC_START (0x600800)
01:59 < marcheu> ElAngelo: not really
02:00 < Lumag> Oh. Good :)
02:00 < ElAngelo> good :)
02:00 < ElAngelo> then i won't bother you :p
02:06 -!- `Duke` [n=gnu@ANantes-251-1-90-179.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:39 -!- qfire_away [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit [Read error: 110 (Connection timed out)]
02:52 -!- qfire_away [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
04:01 < darktama> Lumag: I'll upload it for you now
04:03 < darktama> http://members.iinet.net.au/~darktama/nvtest.tar.bz2
04:04 < darktama> btw, it doesn't use nvidia.ko ioctls.. it uses nvidia's libGL to create a context, and then steals control of it
04:11 < ddl> hey!
04:11 < darktama> hey ddl
04:11 < darktama> how's things?
04:12 < ddl> slowly moving forward (i hope ;))
04:12 < darktama> nice :)
04:12 < darktama> I tried enabling BIOS writes last night, the result wasn't pretty
04:13 < ddl> i know, theres lots of stuff missing
04:13 < ddl> vital parts
04:13 < ddl> like the PLL stuff
04:13 < ddl> and the memory setup
04:14 < ddl> i wrote a mail to rudolf yesterday.. hope i sent it to the right addr
04:15 < darktama> mm, have you tried the haiku driver yet?  I've been meaning to see if it can setup dual-head on my card
04:16 < ddl> nope, not yet 
04:16 < darktama> a haiku livecd would be great, as I don't really want to mess around with it much
04:17 < ddl> yeah, i dont feel like repartitioning this drive to get space for it
04:17 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
04:18 < ddl> i probably have a couple of spare disks at home
04:20 -!- qfire_away is now known as qfire
04:25 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
04:28 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
04:35 < darktama> hmm, what's an appropriate error to return from the drm if we run out of instance ram or hash table entries?  is ENOMEM just for system ram?
04:37 < ddl> check what the proprietary driver returns
04:37 < ddl> that part should be there in code
04:37 < ddl> but ENOMEM seems suitable :)
04:39 < darktama> it seems to return EINVAL if there's *any* error inside the binary part of the kernel module
04:39 < darktama>             status = rm_ioctl(nv, file, _IOC_NR(cmd), arg_copy) ? 0 : -EINVAL;
04:40 < ddl> okay
04:40 < darktama> but ENOMEM still makes more sense to me, so it'll do until I'm told otherwise :)
04:42 < ddl> i agree :)
06:28 < darktama> grr, I don't like the way the ddx is indented with spaces
06:46 < darktama> hm, actually the formatting is quite random in places
06:52 -!- jphenix_away [n=greaterd@modemcable189.26-56-74.mc.videotron.ca] has quit ["using sirc version 2.211+KSIRC/1.3.12"]
06:52 < ddl> mmm, we have to agree on either tabs or spaces
06:52 < ddl> i vote for tabs ;)
06:52 < darktama> me too :)
06:53 < darktama> but for now, I'm trying to match my formatting to the current formatting before I commit
08:47 -!- johill [n=johannes@p5487EFE8.dip.t-dialin.net] has joined #nouveau
09:27 -!- Unavowed [n=silent@13.t6.ds.pwr.wroc.pl] has quit [Read error: 104 (Connection reset by peer)]
09:49 < airlied> for anyt kernel code you *must* follow the lk style..
09:49 < airlied> so any drm code ..
09:52 < darktama> I'd better read the coding style doc and reformat my code then :)
09:54 < airlied> 8-space tabs, braces on same line, no trailing whitespace are top 3 rules..
09:54 < airlied> sorry all tabs... but set at 8-spaces...
09:55 < darktama> are tabs real tabs, or spaces?  radeon_cp.c seems to use real tabs
09:55 < airlied> 5~real tabs..
09:55 < airlied> sorry real tabs..
09:55 < airlied> but to make the code look correct, your editor should display a tab as 8 spaces
09:56 < darktama> yeah, I usually have vim set to 4
09:56 < airlied> it only really matters for indenting printfs and multi-line function prototypes..
10:11 < darktama> airlied: so, this is better? http://sh.nu/p/2515
10:12 < darktama> hm, probably a bad place to show indenting.. firefox killed it
10:13 < darktama> http://members.iinet.net.au/~darktama/drm.diff
10:16 < airlied> darktama: btw where are you in .au?
10:16 < darktama> tassie
10:20 < airlied> darktama: ah cool..
10:21 < airlied> for the NV_WRITE you could probably leave it on one line or at least have the | bars at the end of the previous line..
10:21 < airlied> the rest looks good..
10:25 < darktama> ok.. the NV_WRITE lines go slightly over 80 chars, but I'll put the |s on the other end of the line.. I intend on replacing the shifts with named constants at some point anyway
11:29 -!- EdB [n=EdB@ARennes-251-1-148-220.w86-214.abo.wanadoo.fr] has joined #nouveau
13:20 -!- Duke` [n=gnu@ANantes-251-1-90-179.w86-203.abo.wanadoo.fr] has joined #nouveau
13:37 -!- shenki [n=shenki@ppp149-62.lns3.adl2.internode.on.net] has joined #nouveau
14:36 -!- EdB [n=EdB@ARennes-251-1-148-220.w86-214.abo.wanadoo.fr] has quit ["Konversation terminated!"]
16:02 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:26 -!- shenki [n=shenki@ppp149-62.lns3.adl2.internode.on.net] has quit ["Leaving"]
16:36 -!- Duke` [n=gnu@ANantes-251-1-90-179.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
16:59 -!- Duke` [n=gnu@ANantes-251-1-90-179.w86-203.abo.wanadoo.fr] has joined #nouveau
17:13 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
17:29 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
17:47 -!- tibbs [n=tibbs@fedora/tibbs] has quit [Nick collision from services.]
17:48 -!- tibbs|h [n=tibbs@fedora/tibbs] has joined #nouveau
18:59 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
19:18 -!- haypo [n=haypo@ip-176-84.evc.net] has joined #nouveau
19:19 -!- Duke` [n=gnu@ANantes-251-1-90-179.w86-203.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
19:33 -!- EdB [n=EdB@ARennes-251-1-2-19.w83-195.abo.wanadoo.fr] has joined #nouveau
19:50 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
20:00 < lumag_offline> darktama: thank you. I'll look into it :)
20:08 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:22 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
20:51 -!- Duke` [n=gnu@ANantes-251-1-96-167.w86-203.abo.wanadoo.fr] has joined #nouveau
20:54 -!- pmdata [i=patrice@ANantes-154-1-93-251.w86-210.abo.wanadoo.fr] has joined #nouveau
20:55 < pmdata> hello
21:03 < pmdata> http://nouveau.freedesktop.org/wiki/UserPreferences where is the 'connect' button when logged out, and want to re-login?
21:25 -!- nano [n=nano@h100n2fls33o1016.telia.com] has joined #nouveau
21:28 < marcheu> http://nouveau.freedesktop.org/wiki/UserPreferences?action=login
21:34 < pmdata> thanks
21:50 < marcheu> cool cube maps
22:17 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
22:19 -!- haypo [n=haypo@ip-176-84.evc.net] has left #nouveau ["Konversation terminated!"]
22:20 < pmdata> I see only the 6 texture uploads, and a bit set in the texture unit format
22:21 < pmdata> I should upgrade to driver 5xxx :)
22:22 < pmdata> I tried specific cube map texgeni(), but no change
22:24 < pmdata> vertex weighting was deprecated in favor of vertex program, but I don't think the later is hw accelerated on nv15
22:27 < pmdata> marcheu> if I run another gl program (like glxgears), keep it running before running renouveau, should I see something different?
22:27 < marcheu> did you see a lot of changes when changing the driver version ?
22:28 < pmdata> marcheu> lumag and I made pages on wiki about the difference between drivers
22:28 < marcheu> pmdata: not really except the fifo & matching control register should have a different physical adress
22:28 < marcheu> yeah, I saw those, but they only report the extensions
22:28 < pmdata> hum, I see that on 7xxx for example, vertices are always sent in a array
22:28 < pmdata> even for a single triangle
22:28 < pmdata> whereas on 4xxx I see the single vertex command
22:29 < pmdata> clip planes are also done with cpu on 4xxx
22:29 < marcheu> ah, these are interesting changes
22:29 < marcheu> it's easy to know which driver has which extensions on delphi3d.net
22:29 < pmdata> swap_buffers is always done with blitcopy, even in fullscreen double buffer
22:29 < marcheu> since the windows & linux versions match
22:30 < pmdata> whereas on 7xxx it changes the video display adress
22:30 < pmdata> the purpose on trying drivers was to also check what stuff is in software, and in hw
22:31 < pmdata> for example, 4xxx has NVX_ycrcb, which has been removed later, so may be this is just a conversion done with cpu
22:31 < marcheu> most probably. although ycrb textures are very useful for video playback
22:32 < pmdata> yep, so I must find something to test this texture format
22:33 < marcheu> we need renouveau for osx :) they expose ycrb textures on that platform IIRC
22:33 < marcheu> hmm actually it's yuv textures I think
22:34 < pmdata> what about win32?
22:35 < marcheu> http://delphi3d.net/hardware/index.php
22:35 < marcheu> but really, it matches the linux drivers
22:35 < marcheu> including the version numbers, which can be compared
22:36 < pmdata> spec for nvx_ycrcb has been removed
22:37 < pmdata> I did not try defining a texture with border, should it be hw accelerated?
22:37 < marcheu> it is usually
22:37 < marcheu> however, the nvidia driver doesn't have a conformant behaviour with respect to texture clamping
22:38 < marcheu> so when playing with border modes & clamping, you might get some odd results
22:38 < marcheu> windows users have a switch to enable "conformant texture clamping" or such
22:39 < pmdata> I guess 'conformant' = cpu :)
22:39 < marcheu> nope
22:39 < marcheu> conformant is "conformant to the opengl clamping spec"
22:39 < pmdata> yep, but it does not mean it is hw accelerated
22:40 < marcheu> the issue is that at first, no one had their clamping implementation right, and a couple of games were incorrectly programmed (in particular with the skyboxes)
22:40 < pmdata> should accumulation buffer be hw accelerated?
22:40 < marcheu> nvidia was one of the drivers to have the implementation wrong
22:40 < marcheu> later on, they chose to keep the wrong behaviour, in order to not break those games
22:41 < marcheu> no idea if accumulation buffers are accumulated, I don't think I ever used those
22:41 < marcheu> but I think they are, they are just costly because they usually needs data copies all around
22:42 < marcheu> anyway, I have to go
22:42 < marcheu> I'll try to start work on the memory management stuff when I'm back later
22:43 < marcheu> I'll just pull an existing manager, and add what we need. that'll be sufficient band aid until the Great DRI Memory Manager comes alive
22:45 < pmdata> \o\
22:45 < marcheu> wind from the east, huh ?
22:45 < pmdata> :)
23:24 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
23:27 -!- gajownik_away [i=gajownik@zspswidwin.pl] has joined #nouveau
23:39 < lumag_offline> 
23:39 < lumag_offline> 
23:39 < lumag_offline> 
23:39 < lumag_offline> X :1 & D
23:39 < lumag_offline> X -layout Second :2 & DISPLAY=:2 xterm &
23:40 < lumag_offline> 
23:40 < lumag_offline> X -layout Secondary :33 X -layout Secondary :2 & DISPLAY=:2 xterm &
23:40 < lumag_offline> 
23:40 < lumag_offline> dedmesg > /var/tmp/
23:43 -!- johill [n=johannes@p5487EFE8.dip.t-dialin.net] has quit [Read error: 113 (No route to host)]
23:56 -!- EdB [n=EdB@ARennes-251-1-2-19.w83-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
--- Log closed Втр Авг 01 00:00:03 2006
