[Nouveau] SERIALIZE command

[Younes Manton]

2010/4/9 Shinpei KATO <shinpei at il.is.s.u-tokyo.ac.jp>:
> 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.