Hi all,
The winter holidays are over and I would get busy with regular (but still much fun:) ) things. Thus a bit more detail on the current status
of R300 project:
First of all there is new snapshot - blended_fountain. I have just
tagged it (it was retagged a couple of times couldn't resist making some improvements) so if you are using anonymous CVS access wait a day for
SourceForge to catchup. Or, better yet, e-mail me your SourceForge handle
so I can add you to the developer list !
blended_fountain:
* textures now work more reliably
* alpha, color blending and alpha blending work
* lessons 06, 07 and 19 from nehe.gamedev.net work correctly
(or I can't tell the difference from software rendering
except it goes much faster) * code has been restructured and unified which should make
it a lot easier to add features and work with vertex
and pixel shadersIssues:
* we don't know how to set format field for textures.
Thus there is a hacking lookup function that matches
the format field produces by modified r200 code to
what actually works. There is also a code that quickly changes format - so
you can notice which value works and tabulate it. An (intended) side effect is a caleidoscopic change for
textures with unknown formats.New formats can be added in r300_state.c::translate_texture_formats
* Looks like not all polygon primitives are implemented yet -
I see this with some of KDE screensavers.New primitives can be added in r300_render.c::r300_get_primitive_type
* I occasionally see messages about "not enough vertices", in
particular this can be seen with glxgears. They arise when the driver is asked to paint a primitive
with fewer vertices than usual - for example I don't know
how to paint a QUAD with 2 vertices. (To be precise the end=start+2 in this case.. which to me
means we have only 2 vertices)TODO:
* other drawing modes (like Gourad shading) need to be added
by writing appropriate vertex shaders. the code is already split for that - just add a switch
and a bunch of ready shaders * similarly pixel shaders need to be written to take advantage
of more than one texture * alternatively, write a compiler for both vertex and pixel
shaders. You would probably want to add an extension for
ATI cards - or use the existing NV one. I also hear there
is an OpenGL standard for shaders - not sure whether it
made it into Mesa yet. * The card now draws but putting vertices in the command
buffer. This is suboptimal - so a port of vertex buffer
code from r200 is in order. Should be straighforward enough
there is an example of using vertex buffer in r300_render.c * isolate AOS and texture setup code inside DRM so that DRM
driver keeps track of such state. This is important as
it is probably the only security issue with the current
driver - everything else can be worked around by adding
more check in drm driver code.best
Vladimir Dergachev
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
