|
From: Dennis S. <sy...@yo...> - 2004-09-16 19:51:51
|
On Wed, 2004-09-15 at 23:52 -0300, Duilio Javier Protti wrote: > We can disable mmx within libvisual, but there is no way to > disable mmx on the whole process (even the OS can't do that). > > The question is how to let the libvisual users disable/enable > mmx stuff. If we give something like: > > int visual_cpu_enable_mmx (int yes_or_no); I had exactly this in mind, the plugins should always check capabilities through VisCPU subsystem, and This way we can disable certain capabilities through the VisCPU system. > on the VisCPU module, the problem is what to do if some plugin > enables mmx, but then other plugin (say on morphed switch) disable it. > We must denied or not? If we accept, we must tell the others > plugins that mmx activation has changed, so we must let plugins > register a callback for that: Have to think about this, generally plugins should be touching the capabilities, as in changing them. But still, have to think about it. > int visual_cpu_enable_mmx (int yes_or_no, void (*) (void *)); > > The other possibility is to enable/disable mmx stuff only through > a visual_init() parameter. I like more this, because this is done > just once per application, and because main application have > enough information to decide whether or not it must activate mmx > stuff. Well, not through visual_init, but through an initialization call. I think that, having the app decide if it should be enabled or not is best indeed. However now we have the next problem. What about threaded render pipeline. (at morph, two actors in both a thread) for heavy use in mutliCPU machines... (Why O why does mmx share it's regs with FPU...) We should so get into SSE as well :) Cheers, Dennis |