2010/4/9 Shinpei KATO <[email protected]>: > Hi, > > Thanks again for your reply! > >> > I tried inserting the 0x110 commands with NvSubM2MF (subc=0), MvSubSw >> > (subc=1), NvSub2D (subc=2), NvSubGdiRect (subc=3), NvSubImageBlit >> (subc=4). >> > As a result, I got the PFIFO_CACHE_ERROR interrupts, with respect to those >> > with NvSubSw and NvSubImageBlit. I am really not certain what >> > PFIFO_CACHE_ERROR indicates, but seems they do not work correctly? Well, >> > those with NvSubM2MF, NvSub2D and NvSubGdiRect are still very helpful >> > though. >> >> This is not how it works. >> >> The command channels on nvidia hardware are split into 8 identical so-called >> subchannels. The consts you're refering to are subchannel numbers. >> >> However, these subchannels aren't constantly bound to the same objects - >> you >> bind an object to a subchannel by executing command 0 with data being the >> RAMHT handle of an object. >> >> The Nv* consts you're referring to are only valid in kernel, and represent >> the >> bindings it sets up at start. Most of them don't even apply to NV50. Also, >> NvSubSw is bound to a software object. > > Oops... I thought that each subchannel is always bound to the same object, > and I was actually looking at only the kernel driver ;-) > I have been trying to understand the behavior of GPU operations, using > Gallium demo applications. > To do so, I was dumping the commands sent from the user space > (Nouveau/Gallium libdrm), by mapping the pushbuf to the kernel virtual > address in the kernel driver, to see what is going on. > I was also inserting another command in the kernel driver, like in > nouveau_gem_ioctl_pushbuf(), to see what happens. > Since several Gallium demo applications seem to use the subchannels in the > same manner, I misunderstood that they are constantly bound to the same > objects... > I should have looked into the libdrm code in detail. Now I see them, thanks. > By the way, when I was dumping the commands, I sometimes saw 0x00000000 > without any data. > Do you have any idea what this value means? (just a NOP?)
That's probably the null object (handle=0, class=0x30). It's created for every channel, see libdrm/nouveau_channel.c:86. >> PFIFO_CACHE_ERROR is an error that happens when the PFIFO puller encounters >> some problems. One of the causes is submitting a command on a subchannel >> which >> isn't actually bound to anything, which is what happens here. >> >> Software objects are fake objects where you don't actually bind any object >> to >> a subchannel, and instead trap the PFIFO_CACHE_ERROR this causes on command >> submission and do something on the host side. We use this for syncing with >> vblank on nv50. These don't support the SERIALIZE command because they're >> not >> real objects. > > So I was sending those commands with unbounded subchannels, that is why I got > the PFIFO_CACHE_ERROR interrupts. > >> Basically, there exist only 4 types of real objects you can submit commands >> on >> and bind to subchans: >> >> - m2mf [5039]: memory copies >> - eng2d [502d]: 2d engine >> - tesla [5097, 8297, 8397, 8597]: 3d engine >> - turing [50c0, 85c0]: computation engine: CUDA and the like >> >> Very likely there are more types, using different engine than PGRAPH, but >> we >> don't know anything about them yet. At the very least there should be the >> video decoding engine. > > Got it. > Regarding turing, you mean that Nouveau now supports CUDA? I think the kernel allows that object to be created, but that's all. We don't have any userspace GPGPU library yet. _______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
