>> Will there be open discussion of what makes up Xaa? I know
>> you have already have a working design but rather than accept
>> major changes wholesale can we discuss the finer points before
>> they become defacto-accepted.
>>
>> -Matt
>
> It depends what you'd like to discuss. I already have a
>working implementation. It does not preclude usage of the
>old XAA. A driver can use either one. Nobody has to
>touch old drivers if they don't want to.
I'd like to discuss the design details. Why don't you send the
relevant parts of the header to the list for discussion before
you commit it? Lets face it, once the code is committed there
is not going to be as much room for change. If Xaa is being
replaced then it seems fitting that everyone have a chance to
review and comment on the design before it is committed.
>1) Smaller. It's currently about one fifth the XAA size. There
> was too much benchmark rigging in XAA. It's not justified.
Smaller is good, but can you give an example of "benchmark
rigging"?
>3) No assumptions about offscreen memory usage. Leave it entirely
> up to the driver. I'll provide a sample linear heap manager.
> You can use whatever you want.
So is the new design "surface based"? i.e. blits are coordinates
relative to a surface (off-screen or on-screen). If so, this is
good. The rectangular memory "single surface" Xaa is not a very
good match for modern hardware.
Also, I would like to make sure that the new design has a much
improved syncing mechanism. Syncing should be, at a minimum,
on a per-surface basis. Perhaps even a bounded region of a
surface is justified. As GUI's become more "media rich" the
amount of data coming from the CPU to the graphics engine is
increasing. This means more puts and consequently lots of syncing
for many hardware types. The current global sync design waits
too long and forces idle time unnecessarily. Other driver models
abandoned the single sync a long time back.
I think we should also address the "setup for"..."subsequent"
design concept. Seems like most designs would be better fit
with a single entry point that provides all the information,
perhaps with an "n" option to indicate how many such calls are
expected with the same "setup" data. Command engines could then
batch commands together, or a driver could send a batch of
commands to a kernel driver. In my opinion it is more useful to
know how many similar commands are being sent (or at least know
when the last one is sent) than the current method.
Currently:
setup_for_foo()
while(i--) {
subsequent_foo()
}
could be
while(i--) {
do_foo(i);
}
or alternatively (if you can't know how many until you are done)
while(i--) {
do_foo();
}
last_foo();
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
