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

[Kenneth Graunke]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170103/c3bb3135/attachment.sig>