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/091077.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? 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). 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? 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. --Ken
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
