--- Log opened Пнд Авг 14 00:00:13 2006
00:11 < sturmflut> Funny, the guys over at #macvidia claim that the driver is completely self-written from scratch, but I found more than 30 symbols that can also be found in Linux nvidiafb or the X.Org nv driver
00:13 < sturmflut> This is definitely a case for the LKML
01:19 < sturmflut> Okay, settled. They'll change the legal stuff, it's more or less just a port of the original X nv driver from NVIDIA (the one released back in 2003)
01:21 < Duke`> ahah, and they didn't want to tell it!
01:31 < sturmflut> No, I think they just didn't know what's it all about with GPL and stuff
01:32 < sturmflut> So much for the "intelligent and creative" Apple Community ;)
01:32 < Duke`> erf :/
01:33 < Duke`> but what is this driver? who use it?
01:34 < sturmflut> The Mac-OS-X-on-x86-Hackers
01:35 < sturmflut> The guys who cracked Mac OS X so that it runs on every x86 machine, not just the ones from Apple
01:37 < sturmflut> I thought maybe they reverse engineered something we could use, somebody said the driver is able to run Quartz Extreme and Aqua (the OpenGL-accellerated Mac OS X GUI) and that would mean they must have a driver which is able to initialize the card and execute OpenGL commands
01:37 < sturmflut> But it's only 2D
01:43 < sturmflut> I submitted another 144 commands for Lighting stuff on NV20 and NV30 to CVS, if somebody is good at numbers he can try to find out how the parameters for GL_SPOT_DIRECTION, GL_SPOT_CUTOFF and GL_SPOT_EXPONENT are transformed before being sent to the GPU
01:47 -!- Duke` [n=gnu@ANantes-251-1-85-135.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
01:51 -!- Myrizio [n=Myrizio@host77-101.pool80104.interbusiness.it] has joined #nouveau
01:52 -!- sturmflut [n=sturmflu@2001:6f8:992:1337:213:d4ff:feaa:8a9f] has quit ["Konversation terminated!"]
01:53 < pmdata> sturmflut> could you name the variables more appriopriately? i.e. not using _A,_B,_C but X,Y,Z,W for a position, R,G,B,A for a color, S,T,R,Q for a texture coord
01:54 < pmdata> I just see that in the light stuff
01:54 < pmdata> ambient, diffuse, emission, etc in light are colors
01:55 < pmdata> and A,B,C,D are clip plane coefs
01:55 < johane> update: I put the kernel's unistd.h in the renouveau directory and added #define __KERNEL__ before including it.. compiles now.
01:59 -!- gajownik_away [i=gajownik@zspswidwin.pl] has joined #nouveau
02:08 < pmdata> anyone tried to make dumps with fsaa enabled, to see the difference?
02:08 < pmdata> on nv20+
02:14 -!- Myrizio [n=Myrizio@host77-101.pool80104.interbusiness.it] has quit [Read error: 110 (Connection timed out)]
02:15 -!- svu [n=svu@194.46.173.108] has left #nouveau ["Ex-Chat"]
02:15 -!- svu [n=svu@194.46.173.108] has joined #nouveau
02:18 -!- Myrizio [n=Myrizio@host92-101.pool80104.interbusiness.it] has joined #nouveau
02:36 < pmdata> add test for ext_texture_filter_anisotropic
02:38 -!- pmdata [i=patrice@ANantes-154-1-108-70.w86-214.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
03:06 -!- atcl [n=Universe@L8b65.l.pppool.de] has quit [Read error: 54 (Connection reset by peer)]
03:17 < airlied> darktama: interesting, more than likely my driver will require options, but that isn't all that bad.. every other driver does too still..
03:19 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
03:38 -!- K [i=hazel@tor/session/external/x-a95f3af484b038de] has quit [Remote closed the connection]
04:06 < marcheu> pmdata: if you want to do nv20 dumps, you can use my nv28, remember...
04:07 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
04:49 < johane> marcheu: got renouveau working now, and have experimented with some dumps.. so what can i do to help? i have a geforce 4mx (that would be nv10 in the feature matrix right?)..
04:52 < johane> later..
04:52 -!- johane [n=johan@84-217-89-131.tn.glocalnet.net] has quit ["Leaving"]
04:55 -!- svu [n=svu@194.46.173.108] has quit [Read error: 54 (Connection reset by peer)]
04:55 -!- svu [n=svu@194.46.173.108] has joined #nouveau
05:04 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
06:51 -!- Myrizio [n=Myrizio@host92-101.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
06:52 -!- shenki [n=shenki@ppp175-149.lns3.adl4.internode.on.net] has quit ["Leaving"]
07:45 -!- nano- [i=nano@exodus.xmms.se] has quit [Read error: 60 (Operation timed out)]
08:14 -!- tibbs is now known as tibbs|h
08:29 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit [Read error: 104 (Connection reset by peer)]
08:44 -!- TMM [n=hp@c51471f2c.cable.wanadoo.nl] has quit [Read error: 60 (Operation timed out)]
10:02 -!- K [i=hazel@tor/session/external/x-c216b1bf8559733b] has joined #nouveau
10:21 -!- nano- [i=nano@exodus.xmms.se] has joined #nouveau
11:18 -!- K is now known as Breiko
12:01 -!- Duke` [n=gnu@ANantes-251-1-85-135.w86-203.abo.wanadoo.fr] has joined #nouveau
12:02 -!- pmdata [i=patrice@ANantes-154-1-67-18.w86-195.abo.wanadoo.fr] has joined #nouveau
12:08 < pmdata> hello
12:12 < Duke`> hi
12:22 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
12:40 -!- shenki [n=shenki@ppp175-149.lns3.adl4.internode.on.net] has joined #nouveau
12:45 -!- johane [n=johan@84-217-89-131.tn.glocalnet.net] has joined #nouveau
13:02 -!- Unavowed [n=silent@host81-151-27-96.range81-151.btcentralplus.com] has joined #nouveau
13:08 < pmdata> hum, 1e60 and 1e70 seems related to texture units on nv20
13:13 < pmdata> when enabling each texture unit in turn:
13:13 < pmdata> [pmandin@localhost renouveau]$ grep 1e60 card_10de-0281_test_arb_multitexture.txt
13:13 < pmdata> cc9   0x00000000   0x00011101            NV20_TCL_PRIMITIVE_3D      [0x1e60/4] = 0.000000 | UNKNOWN = 00011101
13:13 < pmdata> d6a   0x00000000   0x00011102            NV20_TCL_PRIMITIVE_3D      [0x1e60/4] = 0.000000 | UNKNOWN = 00011102
13:13 < pmdata> df2   0x00000000   0x00011103            NV20_TCL_PRIMITIVE_3D      [0x1e60/4] = 0.000000 | UNKNOWN = 00011103
13:13 < pmdata> e81   0x00000000   0x00011104            NV20_TCL_PRIMITIVE_3D      [0x1e60/4] = 0.000000 | UNKNOWN = 00011104
13:13 < pmdata> [pmandin@localhost renouveau]$ grep 1e70 card_10de-0281_test_arb_multitexture.txt
13:13 < pmdata> cbb   0x00000000   0x00000001            NV20_TCL_PRIMITIVE_3D      [0x1e70/4] = 0.000000 | UNKNOWN = 00000001
13:14 < pmdata> d5c   0x00000000   0x00000021            NV20_TCL_PRIMITIVE_3D      [0x1e70/4] = 0.000000 | UNKNOWN = 00000021
13:14 < pmdata> de4   0x00000000   0x00000421            NV20_TCL_PRIMITIVE_3D      [0x1e70/4] = 0.000000 | UNKNOWN = 00000421
13:14 < pmdata> e73   0x00000000   0x00008421            NV20_TCL_PRIMITIVE_3D      [0x1e70/4] = 0.000000 | UNKNOWN = 00008421
13:14 < marcheu> 1e70 looks like program parameter routing
13:15 < marcheu> 1e60 looks like it holds the number of enabled program parameters
13:16 < pmdata> I don't know enough about vertex programs
13:17 < marcheu> I suppose darktama has figured those out already...
13:17 < darktama> not those regs, no.. I just worked on the VP instruction set itself..
13:18 < marcheu> pmdata: so, basically, 0x00008421 means that the first 4 params are routed to 1,2,3 and 4th outputs
13:19 < marcheu> at least, that's how I see it
13:20 < darktama> on r300 you have to route vertex program outputs to interpolators, and then into fragment program regs.. could be something similar
13:22 < marcheu> darktama: btw if you need nv34 tests, now is the time
13:23 < darktama> hmm, actually there was one more thing I needed for nv30.. let me quickly write a test that nvidia's optimisers wont mess with
13:26  * pmdata would like nv30+ dumps for arb_multitexture and ext_texture_filter_anisotropic
13:26 -!- shenki [n=shenki@ppp175-149.lns3.adl4.internode.on.net] has quit ["http://xkcd.com/comics/fourier.jpg"]
13:27 < darktama> marcheu: http://sh.nu/p/2705
13:27 < darktama> pmdata: I can get you NV40 if you want it
13:28 < pmdata> I don't know if I could use it
13:28 < pmdata> my motherboard only supports agp 2x or 1x
13:29 < pmdata> or maybe a pci one?
13:29 < darktama> I mean, NV40 dumps :)
13:29 < darktama> I pretty much know how to do it on NV40 anyway though
13:31 < stillunknown_> 6800GT AGP? (just tryring to see if i can guess the right one)
13:31 < darktama> which reminds me, I need to document 0x1ff0/0x1ff4 at some point
13:31  * darktama adds to TODO list
13:31 < darktama> yup, 6800GT AGP here
13:33 < stillunknown_> it could have been an early pci express 6800(GT) as well or another variation of the 6800 AGP
13:35 < stillunknown_> when the new binary blob from nvidia comes out i can offer NV43 dumps if needed (unless something bad happens)
13:35 < pmdata> darktama> ok for your dumps
13:35 < darktama> why do you need to wait for the new driver?
13:35 < marcheu> ok, tests up
13:36 < stillunknown_> xorg 7.1 compatibility
13:36 < darktama> btw, 1.0-8774 is finished.. apparently they're waiting for the web guys to put them up
13:36 < marcheu> darktama: yours is http://nouveau.sourceforge.net/tests/nv34/card_10de-0322_test_vtxprog_darktama.txt
13:36 < stillunknown_> i know
13:36 < darktama> I'm using it with Xorg 7.1 at the moment, everything is fine except for wine
13:36 < darktama> marcheu: thanks
13:36 < marcheu> I'm using 7.1.1 and I can only get it to crash
13:36 < stillunknown_> i had some font issues
13:37 < marcheu> pmdata: for you the names are obvious :)
13:37 < darktama> yeah, I had font issues until I disabled RenderAccel.. now just wine has missing fonts
13:37 < stillunknown_> i know all the possible workarounds, none of them work well
13:39 < darktama> marcheu: hmm, I'm using 7.1.1 also it seems..
13:39 < stillunknown_> me too
13:40 < marcheu> it used to work on 7.1. although it's 7.1.1+ I have at home so maybe that matters
13:40 < darktama> yeah, I'm just using Gentoo's standard xorg-server-1.1.1.. maybe something else changed in X after that
13:40 < marcheu> no idea, I'm always the last one to learn about ABI breakages :)
13:41 < stillunknown_> 7.1.1+ as in git checkout?
13:41 < marcheu> yup
13:42 < darktama> grr, I was hoping to share a fair bit of code between NV20 and NV30 disasm.. but I keep finding slight differences
13:42 < Duke`> it seems that edgy's xorg is 7.1 and is running the proprietary driver fine
13:42 < pmdata> marcheu> which names?
13:43 < stillunknown_> edgy is debian?
13:43 < marcheu> pmdata: http://nouveau.sourceforge.net/tests/nv34/card_10de-0322_test_arb_multitexture.txt and http://nouveau.sourceforge.net/tests/nv34/card_10de-0322_test_ext_texture_filter_anisotropic.txt. I have to rename the file for darktama because that would've overwritten the "real" test 
13:44 < pmdata> of course
13:45 < Duke`> edgy is ubuntu
13:45 < Duke`> etch is debian
13:45 < pmdata> already added stuff to renouveau cvs :)
13:45 < pmdata> I wonder if NV30_TCL_PRIMITIVE_3D_TX_FORMAT_UNIT is correct
13:46 < ajmitch> hi
13:46 < darktama> it should be, except for the FORMAT_FORMAT field perhaps
13:47 < darktama> you also need to set bit 1, 15 and 16 or the engine locks though.. no idea what they are for
13:47 < pmdata> ok, nevermind
13:48 < darktama> sorry, bit 0,15,16..
13:48 -!- `Duke` [n=gnu@ANantes-251-1-140-118.w86-210.abo.wanadoo.fr] has joined #nouveau
14:00 < darktama> pmdata: http://members.iinet.net.au/~darktama/pmdata/
14:03 -!- stillunknown_ [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has quit []
14:04 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
14:04 -!- Duke` [n=gnu@ANantes-251-1-85-135.w86-203.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
14:05 < pmdata> darktama> nv40 or nv30?
14:05 < darktama> NV40
14:05 < pmdata> hum, it does not use same enable bit as nv30 (31 instead of 30)
14:06 < darktama> yup
14:06 < marcheu> pmdata: yeah, saw it, you have to fix that :)
14:07 < darktama> NV40 also has a second set of regs for textures that are used when a vertex program samples textures
14:08 < marcheu> maybe it's as usual on nv30
14:08 < marcheu> bit 30 is used before you enable frag progs
14:08 < marcheu> and bit 31 is used after you enable frag progs
14:08 < darktama> yeah, I don't think nv30 can sample textures in a vertex program.. (no NV_vertex_program3)
14:09 < stillunknown> nv30 was a poor design
14:11 < stillunknown> (from a user perspective), i'll shut up now :-)
14:13 < pmdata> darktama> can you checkout, and redump the anisotropy test?
14:13 < darktama> sure
14:15 < darktama> ok, done
14:48 < marcheu> pmdata: are there 8 clip planes ?
14:55 -!- Myrizio [n=Myrizio@host38-101.pool80104.interbusiness.it] has joined #nouveau
14:59 -!- johane_ [n=johan@84-217-89-131.tn.glocalnet.net] has joined #nouveau
15:08 -!- johane [n=johan@84-217-89-131.tn.glocalnet.net] has quit [Read error: 60 (Operation timed out)]
15:08 < pmdata> there is room for 8 clip planes, but can not enable them
15:09 < pmdata> we'll have to wait for the nouveau driver to test these
15:11 < darktama> pmdata: if you want to test them grab nvtest.tar.bz2 from the same place I put the dumps, and throw the commands at the GPU
15:14 < pmdata> can it crash the system?
15:14 < darktama> yes, it's possible
15:15 < pmdata> :)
15:19 < darktama> I've never bought my machine down completely, but I've had X screw up on me
15:19 < marcheu> I don't even need nvtest for that, the nvidia driver is enough
15:19 < darktama> hehehe :)
15:21 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has quit [Read error: 104 (Connection reset by peer)]
15:22 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
15:27 < marcheu> darktama: what headers are supposed to have GL_NV_vertex_program3 defined ?
15:27 < darktama> glext.h
15:28 < marcheu> so why do we get our extensions from SDL_opengl.h :)
15:28 < darktama> hmm, at one stage glext.h was there I think..
15:29 < pmdata> glext.h is included in sdl_opengl.h
15:29 < marcheu> pmdata: "included" as in "inlined"
15:30 < marcheu> and it is an old version...
15:51 < marcheu> ok, I updated the g70 & nv34 tests
16:03 < pmdata> hum, anisotropy is different between nv30 (same as nv10,nv20) and nv40+
16:17 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
16:17 < pmdata> hi lumag
16:18 < Lumag> hi all! I'm finally back from work, from caves and I'm ready for more renv'ing :)
16:20 < marcheu> hey Lumag. caves ?
16:22 < Lumag> Yup. I had to rest a bit, so we this weekend I was 12-15 meters under the ground level.
16:23 < Lumag> any progress on context switching?
16:24 < marcheu> not on my side, IIRC darktama mentioned he couldn't get the interrupt code to work :(
16:24  * Lumag tries to catch up by reading channel logs.
16:24 < darktama> marcheu: huh?
16:24 < marcheu> darktama: ah, so there is hope ?
16:24 < darktama> no, I don't recall trying anything in the interrupt code..
16:25 < marcheu> ah, so maybe we should :)
16:26 < darktama> I think actually switching channels isn't so hard.. it's saving/restoring the context that has me worried
16:26 < marcheu> I don't think we have to
16:27 < darktama> I doubt the hardware has enough internal memory to store the entire context for every possible object on every channel..
16:27 < darktama> but I could be wrong :)
16:29 < marcheu> why would it allow 8 objects max then ?
16:29 < darktama> the subchannels?
16:29 < marcheu> yeah
16:29 < darktama> hm, I suppose
16:31 < marcheu> I mean, there's not technical reason for allowing only 8 objects on a fifo
16:31 < marcheu> except if you have to store their context, that is...
16:32 -!- Breiko [i=hazel@tor/session/external/x-c216b1bf8559733b] has quit [K-lined]
16:32 < darktama> yes, that does make sense.. the nvosdk code is what bothered me, it saves/restores a heap of stuff in PGRAPH on a context switch
16:33 < marcheu> IIRC Lumag mentioned it was only used on things like VT switches
16:33 < marcheu> heh, kline
16:33 < darktama> oh, I didn't notice that
16:35 -!- Breiko [i=hazel@85-57-132-109.gij1.adsl.uni2.es] has joined #nouveau
16:35 -!- Breiko [i=hazel@tor/session/external/x-378eb38b42570087] has quit [K-lined]
16:41 < marcheu> do you get interrupts at least ?
16:41 < marcheu> I mean, with normal X usage
16:45 < darktama> CRTC interrupts definitely work.. according to my kernel logs I got a FIFO error interrupt at one point aswell
16:45 < Lumag> IIRC there is interrupt code in rivatv. It may be interesting to look into
16:46 < darktama> yup, they handle notifier interrupts - which could be useful for us also
16:46 < darktama> nvidia don't seem to use them on MEMORY_TO_MEMORY_FORMAT for some reason
16:48 < marcheu> there's interrupt code in nvosdk as well
16:48 < darktama> yes, they handle quite a few.. including CONTEXT_SWITCH, which I didn't figure out how to enable
16:48 < marcheu> yeah, we really need to handle these notifiers in the kernel properly
16:49 < marcheu> understand and store them for when the apps requests them
16:51 < darktama> yes, and teach the kernel how to kickoff DMA transfers with an (optional) wait for completion.. it'd be useful to be able to defer the wait_notifier() until a later point also
16:54 -!- EdB [n=EdB@ARennes-251-1-85-113.w86-199.abo.wanadoo.fr] has joined #nouveau
17:33 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
18:04 -!- johane__ [n=johan@84-217-89-131.tn.glocalnet.net] has joined #nouveau
18:11 < darktama> marcheu: if you get a chance, can you do this vtxprog2() test: http://sh.nu/p/2706 .. this is the last one, I promise :)
18:12 < darktama> I didn't realise NV_vp2 had a second address reg, I thought that came in NV_vp3
18:12 -!- johane_ [n=johan@84-217-89-131.tn.glocalnet.net] has quit [Read error: 60 (Operation timed out)]
18:12 < marcheu> oh it does ?
18:12 < marcheu> cool
18:12 < darktama> yup, which means NV30 should have it too :)
18:13 < marcheu> NV20 has only one
18:13 < darktama> yes
18:14 < marcheu> NV20 is the approximate time I stopped writing shaders in assembly :)
18:14 < darktama> ah :) I'm glad there was an option to use assembly for branching etc.. made life much easier.. I tried using GLSL when I first did the work on NV40 shaders
18:16 < darktama> apart from some code cleanups, I'm pretty much done with NV20/30 shaders now.. and fixed a couple of NV40 bugs in the process
18:17 < marcheu> cool, I wonder what it looks like on nv20
18:17 < marcheu> card_10de-0322_test_vtxprog2_darktama.txt
18:17 < marcheu> at the usual place
18:17 < darktama> NV20 has some extra instructions tacked on the end of the program, I have nfi what their purpose is though
18:18 < marcheu> hmm, like what ?
18:18 < darktama> but overall the layout of all three instruction sets is very similar
18:18 < darktama> one sec
18:19 < marcheu> maybe these are directives to override the fixed pipeline ?
18:19 < marcheu> did you figure out what effect position_invariant has ?
18:19 < darktama> http://sh.nu/p/2707 (the last 4 instructions, always the same tacked on the end of every dump)
18:20 < darktama> no, didn't try position invarient on NV20/30 yet.
18:20 < marcheu> those 4 insts you talk about are MUL/RCC/MAD/NOP ?
18:20 < darktama> yup
18:23 < darktama> ok, the address reg select bit is in the same place as NV40
18:25 < marcheu> btw why does NV20 emit RCC ?
18:26 < darktama> it's a vp1.1 instruction, and supported by NV20
18:27 < marcheu> ah, right, I thought it was 2.0
18:28 < darktama> also notice the read from R3, that's never written (in MAD).. user specified programs using MAD show correct results though
18:29 < marcheu> I wonder what this does
18:33 < marcheu> did you test point_size ?
18:33 < marcheu> that might be related
18:33 < darktama> on NV20?
18:34 < marcheu> yes
18:34 < pmdata> nv28 dumps updated on sf.net
18:35 < marcheu> I mean, c[0x3a/3b] have to do something
18:35 < darktama> no I didn't.. do we have a test for that?
18:35 < marcheu> nope
18:35 < marcheu> I mean, point size together with a vertex shader
18:36 < marcheu> I think there was something shady with that, maybe the had to do some workaround in the vertex program
18:36 < marcheu> or maybe that's unrelated
18:37 < darktama> well, from the disasm it looks like it overwrites result.position.. that doesn't seem right at all
18:38 -!- Myrizio [n=Myrizio@host38-101.pool80104.interbusiness.it] has quit [Read error: 110 (Connection timed out)]
18:40 < darktama> on top of that const 0x3a/0x3b is never uploaded..
18:40 < darktama> *but* user consts start from 0x60.. so perhaps <0x60 refers to some state
18:47 < marcheu> and what is R0 ?
18:47 < darktama> temp 0
18:48 < marcheu> but you have no idea what it is, in that context ?
18:48 < marcheu> semantically
18:49 < darktama> well, in this case I'd say undefined.. but here: http://sh.nu/p/2708
18:49 < darktama> it'd be vertex.position
19:18 -!- Myrizio [n=Myrizio@host56-98.pool80104.interbusiness.it] has joined #nouveau
19:23 < pmdata> darktama> could you checkout renouveau and rerun the anisotropy test?
19:26 < darktama> done
19:28 < pmdata> ok, anisotropy done
19:29 < darktama> did you notice the unknown bits in FILTER_UNIT changing too?
19:32 -!- Gloubi [n=Gloubi@ABordeaux-253-1-73-244.w83-200.abo.wanadoo.fr] has joined #nouveau
19:37 < pmdata> yep
19:37 < pmdata> I don't know what they are for
19:38 < darktama> fair enough, still unknown then :P
19:43 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
19:50 < Lumag> marcheu: btw, you once spoke about access to nv20 box. I think I'm free enough now :)
19:53 < pmdata> marcheu> and I need you put it in softquadro mode (the next time you reboot it)
19:53 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
19:54 -!- Unavowed [n=silent@host81-151-27-96.range81-151.btcentralplus.com] has quit ["leaving"]
20:47 -!- shenki [n=shenki@ppp175-149.lns3.adl4.internode.on.net] has joined #nouveau
21:01 -!- shenki [n=shenki@ppp175-149.lns3.adl4.internode.on.net] has quit [Read error: 60 (Operation timed out)]
21:08 -!- atcl [n=Universe@L9374.l.pppool.de] has joined #nouveau
21:16 -!- johane_ [n=johan@84-217-89-131.tn.glocalnet.net] has joined #nouveau
21:23 -!- johane__ [n=johan@84-217-89-131.tn.glocalnet.net] has quit [Read error: 60 (Operation timed out)]
21:56 < marcheu> Lumag: good !
21:56 < Lumag> :)
21:58 -!- sturmflut [n=sturmflu@2001:6f8:992:1337:213:d4ff:feaa:8a9f] has joined #nouveau
22:01 < sturmflut> How do I log in to the wiki? There is no "Login" button
22:02 < sturmflut> Just "Create Profile", "Cancel" and "Mail my account data"
22:02 < marcheu> would you guys prefer if I run the nv28 in quadro mode all the time ?
22:03 < marcheu> sturmflut: http://nouveau.freedesktop.org/wiki/?action=login
22:04 < sturmflut> Ah thanks, the "Login" Link should point to that URL!
22:11 < pmdata> marcheu> yep, would be better
22:16 < sturmflut> What is glClipPlane, Screen Clipping or Object Clipping?
22:30 < pmdata> object clipping
22:30 < pmdata> screen clipping is done with glViewport and glScissors
22:31 < pmdata> xmoto time
22:50 < pmdata> marcheu> in fact, I will not need the softquadro for the test I was planning
23:12 -!- svu [n=svu@194.46.173.108] has quit ["Ex-Chat"]
23:18 -!- svu [n=svu@194.46.173.108] has joined #nouveau
23:28 -!- johane__ [n=johan@84-217-89-131.tn.glocalnet.net] has joined #nouveau
23:29 < sturmflut> pmdata: Oh, you "macroized" my changes. Great. I'll do that myself for the next patches
23:33 < sturmflut> pmdata: What is mssing for NV20/NV30 Lighting and Object clipping to be marked as DONE in the feature matrix? I think I found most of the commands that are executed by the according tests, the only thing I couldn't figure out are the data formats for GL_SPOT_DIRECTION, GL_SPOT_CUTOFF and GL_SPOT_EXPONENT
23:37 -!- johane_ [n=johan@84-217-89-131.tn.glocalnet.net] has quit [Read error: 60 (Operation timed out)]
--- Log closed Втр Авг 15 00:00:14 2006
