[Nouveau] SERIALIZE command

Shinpei KATO shinpei at il.is.s.u-tokyo.ac.jp
Fri Apr 9 19:05:42 PDT 2010


> Plain 0 in a pushbuffer is just a nop, yes. It's inserted as a placeholder
> for unused relocations sometimes.

Ok, thanks.

> The known pushbuf commands are roughly:
> 
> - bits 0-1 = 0, bits 29-31 = 0, bits 16-17 = 0: submit methods, increasing
> kind. method is in bits 2-12, subchan in 13-15, method count in 18-28.
> Subsequent <method count> words in FIFO get pushed into sequential methods
> starting from the given one.
> - bits 0-1 = 0, bits 29-31 = 1: JMP to data & 0x1ffffffc
> - bits 0-1 = 0, bits 29-31 = 2, bits 16-17 = 0: submit methods, non-increasing
> kind. method is in bits 2-12, subchan in 13-15, method count in 18-28.
> Subsequent <method count> words in FIFO get pushed into that method. [NV10+]
> - bits 0-1 = 2: CALL to data & 0xfffffffc [NV11+]
> - bits 0-1 = 0, bits 29-31 = 0, bits 16-17 = 2: RET [NV11+]
> - bits 0-1 = 0, bits 29-31 = 0, bits 16-17 = 1: conditional. disables method
> submission if bits 4-15 of this command AND contents of PFIFO reg 2058 ==
> 0.
> Used for selecting individual cards in SLI configurations for part of the
> command stream [NV40+]
> - bits 0-1 = 0, bits 29-31 = 0, bits 16-17 = 3: big non-increasing method
> submission. like the other non-increasing method submission, but method
> count
> is now taken from next word after the command and can be much larger. Used
> for
> pushing big amounts of data through the PFIFO, like nv50-style index
> buffers.
> [NV50+... I think.]
> 
> There are likely more, but I don't recall any right now.

This is very enough!

> > > 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.
> 
> Yup. Or maybe you sent them on out software object, and nouveau didn't
> recognise it.
> 
> As I already mentioned, there are two kinds of objects you can bind to
> subchannels... software and PGRAPH objects. There are likely more for video
> dec, but meh.
> 
> For software objects, all methods >= 0x100 cause PFIFO_CACHE_ERRORs, which
> driver can trap and emulate, or not.
> 
> For PGRAPH objects, all methods >= 0x100 are passed on to PGRAPH and are
> handled there, perhaps causing PGRAPH_ILLEGAL_MTHD error if they happen
> to not exist.

Yeah I saw both PFIFO_CACHE_ERROR and PGRAPH>ILLEGAL_MTHD while I was trying some commands ;-)
Now things are more clear to me!

> Methods < 0x100 are handled directly by the PFIFO, and are independent of
> the
> current object. There are a couple of known ones...
>
> > > 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?
> 
> Kernel allows you to create the relevant object, but other than that there's
> no support. You can indeed run your gpu code under nouveau if you're happy
> with writing it in nv50 machine code and submitting via the pushbuffer
> interface. Also our current memory managment is totally unfit for GPGPU
> applications and will need to be redone before there's any hope of seeing
> CUDA
> or OpenCL support in nouveau.

Ok, since I read some article saying Nouveau is not yet ready for CUDA applications, I just wondered.
Hope to see the CUDA support someday!

> Also, if you have any more questions and don't hate IRC, you can come to
> #nouveau channel on freenode. Makes it easier to answer.

Now I am in ;-)
Thank you very much for your support.

Shinpei



More information about the Nouveau mailing list