--- Log opened Пнд Июл 17 00:00:52 2006
00:10 -!- qfire is now known as qfire_away
00:13 -!- EdB [n=EdB@ARennes-251-1-89-170.w86-199.abo.wanadoo.fr] has quit [Remote closed the connection]
00:13 -!- EdB [n=EdB@ARennes-251-1-89-170.w86-199.abo.wanadoo.fr] has joined #nouveau
00:22 -!- blx [n=x@h132n1c1o1028.bredband.skanova.com] has joined #nouveau
00:25 -!- EdB [n=EdB@ARennes-251-1-89-170.w86-199.abo.wanadoo.fr] has quit ["Konversation terminated!"]
00:30 < pmdata> hi blx, did you manage to do something with renouveau?
00:34 < blx> pmdata, not yet. i have been working this weekend mostly, but i'm reading up on the wiki
00:50 < pmdata> marcheu> I got segfaults now in renouveau when using __GL_FSAA_MODE
00:50 < marcheu> pmdata: did you get all 6 clip to work ?
00:50 < marcheu> hmm, interesting
00:50 < marcheu> 6 clip planes
00:51 < pmdata> they should work, I did not test them, do you know why they can be GL_EYE_LINEAR or GL_OBJECT_LINEAR?
00:51 < marcheu> either object space or screen space ?
00:52 < pmdata> maybe
00:52 < marcheu> but did you trigger all 6 clip planes with renouveua ?
00:52 < pmdata> no
00:52 < pmdata> fsaa> renouveau segfault in dump_after(), a memcpy() operation
00:52 < marcheu> do you have a backtrace ?
00:53 < marcheu> also, what __GL_FSAA_MODE value ?
00:54 < pmdata> 3 and 4
00:55 < pmdata> (1.5x1.5 and 2x2 fsaa)
00:55 < pmdata> 		printf("==========================\n");
00:55 < pmdata> 		printf("Mapping %d ",i);
00:55 < pmdata> it crashes before printing that
00:56 < pmdata> but all maps are printed correctly
01:00 < pmdata> ah, this is the memcpy() in the first loop of dump_after()
01:01 < pmdata> found it: map 6   from 0x41f37000 to 0x41fa3000 size 0x6c000 (physical 0xdbf60000) => registers
01:02 < pmdata> this one triggers the segfault when doing memcpy()
01:02 < marcheu> size 0x6c000 ?
01:02 < marcheu> what winwod size are you using ?
01:03 < pmdata> 256x256
01:03 < marcheu> at 1.5 AA I guess
01:04 < pmdata> it would be 384x384 then
01:04 < marcheu> yup
01:04 < marcheu> it looks like a 384*384*RGB buffer
01:04 < pmdata> the size is the same when not setting fsaa
01:05 < pmdata> and the same with 2x2 fsaa
01:05 < marcheu> hmm, I don't quite understant
01:05 < marcheu> is that buffer always the same size ?
01:06 < marcheu> I would've expected it to be the window before rescaling
01:06 < pmdata> w and h are always 256x256, but changing fsaa_mode this map size is always the same
01:07 < marcheu> weird
01:07 < pmdata> the maplist.txt file is not used by renouveau, just outputted?
01:07 < marcheu> it's written, and then read from
01:08 < pmdata> I tried deleted it between runs, no change
01:08 < marcheu> it should be printed on screen anyway
01:09 < pmdata> yep, always 6c000
01:11 < pmdata> is it normal I have 2 mappings to same physical location?
01:11 < pmdata> map 6	from 0x41f37000 to 0x41fa3000 size 0x6c000 (physical 0xdbf60000)	=> registers
01:11 < pmdata> map 7	from 0x41fa3000 to 0x4200f000 size 0x6c000 (physical 0xdbf60000)	=> registers
01:13 < marcheu> well, it's not something impossible
01:14 < marcheu> but it's probably useless
01:19 < pmdata> I disable the memcpy() and later print  for registers space, and does not crash
01:22 < pmdata> anyway, I think I made enough stuff for this 3days weekend :)
01:22 < marcheu> yeah, you're going to need a new card :)
01:23 < pmdata> there are still some unknown commands for the nv10_tcl_primitive_3d
01:23 < marcheu> heh, maybe it's useless stuff..
01:24 < pmdata> there are also some unknown bits in commands that are set
01:24 < marcheu> yeah, well 
01:25 < marcheu> again, if we can't trigger those, they're probably not too useful
01:26 < pmdata> ah, I did not try texture compression, will have to check that
01:26 < marcheu> that one is interesting, although there's a patent issue on it
01:26 < marcheu> which prevents mesa from having compressed texture support
01:26 < pmdata> command 208 seems to be the framebuffer setup (pitch, address, etc...)
01:26 < marcheu> ah, good. that one is needed
01:27 < pmdata> I should also try more buffer stuff
01:27 < pmdata> it was a bit hard to find how the fog linear equation was setup
01:28 < pmdata> I still don't found the one for exp and exp2
01:28 < marcheu> do you think there's hw support for that ?
01:30 < pmdata> yep, the equation is just setup differently using same registers
01:31 < pmdata> a good thing the equation is printed in the opengl doc
01:31 -!- `Duke` [n=gnu@ANantes-251-1-138-122.w86-210.abo.wanadoo.fr] has joined #nouveau
01:33 < pmdata> command 2c0 and 2e0 are strange
01:33 < pmdata> the value is 0x08000800
01:33 < pmdata> 2c0 then is + width<<16, and 2e0 is +height<<16
01:34 < pmdata> maybe the clipping value for drawing?
01:35 < pmdata> 0x800 = 2048, and the hardware can not have a bigger size for width or height
01:36 < pmdata> yep, I think they are clipping value for drawing (glviewport? glscissors? anything else?)
01:37  * pmdata to bed now after 3 days of code \O/
01:37 -!- pmdata [i=patrice@ANantes-154-1-63-246.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:48 -!- Duke` [n=gnu@ANantes-251-1-134-93.w86-210.abo.wanadoo.fr] has quit [Connection timed out]
02:07 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
02:09 -!- `Duke` [n=gnu@ANantes-251-1-138-122.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
10:11 -!- xaid [n=Xaid@d199-126-140-132.abhsia.telus.net] has joined #nouveau
10:54 -!- xaid [n=Xaid@d199-126-140-132.abhsia.telus.net] has quit [Read error: 104 (Connection reset by peer)]
11:59 -!- Unavowed [n=silent@host81-158-183-57.range81-158.btcentralplus.com] has joined #nouveau
12:28 -!- shenki [n=shenki@ppp168-239.lns3.adl4.internode.on.net] has quit ["Cya!"]
12:54 -!- Duke` [n=gnu@ANantes-251-1-138-122.w86-210.abo.wanadoo.fr] has joined #nouveau
13:56 -!- EdB [n=EdB@ARennes-251-1-26-4.w81-250.abo.wanadoo.fr] has joined #nouveau
14:32 < Colbert> MIght be making progress on the framebuffer investigation.
14:34 < Colbert> With double buffer enabled i saw these differences between GL_FRONT and GL_FRONT_LEFT
14:34 < Colbert> GL_FRONT_LEFT
14:34 < Colbert> 1b8   0x00000000   0x44000000            NV10_TCL_PRIMITIVE_3D      [0x163c/4] = 0x44000000 | UNKNOWN = 44000000
14:34 < Colbert> 1bf   0x00000000   0x02000000            NV10_TCL_PRIMITIVE_3D      [0x0204/4] = 0x02000000 | UNKNOWN = 02000000
14:34 < Colbert> 1d5   0x00000000   0x09ff0800            NV10_TCL_PRIMITIVE_3D      [0x02e0/4] = 0x09ff0800 | UNKNOWN = 09ff0800
14:34 < Colbert> 277   0xc4e00104   0xc4e00104            NV10_TCL_PRIMITIVE_3D      [0x06ec/4] = 0xc4e00104 | UNKNOWN = c4e00104
14:34 < Colbert> GL_FRONT
14:34 < Colbert> 1b8   0x00000000   0x44004000            NV10_TCL_PRIMITIVE_3D      [0x163c/4] = 0x44004000 | UNKNOWN = 44004000
14:34 < Colbert> 1bf   0x00000000   0x02000001            NV10_TCL_PRIMITIVE_3D      [0x0204/4] = 0x02000001 | UNKNOWN = 02000001
14:34 < Colbert> 1d5   0x00000000   0x0a000801            NV10_TCL_PRIMITIVE_3D      [0x02e0/4] = 0x0a000801 | UNKNOWN = 0a000801
14:34 < Colbert> 277   0xc4e00104   0xc4dfe104            NV10_TCL_PRIMITIVE_3D      [0x06ec/4] = 0xc4dfe104 | UNKNOWN = c4dfe104
14:35 < Colbert> Dont see this with double buffer disabled though.
14:41 -!- Lumag_ [n=lumag@ptr65.lumag.pp.ru] has joined #nouveau
14:43 -!- Lumag_ is now known as Lumag
14:43 < Lumag> hi!
14:45 < Lumag> I'm examining blending on my Vanta. I was able to trigger most modes of blending bug GL_DST_ALPHA. Are there some known problems with it?
14:57 < Lumag> Looks really weird. nvglx always passes GL_ONE instead of GL_DST_ALPHA
15:01 < Colbert> lumag heres one link:
15:01 < Colbert> http://www.quakesrc.org/forums/viewtopic.php?t=1987&view=next&sid=359e2fb3c3a0ad19a1a64ed87c67c98d
15:02 < Colbert> should have read it before i sent this. not useful
15:03 < Lumag> :)
15:04 < Colbert> google NOT to the rescue
15:05 -!- EdB [n=EdB@ARennes-251-1-26-4.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
15:06 -!- jkolb [n=jkolb@209-6-112-224.c3-0.wth-ubr1.sbo-wth.ma.cable.rcn.com] has quit ["Client exiting"]
15:15 < Lumag> Also I can't enable GL_SRC_ALPHA_SATURATE
15:41 < Colbert> Lumag, can a vanta do opengl in 32 bit color? or is it like the old 3dfx's ie. always in 16 bit color?
15:41 < Lumag> A8R8G8B8 :)
15:42 < Colbert> ok, not what i thought then. nevermind
16:01 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
17:10 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
17:21 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
18:12 -!- _Demo_ [n=Demo@modemcable206.154-131-66.mc.videotron.ca] has joined #nouveau
18:32 -!- darktama [n=darktama@gentoo/contributor/darktama] has quit [Remote closed the connection]
18:32 -!- darktama [n=darktama@gentoo/contributor/darktama] has joined #nouveau
18:33 -!- qfire_away [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit [Read error: 104 (Connection reset by peer)]
18:33 -!- qfire_away [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
18:47 < Colbert> this is making my head hurt. need a nap
18:47  * Colbert is away: Colbert
18:48 -!- Colbert is now known as Colbert_naptime
19:01 -!- EdB|w_ [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
19:53 -!- Aexoden [n=Aexoden@207-118-66-169.dyn.centurytel.net] has quit [Read error: 104 (Connection reset by peer)]
19:56 -!- Aexoden [n=Aexoden@207-118-66-169.dyn.centurytel.net] has joined #nouveau
20:02 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:15 -!- Unavowed [n=silent@host81-158-183-57.range81-158.btcentralplus.com] has quit [Read error: 110 (Connection timed out)]
20:16 -!- EdB [n=EdB@ARennes-251-1-86-20.w86-199.abo.wanadoo.fr] has joined #nouveau
20:20 -!- shenki [n=shenki@ppp168-239.lns3.adl4.internode.on.net] has joined #nouveau
21:14 -!- pmdata [i=patrice@ANantes-154-1-21-100.w81-53.abo.wanadoo.fr] has joined #nouveau
21:17 < pmdata> hello people
21:57 < Lumag> hi
23:03 < pmdata> anyone know where I can find some example compressed textures?
23:04 < pmdata> it seems feeding it with random texture data does not work
23:04  * pmdata  trying gl_ext_texture_compression_s3tc
23:05 < pmdata> I guess your answer is 'google' then :)
23:06 < marcheu> look into the mesa tests, there's one
23:07 < marcheu> Mesa/progs/tests
23:09 < pmdata> before trying, I must say that non-compressed(standard) textures are stored in object type 0x39
23:10 < marcheu> yeah
23:10 < pmdata> whereas compressed ones are in object type 0x89 (nv_memory_to_memory_format)
23:10 < marcheu> I think most things are stored in 39
23:10 < marcheu> 89 is scaled image
23:11 < pmdata> maybe there is also some flag for compression then
23:11 < pmdata> do you know which other function use object type 89?
23:11 < marcheu> I don't think the compression is done on the gpu
23:11 < pmdata> s/compression/compressed format/
23:11 < pmdata> gpu must decompress it
23:11 < marcheu> 89 is used a lot on nv20+
23:12 < marcheu> yup, but the compression code is patented, and that's why we can't have it into mesa
23:12 < marcheu> if the hw could do it.. we could have texture compression without infringing that patent... .oO(dreams)
23:13 < pmdata> yep, I think so, it would be present also for tnt hardware in legacy driver if it was done in software
23:13 < blx> marcheu, software patents are not valid all over the world right?
23:13 < pmdata> blx> yep
23:13 < marcheu> blx: right, but the mesa guys won't merge stuff that is us patented 
23:14 < marcheu> so technically, we could have mesa-nonus or something with compressed texture support. and people from us wouldn't be allowed to use it
23:14 < marcheu> anyway, there's the other way we have now
23:14 < marcheu> the compression code is plugged into mesa as an external library, which you can choose to install or not
23:15 < marcheu> back when compressed texture support for radeon was written, I think most people were pissed that it couldn't be merged
23:23 < pmdata> no need for sample image, glteximage2d() will compress it if needed
23:23 < marcheu> yes
23:23 < pmdata> as it is a random texture, well, then maybe it is, using object 89
23:26 < pmdata> I tried the 4 compressed formats, object type 89 is filled with same parameters, only the offset in memory is different
23:41 -!- eLShaman [n=elshaman@pac33-1-82-235-249-217.fbx.proxad.net] has joined #nouveau
23:49 -!- Duke` [n=gnu@ANantes-251-1-138-122.w86-210.abo.wanadoo.fr] has quit [Connection timed out]
23:49 -!- Duke` [n=gnu@ANantes-251-1-135-113.w86-210.abo.wanadoo.fr] has joined #nouveau
--- Log closed Втр Июл 18 00:00:52 2006
