01:21 <hanetzer> https://bpaste.net/show/d2dc594ea894 coreboot with linux as a payload. not yet working.

02:51 <alyssa> Having deja vu writing new code.... all gfx drivers starting to look the same..? :P

03:32 <HdkR> They are all implementing the same specs, so it ends up being fairly similar

03:48 <hanetzer> yep... you start to recognize patterns when you sample a lot of the same thing for various platforms

04:29 <alyssa> OK, I still need to do a *lot* of cleanup, but I have a set of changes for doing BO reference counting etc the right way

04:29 <alyssa> Long story short is, performance gains across the board, especially noticeable in vertex heavy workloads like games.

04:51 <HdkR> :D

05:02 <tomeu> alyssa: how do you atm run deqp?

08:31 <janrinze> just a question: do people here use gcc-8 or g++8 on arm64? I noticed that switching on optimization generates error during runtime whereas gcc-7 / g++-7 runs fine.

11:08 <tomeu> janrinze: I'm using 8 here

11:08 <tomeu> janrinze: can you paste the errors?

12:27 <janrinze> tomeu: the error is free() invalid size. Since I use stl objects it seems it's related to memory management in the c++ library. If i compile with -g to trace the error it simply disappears.

12:28 <tomeu> maybe if you check what pointer is being free'ed, you will see the reason?

12:28 <tomeu> guess it could be with how a struct is packed

12:30 <janrinze> tomeu: since it only happens with optimization turned on and hence hard to track where it happened. No specific packing of structs used here.

12:31 <janrinze> tomeu: I just wondered if others had seen similar issues with g++-8. The issue is not there on g++-7

14:37 <alyssa> tomeu: cd deqp/build/modules/gles2 ; ./deqp-gles2 # -n whatever.whatever.*

20:07 <HdkR> Today is Panfrost day

20:12 <Lyude> nice :)

20:12 <Lyude> what are you planning on working on today?

20:13 <HdkR> job generation and submission

20:14 <Lyude> ahh, still using the dummy job stuff you had correct?

20:15 <HdkR> Never even did any job stuff. Just had the command line app for shader compilation :P

20:16 <Lyude> ahh

20:16 <Lyude> oh erm, I might have misworded that

20:16 <Lyude> I was trying to refer to the one-instruction-per-clause stuff you had

20:17 <HdkR> yea, that was purely compilation. I hadn't gotten far enough to even start pushing it over to the GPU to run yet

20:17 <alyssa> HdkR: I would encourage focusing on the compiler...

20:18 <HdkR> Sure. I'm also using it as an excuse to take a break from compiler work though :P

20:18 <HdkR> So infrastructure outside of that would be cool

20:20 <alyssa> HdkR: Sure

20:21 <alyssa> HdkR: Well, if you insist on doing command stream stuff, I'd say submit patches early and often. I'm willing to merge bifrost patches ahead-of-time, and I definitely want to do review so we don't diverge in bad ways.

20:22 <HdkR> Awesome. I was going to ask if you would allow that :)

20:34 <alyssa> <3

20:35 <alyssa> HdkR: I figure I'm going to end up maintaining parts of this at some point anyway, so.. :P

20:35 <HdkR> hah

20:36 <HdkR> You'll have me for ten hours a week at least :P

20:36 <anarsoul> alyssa: are you planning to rework varyings any time soon?

20:58 <robher> alyssa: I've been looking at the 32 vs. 64 bit support. I think the best way to address it is stick with the 64-bit version of structs everywhere and then copy 64-bit struct elements into the 32-bit struct in panfrost_vertex_tiler_job(). The only alternative I've come up with is start splitting context functions into 32 and 64 bit versions which seems hard to maintain. Thoughts?

21:02 <alyssa> anarsoul: Eventually? Yes. Soon? Probably not.

21:03 <alyssa> robher: I mean, one option is just... always using 64-bit structs.

21:03 <alyssa> Which is... fine. It's more memory usage on 32-bit, though.

21:04 <anarsoul> alyssa: I think I'll end up with allocating bo per job and reusing it later. Reallocating it if it's not large enough for current verteces count

21:04 <alyssa> anarsoul: :+1:

21:04 <anarsoul> I have no idea why Qiang decided to use suballocator for it. It just doesn't fit here

21:05 <anarsoul> (it can't resize bo)

21:05 <robher> alyssa: oh! I had the impression that the T6xx/7xx h/w only supported 32-bit?

21:06 <robher> I did see there's some flag though to set the size.

21:08 <HdkR> bifrost_compiler branch rebased

21:10 <robher> alyssa: It would be strange that the h/w supports 2 different layouts of midgard_payload_vertex_tiler.

23:35 <alyssa> robher: It is strange, but that's what the hardware does :P

23:36 <alyssa> AFAIK

23:36 <alyssa> Fairly sure at least

23:36 <alyssa> We probably have bugs preventing us from getting the 32-bit structs on T8xx etc, but conceptually, it's my understanding it does both.

23:37 <anarsoul> alyssa: then why not to go 64-bit on T6xx/T7xx?

23:37 <alyssa> HdkR: Maybe hold off on the compiler, but if you want to send a patch with just the standalone disassembler, I could probably merge that and get a good chunk of code off your hands

23:39 <robher> alyssa: then I'm confused as to what's not working for folks? Juno with T624 is a 64 bit system BTW.

23:39 <HdkR> alyssa: I could do that. Would shave off a lot

23:42 <alyssa> robher: I don't have traces of the blob running on 32-bit doing a 64-bit thing and vice versa, since I don't test on Juno or whatever

23:42 <alyssa> The hardware can do it. I just can't.

23:42 <alyssa> HdkR: :)