On Wed, 2009-08-12 at 15:27 +0100, Keith Whitwell wrote:
> Dave,
>
> The big problem with the (second) radeon approach of state objects was
> that we defined those objects statically & encoded them into the kernel
> interface. That meant that when new hardware functionality was needed
> (or discovered) we had to rev the kernel interface, usually in a fairly
> ugly way.
>
> I think Jerome's approach could be a good improvement if the state
> objects it creates are defined by software at runtime, more like little
> display lists than pre-defined state atoms. The danger again is that
> you run into cases where you need to expand objects the verifier will
> allow userspace to create, but at least in doing so you won't be
> breaking existing users of the interface.
>
> I think the key is that there should be no pre-defined format for these
> state objects, simply that they should be a sequence of legal
> commands/register writes that the kernel validates once and userspace
> can execute multiple times.
>
> Keith
My idea was to have state grouped together according to what they matter
for. Like glstate of texture or object in nvidia hw. Idea is that most
of the object can be valid only if we know all of their state. For
renderbuffer we need to know its format, size, tiling, for texture we
need to know its format, size, mipmap levels and possibly others state
and so on and so forth.
If we just take arbitrary packet from userspace we might end up in
situation hard to decipher. If one validated cs program a renderbuffer
and other state like zbuffer it might be valid but now if we
combine it with another validated cs things might be completely wrong,
this another cs might just change clipping and renderbuffer size
but not update the zbuffer so we might endup rendering to zbuffer
either too small or too big (too small is what we don't want to
do ;)).
So in the end you need to enforce a set of register onto userspace.
Userspace need to submit a cs which program at least this set to be
validated, we can have different set like renderbufferset(clipping,
scissor,colorbuffer,zbuffer registers), vertex set(vbo,...), shaders
set(shaders reg) and then you can combine different set to do the
rendering. I think splitting states matter because you often render
to some buffer but with different vbo or pixel shader or vertex shader
or primitive, so it sounds better to split states.
There i think we endup pretty much to what i proposed. Thing is,
i don't think packet format is the best to communicate with the kernel
as kernel will have to parse the buffer and this is resource consuming
not to mention that tracking states that way it bit painfull.
I think state object with structure defined per asic (r3xx, r5xx, r6xx)
are better, no parsing, clear split of each value and easy access to
check that all together they do somethings allowed and then
easy and quick for the kernel to build the packet out of this.
On the backward incompatibilities side it's not harder to expand those
states :
struct radeon_state {
u32 state_id;
u64 state_struct_ptr;
};
version 1: state_id = 0x501
struct rv515_texture {
u32 width;
u32 height;
...
};
version 2: state_id = 0x502
struct rv515_texture {
u32 width;
u32 height;
...
u32 texture_pixel_sampling_center; /* well anythings new */
};
So from user pov it could still use the 0x501 and kernel
will just ignore the end of the structure and will set
default safe value for those. If userspace space submit
a 0x502 then it's assume that it knows about new state
and kernel will take them into account.
I don't think this add more works or code than adding new packet
to a parser.
Anyway the biggest problem of any of such approach is that we
need to figure out how to allocate memory to store either validated
cs or kernel built packet on behalf of the program, we don't
want to abuse kernel memory allocation. And we can't allow userspace
to modify those object after they had been validated :)
Cheers,
Jerome
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
