--- Log opened Сбт Сен 09 00:00:34 2006
00:01 < marcheu> I don't think so
00:01 < marcheu> unless you count x86_64
00:06 -!- Myrizio [n=Myrizio@host124-98-static.104-80-b.business.telecomitalia.it] has joined #nouveau
00:26 < stillunknown> pmdata: congratulations on your commit :-)
00:27 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
00:31 -!- ag [i=ag@caladan.roxor.cx] has quit []
00:33 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
00:33 -!- svu [n=svu@83.167.239.56] has quit [Read error: 54 (Connection reset by peer)]
00:34 -!- svu [n=svu@83.167.239.56] has joined #nouveau
00:36 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
00:48 < pmdata> i'm trying to understand how nv10swtcl should be done, comparing against r200 one
00:49 < EdB> but nouveau on cvs is not the real noveau driver
00:50 < marcheu> EdB: hmm ?
00:50 < EdB> nouveau in not on git ?
00:50 < marcheu> no
00:51 < EdB> erf
00:51 < EdB> so i don't understantd what is on git and what is on cvs :o)
00:51 < marcheu> ddx and drm are in git
00:51 < EdB> may be it's the 3d part ?
00:51 < marcheu> dri is in cvs
00:51 < EdB> ok
00:51 < marcheu> yeah, dri is the 3D part
00:51 < EdB> don't give us the same damn :o)
00:51 < EdB> +name
00:52 < EdB> s/us/them
00:52 < pmdata> http://nouveau.freedesktop.org/wiki/UserStatus
00:54 < EdB> ok ok, i don't make my lesson
00:55 -!- EdB [n=EdB@ARennes-251-1-49-104.w81-53.abo.wanadoo.fr] has quit ["Konversation terminated!"]
01:06 -!- etzel [n=thisnuke@west-193.rcn.NMT.EDU] has quit [Remote closed the connection]
01:29 < darktama> marcheu: ok, while I still remember I'll add the copywrite notices.. do I have to add my name to all the files I've touched? or just the ones I created?
01:30 < darktama> copyright*
01:33 < marcheu> add your name as soon as there's a significant contribution, so I guess that means all files touched here
01:33 -!- open_source_nut [n=billalbr@dialup-4.255.205.17.Dial1.St.Louis1.Level3.net] has joined #nouveau
01:33 -!- open_source_nut [n=billalbr@dialup-4.255.205.17.Dial1.St.Louis1.Level3.net] has left #nouveau []
01:34 < marcheu> pmdata: hmm, I think we have to talk
01:34 -!- open_source_nut [n=billalbr@dialup-4.255.205.17.Dial1.St.Louis1.Level3.net] has joined #nouveau
01:35 < pmdata> I do only commits that can make it compilable, I don't know much about all this stuff
01:35 < marcheu> pmdata: unless I have a misunderstanding of the TCL mesa stuff, you removed the sw fallbacks in your first commit
01:35 -!- open_source_nut [n=billalbr@dialup-4.255.205.17.Dial1.St.Louis1.Level3.net] has left #nouveau []
01:35 -!- cetrox [i=cetrox@99-245-222-201.adsl.terra.cl] has quit [Remote closed the connection]
01:35 -!- cetrox [i=cetrox@99-245-222-201.adsl.terra.cl] has joined #nouveau
01:36 -!- phh [n=phh@moi.phhusson.info] has quit [Read error: 104 (Connection reset by peer)]
01:37 < marcheu> also for the specular thing, the hw has specular color, se we don't need the specular color emulation stuff
01:37 < pmdata> I understand what you mean
01:37 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau
01:37 < marcheu> yeah, we can't directly map the radeon/mga/intel stuff to our code
01:38 < marcheu> there are a couple of differences :
01:38 < marcheu> - nvidia cards handle a lot more vertex attributes (namely : all) se we don't need fallbacks in a lot of case 
01:38 < marcheu> - we submit all vertex attributes as fp32 and the card gets fp32 as well, so we don't need conversions
01:39 < phh> marcheu, that's why ati nvidia cards looks quicker on glxgears but not on true game ?
01:39 < phh> oula
01:40 < marcheu> phh: hm ?
01:40 < phh> marcheu, I always saw glxgears FPS higher on ATI than on nVidia (on ATI it's something around 8000FPS whereas 3000 on nVidia or something like)
01:40 -!- open_source_nut [n=billalbr@dialup-4.255.205.17.Dial1.St.Louis1.Level3.net] has joined #nouveau
01:41 -!- open_source_nut [n=billalbr@dialup-4.255.205.17.Dial1.St.Louis1.Level3.net] has quit ["Leaving."]
01:42 < marcheu> pmdata: one thing you could easily for starting with the tcl code is the                 // XXX needs some love
01:42 < pmdata> we'll always need sw fallback (for <nv10 cards)
01:43 -!- open_source_nut [n=billalbr@dialup-4.255.205.17.Dial1.St.Louis1.Level3.net] has joined #nouveau
01:43 < marcheu> no, <nv10 cards will be handled by another nv04_swtcl.c file
01:43 < pmdata> so why should I care about sw fallback  on nv10?
01:43 < marcheu> these are features that nv10 can't accelerate
01:44 < marcheu> usually things like double sided stencil, or weird line drawing modes...
01:46 < marcheu> ok, I'll explain you the full TCL stuff, so that you can get started
01:46 < marcheu> in mesa we have something called t_vertex which is quite powerful. it lets you describe the vertex format that your hw wants
01:46 < marcheu> and then mesa feeds you vertices in that format
01:47 < marcheu> each vertex has components of all kinds. we only care about floats here since that's the only thing the hardware likes
01:47 < darktama> I think nv40 can handle UBYTE too, at least in vertex buffers
01:48 < marcheu> when you see something like v0->f[X] it means the floating point attributes of the vertex
01:50 < marcheu> so the t_vertex has to know the vertex format
01:50 < marcheu> in nv10OutputVertexFormat(), we describe the current vertex format from the enabled vertex attributes, both to the hw and to mesa
01:50 -!- open_source_nut [n=billalbr@dialup-4.255.205.17.Dial1.St.Louis1.Level3.net] has quit [Nick collision from services.]
01:50 < marcheu> to mesa using EMIT_ATTR
01:50 < marcheu> and to the hw using the hw commands we know that describe the vertex format
01:52 < marcheu> finally, for rendering, you get your vertex attributes in the format you asked to mesa, and feed them to the hw
01:53 < pmdata> hu hu
01:53 < marcheu> since we are sent floats, and the hw want floats, it's a simple copy for us (see nv10_draw_triangle for example)
01:54 < pmdata> found that xxx needs love
01:54 < marcheu> yeah, that's one thing that can be easily written I think
01:55 < marcheu> it has to describe the vertex attributes to the nv10 hw
01:56 < marcheu> so you still have to add back some of the old code :)
01:57 < pmdata> found that nv10_draw_triangle
01:57 < marcheu> yep
01:57 < marcheu> so it writes to the fifo directly
01:57 < marcheu> it's pretty simple
01:57 -!- open_source_nut [n=billalbr@dialup-4.245.38.216.Dial1.StLouis1.Level3.net] has joined #nouveau
01:58 < marcheu> darktama: all cards can handle all kind of attributes, however, fp32 is what's used most of the time. I guess we'll care about other formats when we're not using sw TCL anyway :)
01:59 < darktama> ah :)
01:59 < marcheu> yeah, nv10_swtcl.c is for software tcl 
01:59 < marcheu> the rest will have to be written later...
01:59 -!- gnarlin [n=gnarlin@194-144-217-11.du.xdsl.is] has joined #nouveau
01:59 < darktama> it seems like we're getting close to starting on the DRI driver properly.. guess I should get my backside into gear and write the shader stuff for >=nv40
02:00 < marcheu> not urgent if ou ask me.. we're working on nv1x for now anyway (at least pmdata and me are)
02:00 -!- etzel [n=thisnuke@west-193.rcn.NMT.EDU] has joined #nouveau
02:01 < darktama> true :)  but if I want 3D, we need it!
02:02 < marcheu> I'm not sure yet what interface(s) we'll implement WRT hw tcl
02:03 < darktama> I'm not real familiar with how the mesa vtx pipeline works.. I somehow managed the initial vertex buffer stuff for r300, but I really had nfi what I was doing
02:04 < marcheu> the vtx pipeline is very powerful, plus it putputs everything as floats which is good for us
02:04 < marcheu> outputs*
02:05 < darktama> I guess I should have a poke around the other drivers and see how things work
02:06 < marcheu> well, 2 ways
02:06 < marcheu> either use the mesa's maos stuff, which feeds us vertex arrays through mesa
02:06 < marcheu> or hook at the gl function level directly
02:07 < darktama> is the second way the way the "vtxfmt" path in radeon works?
02:09 < marcheu> yes
02:09 < darktama> what's the benefits/drawbacks of each method?
02:10 < marcheu> well, I'm biased
02:10 < marcheu> but the maos code converts stuff up to 3 times on radeon 
02:10 < marcheu> for example if the app sends data as ubytes
02:11 < marcheu> ubytes -> int32 (in the mesa pipeline) -> ubyte (out of the pipeline) -> int16 (to the card)
02:11 < marcheu> or something like that
02:11 < marcheu> that for array indices
02:12 < marcheu> OTOH, the nvidia cards seem feature-complete enough that we can easily have full opengl compliance with few complex corner cases
02:12 -!- Duke` [n=gnu@ANantes-251-1-129-250.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:12 < marcheu> but really hooking gl entry points that was not intended at first
02:13 < marcheu> I suppose we should look at what 3D engines actually do to fire vertices
02:13 < marcheu> and what they don't do, and fallback, maybe even to sw tcl
02:14 < darktama> what do you mean by "what 3D engines actually do to fire vertices"?
02:14 < marcheu> what opengl command they use
02:15 < pmdata> marcheu> should I output the new vertex array format using command d00-d3c, or just fill the vertex array with the datas?
02:15 < marcheu> like glDrawArrays, or glVertex*, or vertex buffers...
02:15 < darktama> ah
02:16 < marcheu> pmdata: yeah, you have to send the hw the format using thos commands
02:17 < pmdata> so the vertex attribute format, the offset in nvmem, the cf0 command to validate the format and the datas?
02:17 < marcheu> nope, only the vertex format
02:18 < marcheu> hmm, maybe you'd need cf0 on nv10
02:19 < marcheu> follow what you see in renouveau, there's a reason I didn't to it, it's because I don't know how it works for nv10 :)
02:20 < pmdata> well, (attribute format+offset) for each vertex component (pos,col0,col1,fog,wgh,nor,tx0,tx1) then cf0
02:20 < marcheu> ok, then that's it
02:21 < darktama> marcheu: btw, the NV30_UNKNOWN_0 (0x1718) stuff doesn't appear to be needed, I have no idea what it is
02:22 < pmdata> how do I know where to peek the offset? and what each vertex attribute is?
02:23 < marcheu> what offset ? there's no offset, it's the immediate mode vertex format
02:23 < marcheu> I thought it was the same as the array format, except you don't set offsets
02:23 < marcheu> again, I might be wrong, I didn't do much on nv10
02:23 < pmdata> ah ok
02:23 -!- jkolb [n=jkolb@wsi-128-132.wsi.com] has quit ["Leaving"]
02:26 < pmdata> so where should I read values from, and know what they are to fill the right command?
02:27 < marcheu> open_source_nut: really, you should stop sending private messages for stuff that's not private
02:27 < marcheu> pmdata: hmm, look at what's done for nv20/nv30
02:27 < marcheu> it's almost the same
02:27 < marcheu> (albeit not exactly, because you have to convert the mesa vertex parameters into nv10 ones)
02:28 < pmdata> this is my problem
02:28 < marcheu> pmdata: for now, the previous code fills up an array attr_size with the number of float for each attribute
02:28 < marcheu> these 16 entries follow the nv_vertex_program convention
02:28 < marcheu> HOWEVER
02:28 < open_source_nut> marcheu: oh?
02:29 < marcheu> that's a bit outdated with recent mesa changes, so I'm not sure if some changes are needed or not
02:29 < open_source_nut> marcheu: so you want me to ask that same question again here in the channel?
02:29 < marcheu> in particular to the first part filling that "Determine attribute sizes"
02:29 < marcheu> open_source_nut: well, that would be the appropriate place
02:30 < marcheu> open_source_nut: really, I have very few time atm
02:30 < pmdata> this does not suits nv10, because it has pos3f,pos4f,nor3f,nor3i,col4f,col4f,col3i,etc...
02:30 < marcheu> pmdata: which regs are you speaking of ?
02:30 -!- Unavowed [n=silent@13.t6.ds.pwr.wroc.pl] has quit ["leaving"]
02:30 < open_source_nut> what does nvidia say about this project? how do they like it or dislike it? 
02:31 < darktama> I don't think they've acknowledged we exist..
02:31 < open_source_nut> lol
02:31 < open_source_nut> well would the become upset or somthing with this project and change thier specs or something?
02:32 < marcheu> pmdata: the thing from 0x00000c00 to 0x00000cec ? these are the default attribute values
02:32 < darktama> well, they can't really change them for the cards that already exist - and, the current design of their GPUs is quite good.. it'd be a waste to change it
02:32 -!- predatorfreak [n=predator@adsl-69-212-52-66.dsl.sfldmi.ameritech.net] has joined #nouveau
02:32 < marcheu> pmdata: here, we're talking about describing the attributes format, like "the vertices I am going to send have 3 floats for pos, 4 for color and 2 for texture0"
02:32 < stillunknown> open_source_nut: there's no reason for them to get upset (it will do no good)
02:33 < open_source_nut> oh cool
02:33 < open_source_nut> why doesent nvidia just open up?
02:33 < open_source_nut> open thier specs and source
02:33 < darktama> you'd have to ask them that..
02:33 < open_source_nut> ask them? lol they would ignore me asking them
02:34 < stillunknown> they don't say, but there could be various reasons
02:34 < open_source_nut> what about ati and them opening up?
02:35 < gnarlin> actually I think they have said on several occations that it is mostly due to having third party licensed code and not wanting to give up their "competitive advantage"
02:35 < gnarlin> nvidia that is
02:35 < marcheu> pmdata: got it ?
02:35 < marcheu> pmdata: or is it too late ?
02:35 < stillunknown> open_source_nut: ati has already denied that
02:36 < open_source_nut> stillunknown:  that they will open up after amd bougth them?
02:36 < pmdata> I still don't get it, sorry, I don't see how it should be done
02:36 < open_source_nut> stillunknown:  they denied that they will do that?
02:37 < stillunknown> i lack the source url, but it boiled to this:
02:37 < pmdata> nv10 has either immediate format (where you send vertex attribute values in a command) or vertex array format
02:38 < stillunknown> Amd will make open source drivers were it is considered neccesary, but will not in areas were it is not. (pretty much what they do already)
02:39 < marcheu> pmdata: hmm, do you have a dump of a simple glBegin(GL_TRIANGLES);3*glVertex();glEnd() on nv10 ?
02:41 < pmdata> http://nouveau.sourceforge.net/tests/nv15/card_10de-0151_test_default.txt
02:41 -!- phh [n=phh@moi.phhusson.info] has quit [Remote closed the connection]
02:42 < marcheu> pmdata: so, when you do that, you have a series of NV10_TCL_PRIMITIVE_3D_VERTEX_ARRAY_FORMAT_*
02:42 < marcheu> which are not only used for vertex arrays, but also for immediate vertices (which is why I don't like their naming btw)
02:45 < marcheu> pmdata: ok ?
02:45 < pmdata> mostly, I can have up to 8 attributes (pos,col,col2,tx0,tx1,nor,wgh,fog) edge flag is not in vertex array
02:45 < marcheu> so the code that needs to be where there is "needs some love" is the code that creates this stuff
02:46 < marcheu> and yeah, there are 16 inputs, and 8 outputs. so not everything will fit
02:46 < marcheu> you have to map stuff form the nv_vertex_program extension to the nv10 vertex format attributes
02:49 < pmdata> 'slots' is the number of attributes?
02:49 < marcheu> well, it's the number of the highest-enabled attribute -1 IIRC
02:50 < marcheu> yup
02:50 < marcheu> that's probably not useful for nv10
02:50 < marcheu> where you'll have to remap everything anyway, and you send separate commands
02:50 < stillunknown> open_source_nut: but maybe i'm being too pessimistic
02:50 < stillunknown> goodnight people
02:56 < pmdata> do I need to set the 'stride' value for the command to the vertex size?
02:57 < darktama> on NV40, you only need it for vertex buffers, but not immediate vertices.. probably the same on nv10?
03:07 < pmdata> this is always non zero, except sometimes :)
03:07 -!- open_source_nut [n=billalbr@dialup-4.245.38.216.Dial1.StLouis1.Level3.net] has left #nouveau []
03:07 < darktama> haha, I like that! "always, except sometimes" :)
03:14 < pmdata> to be more precise: when a component is not used, =(number of values)*4 except for col and col2 which are set to 0
03:20 < pmdata> marcheu> hope I got it right, commited to cvs, bed time now
03:20 < marcheu> well, you'll fix it if it's wrong anyway ;p
03:22 -!- pmdata [i=patrice@ANantes-154-1-70-91.w86-195.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
03:23 < darktama> hmm, I wonder why NV30 has fragprog opcodes for LIT (etc) and NV40 doesn't..
03:51 -!- Unbeliever is now known as K_zzzZZ
03:52 -!- tibbs|h is now known as tibbs
04:05 -!- K_zzzZZ [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
05:11 -!- cetrox [i=cetrox@99-245-222-201.adsl.terra.cl] has quit [Remote closed the connection]
05:11 -!- cetrox [i=cetrox@99-245-222-201.adsl.terra.cl] has joined #nouveau
05:11 -!- predatorfreak [n=predator@adsl-69-212-52-66.dsl.sfldmi.ameritech.net] has quit [Remote closed the connection]
05:12 -!- predatorfreak [n=predator@adsl-69-212-52-66.dsl.sfldmi.ameritech.net] has joined #nouveau
05:13 < marcheu> on #nvidia :
05:13 < marcheu> 01:46 < aaronp> Blissex: All of the actual OpenGL rendering code lives in libGLcore.so.1.
05:14 < marcheu> 01:51 < aaronp> Nope.  The kernel module contains no OpenGL.  It *does* contain a lot of hardware interface code, but it's not OpenGL-specific.
05:14 < marcheu> 01:52 < aaronp> In fact, the exact same kernel code is used by DirectX.
05:15 < tibbs> I just have a hard time believing there's 4.5MB of hardware interface code.
05:15 < marcheu> depends where you split, I guess
05:25 < darktama> 4.5MB does seem a bit large for what the module actually does
05:44 -!- jkolb [n=jkolb@c-71-232-160-124.hsd1.ma.comcast.net] has joined #nouveau
06:13 -!- cetrox [i=cetrox@99-245-222-201.adsl.terra.cl] has quit [Remote closed the connection]
06:19 -!- cetrox [i=cetrox@99-245-222-201.adsl.terra.cl] has joined #nouveau
06:24 -!- Myrizio [n=Myrizio@host124-98-static.104-80-b.business.telecomitalia.it] has quit [Read error: 113 (No route to host)]
06:44 < jkolb> how do i pull the drm and ddx?
06:44 < jkolb> i don't remember the git syntax
06:50 < jkolb> nm. got it
06:52 < jkolb> not sure how to get the drm module
06:52 < jkolb> got the ddx though
07:23 -!- etzel [n=thisnuke@west-193.rcn.NMT.EDU] has quit [Remote closed the connection]
07:25 -!- open_source_nut [n=billalbr@dialup-4.245.34.149.Dial1.StLouis1.Level3.net] has joined #nouveau
07:25 -!- etzel [n=thisnuke@west-193.rcn.NMT.EDU] has joined #nouveau
07:37 -!- open_source_nut [n=billalbr@dialup-4.245.34.149.Dial1.StLouis1.Level3.net] has left #nouveau []
10:10 -!- cetrox_ [i=cetrox@57-246-222-201.adsl.terra.cl] has joined #nouveau
10:25 -!- cetrox [i=cetrox@99-245-222-201.adsl.terra.cl] has quit [Read error: 110 (Connection timed out)]
10:53 -!- KoalaBR_ [n=KoalaBR@port-83-236-12-39.dynamic.qsc.de] has joined #nouveau
10:53 < KoalaBR_> Hello
11:11 -!- gnarlin [n=gnarlin@194-144-217-11.du.xdsl.is] has quit ["leaving"]
11:24 -!- KoalaBR_ [n=KoalaBR@port-83-236-12-39.dynamic.qsc.de] has quit [Remote closed the connection]
11:37 -!- Duke` [n=gnu@ANantes-251-1-129-250.w86-210.abo.wanadoo.fr] has joined #nouveau
11:39 -!- pmdata [i=patrice@ANantes-154-1-12-221.w81-53.abo.wanadoo.fr] has joined #nouveau
12:05 -!- predatorfreak [n=predator@adsl-69-212-52-66.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
12:08 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau
12:10 -!- predatorfreak [n=predator@adsl-69-212-52-66.dsl.sfldmi.ameritech.net] has joined #nouveau
12:32 -!- predatorfreak [n=predator@adsl-69-212-52-66.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
12:50 -!- Aexoden [n=Aexoden@uranus.aexoden.com] has quit [Remote closed the connection]
13:10 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
13:13 -!- zoeloelip [n=bart@d54C0400B.access.telenet.be] has quit [Read error: 110 (Connection timed out)]
13:21 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
13:56 < stillunknown> jkolb: i think you need to checkout mesa drm and add the word as a parameter nouveau-1
13:57 < stillunknown> or git checkout nouveau-1
13:57 < stillunknown> if you already checked out the normal drm
13:57 < stillunknown> http://www.freedesktop.org/wiki/UsingGit
14:02 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
14:33 -!- EdB [n=EdB@ARennes-251-1-99-229.w86-199.abo.wanadoo.fr] has joined #nouveau
14:37 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
15:04 -!- Myrizio [n=Myrizio@host184-98-static.104-80-b.business.telecomitalia.it] has joined #nouveau
15:13 -!- phh [n=phh@moi.phhusson.info] has quit [Read error: 110 (Connection timed out)]
15:20 -!- Aexoden [n=Aexoden@uranus.aexoden.com] has joined #nouveau
16:08 -!- EdB [n=EdB@ARennes-251-1-99-229.w86-199.abo.wanadoo.fr] has quit ["Konversation terminated!"]
16:11 -!- KoalaBR_ [n=KoalaBR@port-83-236-12-28.dynamic.qsc.de] has joined #nouveau
16:16 -!- Myrizio [n=Myrizio@host184-98-static.104-80-b.business.telecomitalia.it] has quit [Read error: 104 (Connection reset by peer)]
16:17 < KoalaBR_> marcheu: Help
16:23 -!- pmdata [i=patrice@ANantes-154-1-12-221.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
16:25 -!- marteus [n=marteus@0x503fbab3.albnxx8.adsl-dhcp.tele.dk] has joined #nouveau
16:36 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:38 < jkolb> stillunknown: thanks, git checkout nouveau-1 did it
16:38 -!- darktama [n=darktama@gentoo/contributor/darktama] has quit [Remote closed the connection]
16:38 -!- darktama [n=darktama@gentoo/contributor/darktama] has joined #nouveau
16:57 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
17:16 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
17:49 < darktama> KoalaBR_: a slight correction, the nvidia module wasn't loaded at all when the EXA-on-3D code was runnig
17:49 < darktama> running*
17:50 < darktama> X has to be started with nvidia's driver beforehand, but you can rmmod nvidia.ko just fine
17:50 < jkolb> what's the difference between fifo and pfifo?
17:51 < darktama> FIFO is the regs that an app using the hw can access to say "I've got commands that need to be run".  PFIFO is regs that control what user FIFO is being executed by the card at a particular time
17:52 < jkolb> so the pfifo is the pointer to the current fifo?
17:53 < darktama> sort of, but it's more than that.. the PFIFO regs also say where the object hash table is and a few other things
17:53 < jkolb> ok
17:53 < jkolb> so sort of a fifo context or something
17:56 < darktama> the main purpose seems to be to point the hardware at the current user FIFO, and to control the RAMIN area.. but, I don't think we know much more of that
17:56 < jkolb> ok
17:56 < jkolb> the drm doesn't look that complicated
18:05 -!- cetrox_ is now known as cetrox
18:06 -!- KoalaBR_ [n=KoalaBR@port-83-236-12-28.dynamic.qsc.de] has quit [Remote closed the connection]
18:28 -!- Myrizio [n=Myrizio@host50-98-static.104-80-b.business.telecomitalia.it] has joined #nouveau
18:32 -!- EdB|w_ [n=EdB@212.234.68.206] has quit ["Parti"]
18:39 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau
18:54 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has quit [Read error: 60 (Operation timed out)]
19:01 -!- phh [n=phh@moi.phhusson.info] has quit ["Quitte"]
19:01 -!- shenki [n=shenki@ppp110-122.lns4.adl4.internode.on.net] has joined #nouveau
19:14 -!- jkolb_ [n=jkolb@wsi-128-132.wsi.com] has joined #nouveau
19:24 -!- `Duke` [n=gnu@ANantes-251-1-175-153.w90-12.abo.wanadoo.fr] has joined #nouveau
19:31 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
19:40 -!- Duke` [n=gnu@ANantes-251-1-129-250.w86-210.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
19:50 -!- shenki [n=shenki@ppp110-122.lns4.adl4.internode.on.net] has quit ["http://xkcd.com/comics/fourier.jpg"]
20:40 -!- EdB [n=EdB@ARennes-251-1-91-200.w86-199.abo.wanadoo.fr] has joined #nouveau
21:09 -!- pmdata [i=patrice@ANantes-154-1-94-23.w86-210.abo.wanadoo.fr] has joined #nouveau
21:19 -!- Unavowed [n=silent@13.t6.ds.pwr.wroc.pl] has joined #nouveau
21:41 -!- svu [n=svu@83.167.239.56] has quit [Remote closed the connection]
21:43 -!- pmdata [i=patrice@ANantes-154-1-94-23.w86-210.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
21:44 -!- pmdata [i=patrice@ANantes-154-1-94-23.w86-210.abo.wanadoo.fr] has joined #nouveau
21:44 -!- pmdata [i=patrice@ANantes-154-1-94-23.w86-210.abo.wanadoo.fr] has quit [Client Quit]
21:46 -!- stringfellow [n=stringfe@ip545711d4.direct-adsl.nl] has joined #nouveau
22:01 -!- K is now known as Unbeliever
22:01 -!- pmdata [i=patrice@ANantes-154-1-94-23.w86-210.abo.wanadoo.fr] has joined #nouveau
22:04 -!- Myrizio [n=Myrizio@host50-98-static.104-80-b.business.telecomitalia.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
22:06 -!- nano- [i=nano@83.140.162.43] has quit [Remote closed the connection]
22:06 -!- nano- [i=nano@exodus.xmms.se] has joined #nouveau
22:08 -!- pmdata [i=patrice@ANantes-154-1-94-23.w86-210.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
22:10 -!- jkolb_ [n=jkolb@wsi-128-132.wsi.com] has quit ["Leaving"]
22:14 -!- predatorfreak [n=predator@adsl-69-212-52-66.dsl.sfldmi.ameritech.net] has joined #nouveau
22:32 -!- stringfellow [n=stringfe@ip545711d4.direct-adsl.nl] has quit [Remote closed the connection]
22:35 -!- svu [n=svu@83.167.239.56] has joined #nouveau
22:58  * darktama listens to the crickets
23:13 -!- stringfellow [n=stringfe@a80-100-96-220.adsl.xs4all.nl] has joined #nouveau
23:20 -!- jkolb_ [n=jkolb@wsi-128-132.wsi.com] has joined #nouveau
23:32 -!- stringfellow [n=stringfe@a80-100-96-220.adsl.xs4all.nl] has quit [Remote closed the connection]
23:43 -!- jkolb_ [n=jkolb@wsi-128-132.wsi.com] has quit ["Leaving"]
--- Log closed Вск Сен 10 00:00:34 2006
