On Fri, Jan 18, 2013 at 5:20 PM, Christian König <deathsim...@vodafone.de> wrote: > Am 18.01.2013 16:40, schrieb Marek Olšák: > >> On Fri, Jan 18, 2013 at 2:46 PM, Christian König >> <deathsim...@vodafone.de> wrote: >>> >>> Am 17.01.2013 23:54, schrieb Alex Deucher: >>> >>>> On Thu, Jan 17, 2013 at 12:32 PM, Michel Dänzer <mic...@daenzer.net> >>>> wrote: >>>>> >>>>> On Don, 2013-01-17 at 18:02 +0100, Michel Dänzer wrote: >>>>>> >>>>>> On Don, 2013-01-17 at 17:56 +0100, Marek Olšák wrote: >>>>>>> >>>>>>> Forking r600g was obviously a bad idea, because now radeonsi is just >>>>>>> as horrible as r600g used to be. >>>>>> >>>>>> What do you suggest? >>>>> >>>>> That's an honest question, BTW. It's certainly becoming increasingly >>>>> painful to port changes from r600g to radeonsi. The question is how we >>>>> could start sharing at least some code again. E.g. the state handling >>>>> has diverged quite a bit. Christian, any thoughts? >>>> >>>> Perhaps we could restructure things a bit and maybe add a few chip >>>> specific function pointers and share a number of source files like we >>>> do for the radeon/r200 (and formerly r300c/r600c). >>> >>> >>> I think we should place more common code under >>> src/gallium/drivers/radeon. >>> For the unreleased code that I wrote for more than one chipset generation >>> I >>> even opened up a new directory under "src/gallium/drivers/". >>> >>> On the other hand the state handling between SI and previous generations >>> needs to be quite a bit different (virtual memory and allocating space >>> inside the IB), so merging those state handling things again might not be >>> a >>> practical approach. >> >> What is allocating space inside the IB? Right now, the r600g state >> management and emission is pretty much the same as r300g, and I also >> think the ideas applied there are completely hardware-independent. >> What is so special about the SI hw that it needs something different >> now? >> >> Also what does virtual memory have anything to do with it? Cayman has >> virtual memory too. >> >> I think we should make new radeon_context a subclass of pipe_context >> for the common code, and making r600_context and si_context subclasses >> of radeon_context, the same for the screen, unless the evergreen and >> SI code can co-exist just like r600, evergreen, and cayman do. > > > Having common base classes for all three radeon drivers sounds like a good > idea to me and sharing the texture code between r600g and SI also.
Well, I'd like to keep r300g out of this. Even though a lot of r600g code is based on the same ideas now, the two have very different/incompatible codebases. > > We just need to keep in mind that the PM4 state handling is quite a bit > different on the different generations: > 1. R300: IIRC nearly 100% register based state > 2. R600: Mostly register based, but also some specialized PM4 commands > (Streamout etc..) > 3. SI: Few registers and allot of specialized PM4 commands, sometimes even > with embedded data. And ontop of that a second command stream for preloading > data (not implemented yet). Whether the states are register-based or based on special packets doesn't matter at all. It's only about reserving enough space for state objects and other hw commands in a command stream and the mechanism must have very small overhead, which isn't the case with r600g yet, but we're getting there. (r300g is 20% faster than r600g if rendering is CPU-bound) > > VM on Cayman is only optional, but on SI it is mandatory. So on SI we don't > have NOP packets for relocation for example and the state handling can be a > bit tighter, but on the other hand we need to deal with embedded data inside > the command stream. Both r300g and r600g embed indices inside the command stream in some cases. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
