AMD GPU new API for new module
Dave Airlie
airlied at gmail.com
Mon Oct 13 14:13:52 PDT 2014
On 9 October 2014 19:20, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Wed, Oct 8, 2014 at 6:00 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
>>
>> struct radeon_ioctl {
>> u32 version;
>> u32 size;
>> };
>
> How is this any different from just another ioctl multiplexer and why
> can't we just add a new version if an ioctl needs to be revised? E.g.
> in i915 we've just added execbuf2 and within execbuf2 there's tons of
> flags to enable/disable code. I don't see what a version field buys us
> on top of having flags fields and just creating a new ioctl if that
> gets too fuzzy. In the end you still have to keep all the old crap
> working, and imo that's easier to do long-term if you don't make it
> too easy to add new interfaces.
>
> Also, the size is encoded in the ioctl itself and like Rob said the
> core takes care of properly zero-filling this.
I'm kinda with Daniel on this, I don't see the point in adding a multiplexer
to a multiplexer interface,
Do we envisage adding a lot of new ioctls? so the driver will run out of ioctls?
Otherwise I don't erally see the difference between this
submit (0, - submit (1, - submit(2,
and just adding
submit1, submit2, submit3 ioctls,
You still know what userspace is asking for by what entry point it comes in,
Dave.
More information about the dri-devel
mailing list