On Tue, 2017-01-03 at 07:48 -0800, Kenneth Graunke wrote: > On Tuesday, January 3, 2017 2:02:19 PM PST Iago Toral wrote: > > > > On Tue, 2017-01-03 at 11:14 +0000, Chris Wilson wrote: > > > > > > On Tue, Jan 03, 2017 at 11:42:50AM +0100, Iago Toral Quiroga > > > wrote: > > > > > > > > > > > > Enabling GL 4.0 in gen7 requires a bit of work because some > > > > hardware and kernel > > > > combinations may not support all the features. Specifically, we > > > > need to know > > > > if the kernel can do pipelined register writes. Unfortunately, > > > > this > > > > requires > > > > that we emit batches at screen creation time when we don't have > > > > a > > > > brw_context > > > > available (all our current batch emission infrastructure relies > > > > on > > > > this). > > > > See [1] and [2] for more details. > > > Emitting a batch is trivial: > > > > > > https://lists.freedesktop.org/archives/mesa-dev/2015-August/09107 > > > 7.ht > > > ml > > Oh, thanks, I did not know you had done this before. It seems that > > patch got an Rb from Martin when it was sent in 2015 but it never > > landed, right? was there any other issue holding it back? > That was me - I NAK'd the series as a whole. > > > > > > > > > But we do want to share the bufmgr between screens, and you do > > > want > > > to > > > deprecate the current intel_batchbuffer.c due to the very large > > > overhead > > > it imposes. > > It seems that Curro and Ken were more interested in trying to reuse > > a > > bit more of the intel_batchbuffer.c for this rather than the other > > way > > around, but then again that might have only been because my > > original > > implementation was very focused on porting code from that file... > > your > > patch gets this done without using a batchbuffer object at all and > > I > > think it is quite clean. If Ken and Curro also like it and there > > are no > > other concerns I'll be happy to adapt/rebase your patch instead. > > > > Ken was also saying that he was planning some rework of the batch > > emission code, so I don't know what strategy fits his plans better. > > > > Iago > I'd forgotten that Chris did this. His code is much smaller, and > looks > like a nice solution to this problem. > > Iago, could you update the patch Chris linked instead?
Sure! > A couple thoughts on Chris's patch: > > I'd prefer to drop brw->has_pipelined_so in favor of checking the > screen > field directly (we've got enough redundant things in brw_context > already). Makes sense to me. > Also, I'm not sure what to make of the hw_has_pipelined_register > bitfield. If we're only using it for one thing, we could just use a > "can_write_sol_offsets" boolean. But it also seems nice. Would it > make sense to generalize it a bit and have: > > #define KERNEL_ALLOWS_SOL_OFFSET_WRITES (1 << 0) > #define KERNEL_ALLOWS_PREDICATE_WRITES (1 << 1) > #define KERNEL_ALLOWS_CS_GPR_WRITES (1 << 2) > #define KERNEL_ALLOWS_HSW_SCRATCH1_AND_ROW_CHICKEN3_WRITES (1 << 3) > #define KERNEL_ALLOWS_LOAD_REGISTER_REG (1 << 4) > > and consolidate the various brw->screen->cmd_parser_version checking > into one place, so intel_screen.c either tries it or queries it, and > then sets a bit, and the rest of the code just checks that bitfield? > > It might be cleaner that way...thoughts? I suppose this could make sense too. I am fine with giving this a go if there is agreement. I'll start by updating Chris's patch as is, then send a follow-up patch to do this if we decide to go down that path. > By the way, I just pushed a patch from Robert which eliminated the > OACONTROL register checking. So you don't need to worry about that. Great, thanks Ken! Iago > --Ken _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
