> > I did the fun conflict resolution, so my tree doesn't have the ordering changes. > > I also did some things slightly differently from you - you had left > some direct ib[] accesses that I spotted (see for example "case 0x48" > (aka "Copy L2T Frame to Field"), and yours apparently has a few cases > where you use "idx_value" instead of my mindless conflict resolution > that just re-did the brute-force "repace direct ib[] read accesses > with the radeon_get_ib_value() helper function". But you don't do it > for *all* the radeon_get_ib_value(p, idx+2) users, so whatever. Yeah the rules for radeon_get_ib_value are that they are meant to be sequential, but it actually doesn't matter as long as the values are within a page of each other, I was just avoiding multiple calls to get the same value with the idx_value, but I think Alex or Jerome can clean this up a bit further anyways. > Anyway - my conflict resolution isn't exactly the same as yours, and > maybe I screwed something up. But it's damn close, and the differences > _seem_ be all be benign. > > Btw, why is it ok that some functions still read the ib[] array > directly (eg evergreen_vm_packet3_check() or evergreen_cs_check_reg() > etc)? The semantics for that function are a bit underdocumented, and I thought the other developers understood them after I explained them, but I found out that they hadn't quite grasped the true extent of pain. So yes there are other places that need to be cleaned up, but most of the time direct ib access will work fine, until you have a buffer that straddles a page boundary. > Whatever. I prefer doing my own resolutions just so that I know what's > going on, and it all seems to build and looks reasonable, but it's > always good to get a second opinion. Particularly since I can't > actually test the radeon stuff, so just eyeballing it and saying > "looks semantically identical to Dave's resolution" may not be 100% > sufficient.. Yup I've reviewed it and it looks fine, any cleanup is just going to be an optimisation. So I'll work with Alex/Jerome to clean up anything else out-of-band and hopefully we can avoid any big conflicts in future! Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
