[Mesa-dev] [PATCH 0/6] Enable OpenGL 4.0 on Haswell

[Iago Toral]

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