On 2002.06.12 03:49 Leif Delgass wrote: > On Tue, 11 Jun 2002, José Fonseca wrote: > > ... > > > > Please, let's not discuss this further. I think we both agree that > using a > > variable is the best wat to go, isn't it? > > Each and every processor cycle must be precisely documented and accounted > for! The lives of rocket-launcher toting space marines depend on our > attention to detail! I've clamped onto the throat of this bit of code > like a mad dog and will continue to shake it around while foam dribbles > from the corners of my mouth long after it's dead. Ahem, ... ok I'm back > now, I think I blacked-out for a minute there. >
:-) > Anyway, I just think that in any case it would be better if we only > enable > bus mastering on idle (if things are going well, an active engine should > be the common case). If we do that I don't think it's really a big deal > to > have the extra writes. The writes could be conditional on a read or we > could use a variable instead, but I'm not sure it's worth it and it could > be error prone. Now that I think about it, there's an added bit of > security and safety in making sure that the block 1 registers are enabled > and that src_cntl is set for gui-mastering and FIFO synchronization > before > starting a new DMA pass. It would probably help performance in general > to find ways to reduce the number of DMA restarts we do also. Without doubt. I hope that by joining the state buffers, by speeding up the vertex buffer construction, and (if we don't manage to increase the buffer size on the client side) hold the buffers a little more on the kernel to achieve the same effect we will then overcome this. > > btw, as I tried to indicate above, I can be a bit of an obstinate bugger > sometimes and I'm often just thinking out loud. You might want to have a > salt shaker at hand and administer a grain or two when you read my posts. > 8->~ (that's me foaming at the mouth). > That's ok! I'm not too far behind you! > ... > > > > Oh.. I didn't had that impression... But even with that restriction, > they > > are a lot smaller than I would expect. I would expect that OpenGL > > applications made less state changes than that... > > Changing textures is one example, and I'd imagine that happens fairly > often. I should point out that a primitive won't be split across > multiple > vertex buffers, so that can leave some unused space as well. As you > mentioned, we're going to have to revisit vertex buffers at some point in > any case, both for performance and security. BTW, last time I had to > boot > Windows (against my will, of course), I did a quake3 timedemo. On my > laptop, the current dri branch is only behind by ~4fps w/ vertex lighting > and 2fps w/ lightmap lighting (approx. 82% and 87% of performance in > Windows respectively). I'd say we're making good progress. My goal is Indeed! Especially attending that we know that there are several optimization to do yet. > to > try to at least match the Windows driver, but with a more secure > implementation. Me too! Ok. Enough of talk and back to coding..! José Fonseca _______________________________________________________________ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
