Jerome Glisse wrote: > On 11/18/06, Aapo Tahkola <[EMAIL PROTECTED]> wrote: >>> On 11/2/06, Keith Whitwell <[EMAIL PROTECTED]> wrote: >>>> Jerome Glisse wrote: >>>>> On 11/2/06, Keith Whitwell <[EMAIL PROTECTED]> wrote: >>>>>> Keith Whitwell wrote: >>>>>>> OK, the first round of work on the VBO branch seems to have gone >>>>>>> quite smoothly. It'd be great if a couple of the key r200/r300 >>>>>>> people could check the branch out and verify whether I've broken >>>>>>> those drivers or not. >>>>>>> >>>>>>> It'd be particularly interesting to see if someone (Aapo?) can >>>>>>> take a look at the disabled vtxfmt_a code and see if it is easy >>>>>>> to port that over to the new archiecture. I've got a feeling it >>>>>>> should be fairly straight-forward, as it's simple to fallback to >>>>>>> the tnl/ module for any unexpected or non-handled situations. >>>>>> I took a quick look at this and it seems doable. I sketched out a >>>>>> simplified approach that just attempts to hook the existing code >>>>>> into a _radeon_draw_prims() callback. It looks like it might >>>>>> work, but it would be better to try for a deeper integration. >>>>>> >>>>>> I'm pretty bullish about the vbo code & would like to see an early >>>>>> merge, so please take a look at this. >>>>>> >>>>>> Keith >>>>>> >>>>>> >>>>> I investigated recently a bug (8348) and we don't check if in >>>>> DrawRangeElement max - min won't requiert a memory area >>>>> bigger than what we can have with DMA (which if i am right >>>>> can't be bigger than RADEON_BUFFER_SIZE * 16). Do you see >>>>> any easy they to work around this. I will try to test VBO branch >>>>> today and complete your change. >>>> OK. I've got a couple of bugs to fix yet, and I've still got to try >>>> running glean, etc, so it'll be a couple of days before anything >>>> happens. But it would be good to have the r200/r300 drivers up to >>>> speed prior to a merge. >>>> >>>> Keith >>>> >>> I have tried to play a bit with that but i segfault in vbo_exec_array.c >>> line 127 with varray in progs/redbook know bug or something from my >>> side ? >>> >>> Btw i have thinked a bit more about the need to update max-min vertices >>> in drawelements and drawrangeelements and i don't see an easy way to >>> split the rendering as we have to go throught all indices and make sure >>> that (max-min)*primsize never need more memory than what dma alloc >>> can give us. Don't you have similar problem with intel ? >> You cannot split the commands nor remove copying of elts. >> r300 vertex cache is incorrectly configured and as a result of that, >> accessing elts twice (by the gpu) will cause r300 to crash immediately. >> You must upload new indices for every IDX packet. >> >> While this sucks it would suck even more if IDX packets wouldn't work >> at all. >> > > I was thinking of accumulating vertex in a buffer and submit then so > we wouldn't exactly split the IDX packet but send a stream of vertex. > Anyway i think this should be handled somewhere in mesa because > all driver might suffer from that, even with new memory handler if > your gart size doesn't fit the vertex and index buffer you end up in > bad situation.
I've been travelling for the last two weeks (and another long flight tonight) so I've had to let this sit for a little while. Hopefully I'll be alert enough on the flight to do a little more investigation. Keith ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
