--- Log opened Птн Июн 23 00:00:34 2006
00:08 < pmdata> ah ok, will update with this
00:19 < pmdata> commited to cvs
00:26 < Lumag> :)
00:29 < pmdata> are you done with your exams?
00:32 < Lumag> fine, thanks
00:35 < pmdata> hardest part one: waiting for results
00:35 < pmdata> s/one/now/
00:41 < pmdata> ah, glcopypixels() is done by defining a texture from framebuffer, then drawing a quad from it
00:42 < pmdata> arg, it is glbitmap
00:45 < pmdata> ah, glcopypixels() uses a new object type: nvtype009f
00:46 < pmdata> nv12_image_blit, from xorg nv driver
00:47 < marcheu> yeah, I'm not even sure it requires an nv12
00:48 < marcheu> nv12 doesn't exist in the first place
00:48 < marcheu> and if the xorg driver uses it, it probably works on nv10/nv11 as well
00:52 < pmdata> yep, I put it as nv10|nv15, it maybe also works on tnt
00:52 < Lumag> 9f? Don't think so.
01:05 < pmdata> yo, nv12_image_blit added
01:15 < pmdata> added skip_to_next_line value, time to sleep now
01:15 -!- pmdata [i=patrice@ANantes-154-1-108-47.w86-214.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:36 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
01:49 -!- EdB [n=EdB@ARennes-251-1-22-151.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
01:52 -!- Netsplit niven.freenode.net <-> irc.freenode.net quits: @ChanServ
01:53 -!- Netsplit over, joins: @ChanServ
02:03 -!- Duke` [n=gnu@ANantes-251-1-100-249.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:07 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
02:41 -!- katakombi [n=kombrisn@dslb-084-056-188-105.pools.arcor-ip.net] has quit [Remote closed the connection]
02:56 < darktama> marcheu: have you started porting object creation and RAMHT handling to DRM yet?
03:14 < marcheu> darktama: nope
03:14 < marcheu> darktama: I'm looking at the bios code on nv28 now and hoping I have more luck
03:15 < marcheu> do you need it ?
03:15 < darktama> not just yet, but I'm starting to look at trying to get a test program to use NV30_TCL_PRIMITIVE_3D
03:16 < darktama> bios code still giving you trouble then? :P
03:19 < marcheu> yup, I don't understand
03:19 < marcheu> it leaves the card in an unusable state
03:19 < marcheu> I tried a port the haiku reinit code, but it doesn't look like it's enough
03:21 < darktama> what is borked after running the BIOS code?
03:22 < marcheu> basically everythin, you can't read/write regs
03:22 < marcheu> and after I power up the card again, regs still have weird values, like my card starts reporting 64Mb (has 128)
03:23 < darktama> ouch, that's not terribly useful then :)
03:23 < darktama> does that happen on all cards you've tested?
03:24 < marcheu> right now the code only works on cards with the BIT bios signature, that is >=NV40. so I only tested on the nv44
03:24 < marcheu> I'm porting the PINS signature code now
03:27 < darktama> I think we need a tool to watch the kernel module's mmio access, that way we can see how nvidia interprets the bios tables
03:28 < marcheu> or maybe limit the writes to what we need, i.e. crtc regs and PLL regs
03:29 < darktama> yeah, that's not a bad idea either
03:29 < marcheu> a kernel tool to trap mmio writes looks like a lot of work
03:29 < marcheu> right now I really'd like to write driver code, not another tool...
03:30 < darktama> yup, definitely
03:32 < darktama> my current plan is to try and get a test prog that can draw a triangle, then I'll be satisfied that we're ready to do it in a dri driver
03:32 < marcheu> yup
03:32 < marcheu> but do you want to use nvidia's kernel module or the drm module ?
03:33 < marcheu> if you need a working drm module I can git it a whiplash
03:33 < darktama> drm preferably, using nvidia's module would just be a hack imo
03:34 < darktama> on nv40 we're going to need that agp scratch space too.. we need a fragprog for everything
03:35 < marcheu> I can see a memory manager discussion coming
03:35 < darktama> hehe, well, for the purposes of a test prog I can hardcode values and worry about doing it properly later
03:36 < airlied> marcheu: look at my valgrind code..
03:36 < airlied> or glisses libsegfault..
03:36 < airlied> they both trap all mmios from a driver..
03:36 < airlied> ah you want the kernel module.. bit messier..
03:37 < marcheu> yup, the nvidia bios parsing code seems to be in-kernel
03:37 < darktama> and modesetting :(
03:37 < marcheu> so we need to act kernel-side...
03:38 < marcheu> airlied: any hints how to do that in the kernel ?
03:39 < airlied> marcheu: hmm it's messy, I'll think it over I'd seriously doubt there is any where to hook..
04:39 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
08:14 < airlied> marcheu: you could try re-writing some of the os_ functions in nvidia os-interface.c
08:15 < airlied> some named like os_io_read_byte.. but I don't see any for MMIO..
09:16 -!- Netsplit niven.freenode.net <-> irc.freenode.net quits: marcheu, |pedro, hiyuh
09:18 -!- Netsplit over, joins: hiyuh, marcheu, |pedro
09:21 -!- ddl [i=erikw@montezuma.acc.umu.se] has quit [Read error: 104 (Connection reset by peer)]
09:21 -!- ddl [i=erikw@montezuma.acc.umu.se] has joined #nouveau
10:20 -!- Duke` [n=gnu@ANantes-251-1-90-29.w86-203.abo.wanadoo.fr] has joined #nouveau
10:22 -!- katakombi [n=kombrisn@dslb-084-056-131-099.pools.arcor-ip.net] has joined #nouveau
11:05 -!- katakombi [n=kombrisn@dslb-084-056-131-099.pools.arcor-ip.net] has quit [Remote closed the connection]
11:13 -!- EdB [n=EdB@ARennes-251-1-18-100.w81-250.abo.wanadoo.fr] has joined #nouveau
11:27 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has joined #nouveau
12:15 -!- EdB [n=EdB@ARennes-251-1-18-100.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
12:16 -!- EdB [n=EdB@ARennes-251-1-18-100.w81-250.abo.wanadoo.fr] has joined #nouveau
15:06 -!- EdB [n=EdB@ARennes-251-1-18-100.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
15:20 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has quit ["SIGKILL"]
16:19 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:32 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
16:53 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has joined #nouveau
17:04 -!- littlesniper [n=guillaum@6.173.97-84.rev.gaoland.net] has joined #nouveau
19:00 -!- katakombi [n=kombrisn@dslb-084-056-176-247.pools.arcor-ip.net] has joined #nouveau
19:17 -!- littlesniper [n=guillaum@6.173.97-84.rev.gaoland.net] has quit [Read error: 110 (Connection timed out)]
19:42 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
19:43 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has quit ["SIGKILL"]
19:47 -!- katakombi [n=kombrisn@dslb-084-056-176-247.pools.arcor-ip.net] has quit [Remote closed the connection]
20:11 -!- pmdata [n=patrice@ANantes-154-1-53-167.w81-53.abo.wanadoo.fr] has joined #nouveau
20:13 < pmdata> hello
20:50 < marcheu> hi pmdata
20:52 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
20:53 < pmdata> marcheu> so you think fsaa multisampling is the same as mipmapping (if the later is done by hardware) ?
20:53 < marcheu> pmdata: both are about downsampling
20:54 < marcheu> so if we have a command to downsample a memory area, we might be able to reuse it to generate a mipmap set automatically
20:54 < pmdata> yep, so we should try defining a mipmapped texture, to see if same commands are used
20:55 < marcheu> although there's one issue IIRC
20:55 < marcheu> 99% of the time, the mipmaps are generated by GLU
20:55 < marcheu> and you have to upload them as-is
20:55 < marcheu> there's an SGI extension to do that, though
20:56 < pmdata> gluBuild2DBitmaps()
20:56 < marcheu> http://icps.u-strasbg.fr/~marchesin/perso/extensions/SGIS/generate_mipmap.html
20:56 < pmdata> ah, I have this extension as supported on 1.0-7174
20:57 < marcheu> yes, gluBuild2DMipmaps generates the full arrays. but the trouble is that it's done inside the glu lib which in turns does GL calls
20:57 < marcheu> so you have no way to know if GLU handed you a set of colored mipmaps or a simple set of downsampled mipmaps
20:57 < marcheu> which is which separating the functionality in GLU was stupid in the first place
20:58 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
20:58 < marcheu> s/which is which/which is why
20:58 < pmdata> I think any glu stuff is done on cpu
20:58 < marcheu> yes, that's my point
20:58 < marcheu> it's done on the CPU and there's no way to hijack it
20:58 < pmdata> glu is just a high level lib on top of gl
20:59 < marcheu> yes, but we still have no way to hijack the call :)
20:59 < pmdata> hum, so we should try sgis_generate_mipmap then
20:59 < marcheu> that's why the call should have been in GL and not GLU in the first place
21:00 < marcheu> I don't think many apps use that though. Although OpenGL-ES does something similar...
21:00 < pmdata> if sgis_generate_mipmap  is available in gl, then glu could use it
21:00 < marcheu> ah, good point
21:00 < marcheu> that's a very clean solution
21:02 < pmdata> time to write a test_sgis_generate_mipmap then
21:02 < pmdata> hm, I don't know if mesa glu already does it
21:02 < marcheu> it doesn't
21:03 < marcheu> that'd be pretty cool, though
21:05 < marcheu> it definitely looks feasible
21:06 < pmdata> yep, it creates a new texture then gluscaleimage it
21:06 < marcheu> that'd be a very nice improvement for many texture-intensive applications
21:07 < pmdata> only when you load (and generate mipmaps) frequently -> when you have no so much texture memory maybe?
21:07 < marcheu> if you don't plan on doing this right now, we have to write that down somewhere in the wiki so we don't forget that idea
21:07 < marcheu> it's interesting because you upload only the first mipmap level over the bus
21:08 < marcheu> the other levels can be done by the card, and thus require no transfer
21:08 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
21:09 < marcheu> so if you have lot of textures, and texture swapping happens, it's very nice
21:09 < pmdata> first I think I will write a test function to see how it compares with glubuild2dbitmaps
21:09 < marcheu> yeah
21:09 < marcheu> btw when dealing with textures, you have to keep in mind that all drivers cheat
21:10 < marcheu> some will send compressed textures even when not asked to, some will resample to lower bpp, some will lower the mipmap lod bias...
21:14 < pmdata> and I hope nvidia did not implement sgis_generate_mipmap in software :)
21:15 < marcheu> well, they might. they have a texture analysis code (I don't remember what it's called) that looks at mipmaps and lower the bias if they are similar
21:15  * pmdata will use random generated texture
21:15 < marcheu> yup, that's how aet defeated it on r300 as well
21:16 < marcheu> we were discussing it some time ago
21:16 < marcheu> and couldn't find where the textures were
21:16 < marcheu> I looked at the fglrx disassembly, and saw that the driver would automatically compress textures when the loss was acceptable
21:16 < pmdata> we don't need these tricks, do we?
21:17 < marcheu> so aet did the test with a pure noise texture, and could figure out how the upload worked
21:17 < marcheu> well, it's all for performance
21:22 < marcheu> btw darktama suggested yesterday that we start "operation triangle"
21:22 < marcheu> I agree we know enough to get a basic triangle going now
21:22 < pmdata> a simple program that draws a triangle?
21:23 < pmdata> yep, you must start somewhere :)
21:23 < darktama> the only part I'm confused about at the moment is color/depth/etc buffer setup, do we know how that is done?
21:24 < marcheu> darktama: nope, I was trying to figure out where the pitch is setup the other day too...
21:24 < marcheu> I suppose we should create an FBO to see how it works
21:24 < marcheu> or a pbuffer
21:24 < darktama> yup
21:24 < darktama> I started playing with it a while back and got distracted by shaders again :)
21:25  * pmdata can not run shaders, so do buffer setup stuff instead
21:25 < darktama> hehe
21:26 < darktama> marcheu: I'm currently reworking the code in cvs already to share register alloc / usage tracking etc. between both vtx and fragprogs.. it'd be wasteful to have it duplicated
21:27 < marcheu> darktama: oh btw, please keep older nv20 in mind when doing that
21:27 < marcheu> darktama: I suspect we can implement a lot of vtx/frag prog func here
21:27 < marcheu> I suppose we could have a common optimizer and two backends
21:27 < darktama> yup, that's my general plan
21:28 < marcheu> ok, cool
21:28 < darktama> the backend will just do opcode construction really
21:28 < marcheu> not really
21:28 < marcheu> think opcode merging
21:29 < marcheu> think premultipliers
21:29 < darktama> btw, from looking at your nv34 dumps.. I don't think the vtxprog info matches well at all to nv30
21:30 < marcheu> hmm
21:30 < marcheu> well if you need to do some tests...
21:31 < darktama> yeah, it might be a good idea..
21:31 < darktama> has anyone figured out fixed-function TCL for it yet?
21:31 < darktama> and texenv
21:32 < marcheu> no, but I'm all for letting up low hanging fruit for newcomers anyway
21:33 < darktama> fair enough :)
21:37 < pmdata> does anyone tried nv_register_combiners stuff for pre nv20 cards?
21:37 < marcheu> nope
22:00 -!- EdB|w_ [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
22:22 -!- EdB [n=EdB@ARennes-251-1-43-56.w81-250.abo.wanadoo.fr] has joined #nouveau
22:28 < pmdata> marcheu> do you think someone could port renouveau to windows, to check stuff not present in linux nv driver?
22:28 < pmdata> (mainly video related I think)
22:28 < marcheu> hmm, that's complicated, because AFAIK windows emits all the video stuff frmo the kernel
22:29 < marcheu> so you can port renouveau (probably with some pain) but I don't think that'll help much
22:30 < pmdata> ok, I was just wondering
22:31 < marcheu> what functionality do you have in mind precisely
22:31 < marcheu> ?
22:33 < pmdata> maybe some video decompression stuff that is not in xvmc maybe, well anything that is not 3d
22:33 < marcheu> do you have some link about that ?
22:35 < pmdata> no, sorry, but for example, nvidia makes some pr about their 'purevideo' layer, and maybe the xvmc does not provides everything purevideo does
22:36 < pmdata> when doing some gldrawpixels()/glreadpixels() tests (don't exactly remember), I saw the fifo filled with 0 (NOP)
22:37 < marcheu> well, purevideo is really a fragment program that decodes the video using some quality filters
22:37 < pmdata> purevideo> yes, I agree
22:37 < marcheu> so once we have the OpenGL functionality, we can do "purevideo" :)
22:38  * pmdata was wondering if NOPs were really required (I saw over 260000 NOP)
22:38 < pmdata> for a single glreadpixels (or gldrawpixels) operation
22:38 < marcheu> hmm, these should be merged by the nop merging function
22:38 < pmdata> yep, they are merged
22:38 < marcheu> ah, well so the fifo is written at the end
22:38 < pmdata> but I wonder if the gpu really need those nops
22:38 < marcheu> and renouveau sees one little change at the end
22:39 < marcheu> and one little change at the begining
22:39 < marcheu> so it think the whole fifo changed
22:39 < marcheu> because it's not too smart, really :)
22:40 < pmdata> I heard years ago that fast raster ops required having a quadro board, I just hope this is not done by having these nops removed
22:40 < marcheu> these nops were not inserted in the first place
22:40 < pmdata> ah ok
22:41 < marcheu> it's just that the end of the fifo is changed, for some reason I don't understand
22:41 < marcheu> and renouveau just uses a single range, so the range covers the whole fifo
22:42  * pmdata has to find some gl_sgis_generate_mipmap sample code/doc now
22:42 < pmdata> grr, sourceforge ml are still out
22:45 < pmdata> another question: how can I know if some 32bit value is an adress (for a buffer or a texture)? I saw some high ranges values sometimes that may be them, but not sure
22:46 < pmdata> and another one: does texturing (and or any other operation that requires reading values from ram) need a copy from system ram to video ram (using agp), before use?
22:47 < marcheu> for the first question, you can't
22:47 < pmdata> or does gpu can directly pull texture from system ram in agp space ?
22:47 < marcheu> for the 2nd, both can happen
22:47 < marcheu> but since video ram is faster, the textures will be put in video memory first
22:47 < marcheu> only when video memory is full will the AGP space be used
22:48 < marcheu> so if you're creating your first texture, it'll probably go to video mem
22:51  * pmdata should try generating many 2048x2048x32bit texture then, to see what happens
22:52 < marcheu> it'll go to video memory since it uses 16mb :)
22:52 < marcheu> once you're past the point where you fill video memory, things get complicated
22:53 < marcheu> the driver has to keep the often-used textures in video memory, and others in AGP space
22:53 < marcheu> so it swaps the in and out
22:55 < pmdata> I have 448MB ram, 256MB agp space, and 64MB video ram
23:03 < marcheu> time to drive home now, bbiab
23:04 -!- EdB [n=EdB@ARennes-251-1-43-56.w81-250.abo.wanadoo.fr] has quit [Success]
--- Log closed Сбт Июн 24 00:00:34 2006
