Re: [Mesa-dev] very strange intermittent frame-dropping

[Luke Kenneth Casson Leighton]

well it had to happen eventually (i forgot to keep the battery charged
up) so the opportunity to restart arrived - changed to DRI=3 and,
ta-daaa, problem's gone.

... or, at least, carrying out the previously 100%-repeatable test
(resize of a window under fvwm2) is no longer 100% repeatable.  i'll
run some more programs that are known to be problematic (with DRI2)
over the next few days, and report back.

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] very strange intermittent frame-dropping

[Luke Kenneth Casson Leighton]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848895

there's a really strange and comprehensively cross-application
intermittent bug that's only occurring on opengl-based applications,
that's been introduced some time in the past year.  to be absolutely
honest nobody's even sure it's actually opengl-related or whether it's
x11 related, but it's so weird that it's really hard to pin down.

the above bugreport on debian with chromium-browser is *just one* of
the occurrences, but it occurs with glxgears, openscad and a whole
stack of other applications.

the simplest 100% guaranteed way discovered so far to reproduce the issue is:

* install debian / testing
* install fvwm2
* set up fvwm2 to use "wireframe" for "resize window"
* run glxgears
* go ahead and resize the glxgears window with a mouse

that is *guaranteed* to result in glxgears "freezing".  the only known
guaranteed way to "recover" it is to switch to text console
(ctrl-alt-f1) followed by switching back to X11 (ctrl-alt-f7).

there are various teams trying to "fix" this bug, believing it to be
the fault of their application.  this includes the chromium-browser
team.  what they've managed to do so far is to simply... avoid *most*
circumstances under which the lock-up occurs... but all that happens
is that the processor running the application goes into multi-tasking
meltdown... *and then still* gets a lock-up.

it doesn't matter what underlying hardware is used: intel graphics,
nvidia, ATI.  it doesn't even matter if you use optirun: that *still*
results in a lockup although there you get a rather useful error
message indicating that the GPU is trying to do its job, but reports
constantly that the frame had to be dropped.

anyway, apologies: nobody whose applications are affected by this
really has a clue where the *actual* bug is so i am escalating it down
the chain of library dependencies, making people aware.  it could be
X11, it could be mesa, we just don't know.

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] very strange intermittent frame-dropping

[Luke Kenneth Casson Leighton]

On Tue, Apr 4, 2017 at 11:04 AM, Eero Tamminen
 wrote:

>> anyway, apologies: nobody whose applications are affected by this
>> really has a clue where the *actual* bug is so i am escalating it down
>> the chain of library dependencies, making people aware.  it could be
>> X11, it could be mesa, we just don't know.
>
>
> Does it happen only with the old, non-compositing window managers like
> FVWM2, or also with something newer?

 there's a whole stack of people reporting this occurring, running the
full range of window managers.

> Does DRI2 vs. DRI3 have any effect on it?

 hmm, good question.  i'm running with "DRI" "true" (so don't know if
it's 2 or 3), other people will have different settings.  i run with a
*lot* of applications that are left running 24x7 for days/months at a
time (because they're a pain to shut down and reopen), i'll see if i
can use startx -- :1 or something to try out a different DRI setting.
will get back to you soon.

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] very strange intermittent frame-dropping

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Tue, Apr 4, 2017 at 12:10 PM, Luke Kenneth Casson Leighton
<l...@lkcl.net> wrote:

>> Does DRI2 vs. DRI3 have any effect on it?
>
>  hmm, good question.  i'm running with "DRI" "true" (so don't know if
> it's 2 or 3), other people will have different settings.  i run with a
> *lot* of applications that are left running 24x7 for days/months at a
> time (because they're a pain to shut down and reopen), i'll see if i
> can use startx -- :1 or something to try out a different DRI setting.
> will get back to you soon.
>
> l.

https://wiki.archlinux.org/index.php/intel_graphics#DRI3_issues

DRI3 currently being used - i'm seeing the same god-awful rendering
crap issues, i did wonder how to fix that :)

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] very strange intermittent frame-dropping

[Luke Kenneth Casson Leighton]

On Thu, Apr 6, 2017 at 11:36 AM, Eero Tamminen
 wrote:
>>  LIBGL_DEBUG=verbose glxgears
>> libGL: Using DRI2 for screen 0
>>
>> huh.  so i _thought_ it was going to be DRI3.   that's supposed to be
>> the default, isn't it?
>
>
> You need it enabled in Intel DDX build, in X configuration, and Mesa build
> (with building done with suitable deps present).
>
> On normal distros, support should be built in, but not necessarily enabled
> for run-time by default.  In your own builds you need to make sure you
> enable support for DRI3 (= use "--enable-dri3" configure option).

 ok - i'll track it down.  i should be able to get the debian package
mesa-utils (and libraries), check the build configuration, etc.


>>> It would be interesting to know whether there's any correspondence with
>>> the
>>> DRI setting, and what exact Mesa & X versions they have.
>>
>>
>>  looks like i'm on debian 13.0.6-1
>
>
> ???

 sorry - i mean that the mesa version - on debian - is 13.0.6-1.  dpkg
-l | grep mesa:

ii  libgl1-mesa-glx:amd64 13.0.6-1
amd64free implementation of the OpenGL API -- GLX
runtime


> $ cat /etc/debian_version

 an answer to that would be misleading, i run debian/testing on which
i never do an "apt-get dist-upgrade", only pulling in packages
as-needed.

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] very strange intermittent frame-dropping

[Luke Kenneth Casson Leighton]

On Wed, Apr 5, 2017 at 10:43 PM, Chris Wilson  wrote:

>> 303 frames in 5.0 seconds = 60.424 FPS
>> 212 frames in 11.7 seconds = 18.079 FPS
>
> Overshoots by 6s.

 that's because, after the first 5 seconds, i did the fvwm2-based
"window resize" operation which triggered the "freeze".  after
probably... mmm... 2 seconds i pressed ctrl-alt-f1 then ctrl-alt-f7
all during 5 seconds which thus gives the apparent reduced framerate.

> Check dmesg for a GPU hang.

 none.

>  Attach
> /sys/class/drm/card0/error.

# cat /sys/class/drm/card0/error
no error state collected

this time i re-ran the test, but left it after triggering a "hang" for
more than 5 seconds.  the output of the framerate did *NOT* take place
until *AFTER* i had "recovered" glxgears running (with ctrl-alt-f1 /
ctrl-alt-f2)

Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
94 frames in 20.3 seconds =  4.637 FPS
302 frames in 5.0 seconds = 60.275 FPS
300 frames in 5.0 seconds = 59.986 FPS


hmmm i think it's time for a gdb session...

(gdb) where
#0  0x76b49180 in __poll_nocancel ()
   from /lib/x86_64-linux-gnu/libc.so.6
#1  0x75042150 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x75043c0f in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x75043d81 in xcb_wait_for_reply64 ()
   from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#4  0x77061018 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x776a88ea in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1
#6  0x776a8c47 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1
#7  0x73a899ca in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#8  0x73a89f01 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#9  0x73a75054 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#10 0x66be in ?? ()
#11 0x5e38 in ?? ()
#12 0x76a8b730 in __libc_start_main ()
   from /lib/x86_64-linux-gnu/libc.so.6
#13 0x646a in ?? ()
(gdb)

hmmm... where's the debug-symbols package when you need it...

let's try strace instead

oo that's interesting.  this time, when running strace, i did *NOT*
get a 100% "guaranteed" hang from resizing the window using fvwm2.
instead it took *three attempts*.

log file from strace is too large to post, it's at
http://hands.com/~lkcl/glxgears.strace.txt

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] very strange intermittent frame-dropping

[Luke Kenneth Casson Leighton]

ok installed libxcb1-dbg from debian, that gives more info, sorry i
can't install all the dbg symbols because of conflicting dependencies,
it seems that the packages are not fully sync'd at debian/testing.

starting to look like an x11 (xcb-related) bug, not mesa, what do you think?

l.

Approximately the same as the monitor refresh rate.
328 frames in 5.0 seconds = 65.397 FPS
^C
Program received signal SIGINT, Interrupt.
0x76b49180 in __poll_nocancel () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) where
#0  0x76b49180 in __poll_nocancel ()
   from /lib/x86_64-linux-gnu/libc.so.6
#1  0x75042150 in _xcb_conn_wait ()
   from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x75043c0f in wait_for_reply ()
   from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x75043d81 in xcb_wait_for_reply64 ()
   from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#4  0x77061018 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x776a88ea in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1
#6  0x776a8c47 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1
#7  0x73a899ca in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#8  0x73a89f01 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#9  0x73a75054 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#10 0x66be in ?? ()
#11 0x5e38 in ?? ()
#12 0x76a8b730 in __libc_start_main ()
   from /lib/x86_64-linux-gnu/libc.so.6
#13 0x646a in ?? ()
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] very strange intermittent frame-dropping

[Luke Kenneth Casson Leighton]

eero, apologies, the mesa-dev list's traffic is very high, i'll switch
over to digest, so please do cc me each time, to mitigate that.
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Apr 5, 2017 at 1:31 PM, Eero Tamminen <eero.t.tammi...@intel.com> wrote:
> Hi,
>
> On 04.04.2017 14:10, Luke Kenneth Casson Leighton wrote:
>>
>> On Tue, Apr 4, 2017 at 11:04 AM, Eero Tamminen
>> <eero.t.tammi...@intel.com> wrote:
>>>>
>>>> anyway, apologies: nobody whose applications are affected by this
>>>> really has a clue where the *actual* bug is so i am escalating it down
>>>> the chain of library dependencies, making people aware.  it could be
>>>> X11, it could be mesa, we just don't know.
>>>
>>>
>>>
>>> Does it happen only with the old, non-compositing window managers like
>>> FVWM2, or also with something newer?
>>
>>
>>  there's a whole stack of people reporting this occurring, running the
>> full range of window managers.
>>
>>> Does DRI2 vs. DRI3 have any effect on it?
>>
>>
>>  hmm, good question.  i'm running with "DRI" "true"
>
>
> Valid values for "DRI" setting are "2" or "3".
>
>
>> (so don't know if it's 2 or 3),
>
> This tells you which version apps get:
> LIBGL_DEBUG=verbose glxgears
>

 LIBGL_DEBUG=verbose glxgears
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/i965_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
libGL: Can't open configuration file /home/lkcl/.drirc: No such file
or directory.
libGL: Using DRI2 for screen 0
libGL: Can't open configuration file /home/lkcl/.drirc: No such file
or directory.
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
303 frames in 5.0 seconds = 60.424 FPS
212 frames in 11.7 seconds = 18.079 FPS

huh.  so i _thought_ it was going to be DRI3.   that's supposed to be
the default, isn't it?

>> other people will have different settings.
>
>
> It would be interesting to know whether there's any correspondence with the
> DRI setting, and what exact Mesa & X versions they have.

 looks like i'm on debian 13.0.6-1

  this is gonna be fun - i'll relay the request and get back to
you: might take a while, there's lots of people / lots of different
projects.

 some people are *not* able to repro the problem which is a good datapoint.

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] very strange intermittent frame-dropping

[Luke Kenneth Casson Leighton]

eero, chris: michel informs me that this is a known bug in
xserver-xorg-core 1.19.0 and that upgrading to at least 1.19.1 or
above fixes the problem.  i'll need to wait until another unscheduled
reboot but will keep you informed, and will try out DRI2 as well as
DRI3.

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] NLNet Funding Application, EUR 50, 000, for help porting AMDVLK or MESA RADV to the Libre RISC-V Hybrid CPU/GPU.

[Luke Kenneth Casson Leighton]

(to preserve thread, please do cc me on any questions, i am subscribed
digest, thanks)

https://libre-riscv.org/nlnet_2019_amdvlk_port/

i've submitted a funding request to the Charitable Foundation, NLNet,
for people to be the recipient of donations to work on a port of MESA
RADV (or AMDVLK, as appropriate) to the Libre RISC-V Hybrid CPU / GPU
/ VPU.

as this is a *hybrid* CPU/GPU, once the chain of
GLSL-SPIRV-NIR-LLVMIR-assembler has generated the assembly code, it is
executed *directly* on the Libre RISC-V SoC, *not* shipped over an
IPC/RPC mechanism to a [separate] GPU.  as mentioned in the link above
it has a lot in common with swiftshader, except that swiftshader is
not really suitable, here.

if there is anyone who would like to help with this, and be the
recipient of direct (tax-deductible) funding from NLNet for doing so,
please do contact me privately or off-list.

one important request: to fulfil NLNet's Horizon 2020 Backing (Grant
agreement No 825310), we need at least one EU Citizen to sign the MOU.
this is *not* a contract.  the EU Citizen does not have to *reside* in
the EU, they just have to have an EU Residence.

more information about NLNet is here:
https://nlnet.nl/foundation/

with many thanks,

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] NLNet Funding Application, EUR 50, 000, for help porting AMDVLK or MESA RADV to the Libre RISC-V Hybrid CPU/GPU.

[Luke Kenneth Casson Leighton]

hi all, the funding application was successful, i will follow up in a
separate subject line.

On Thursday, September 26, 2019, Luke Kenneth Casson Leighton 
wrote:

> (to preserve thread, please do cc me on any questions, i am subscribed
> digest, thanks)
>
> https://libre-riscv.org/nlnet_2019_amdvlk_port/
>
> i've submitted a funding request to the Charitable Foundation, NLNet,
> for people to be the recipient of donations to work on a port of MESA
> RADV (or AMDVLK, as appropriate) to the Libre RISC-V Hybrid CPU / GPU
> / VPU.
>



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU

[Luke Kenneth Casson Leighton]

On Thursday, January 9, 2020, Jason Ekstrand  wrote:

> Drive-by comment:
>

really appreciate the feedback.


>  I don't think you actually want to base any decisions an a vec4
> architecture. Nearly every company in the graphics industry thought that
> was a good idea and designed vec4 processors. Over the course of the last
> 15 years or so they have all, one by one, realized that it was a bad idea
> and stopped doing it. Instead, they all parallelize the other way and their
> SIMD instructions and on scalar values across 8, 16, 32, or 64 invocations
> (vertices, pixels, etc.) Of the shader program.
>

for simplicity (not outlining nearly 18 months of Vector Architecture ISA
development) i missed out that we have designed a vector-plus-subvector
architecture, where the subvectors may be of any length between 1 and 4,
and there is an additional vector loop around that which may be from length
1 (scalar) to 64

individual predicate mask bits may be applied to vector however they may
only be applied (one bit) per subvector.

discussions have been ongoing for around 2 years now on the LLVM dev lists
to support this type of concept.

on the libre soc lists we have also had detailed discissions on how to do
swizzles at the subvector level.

AMDGPU, NVIDIA, MALI, they all support these capabilities.

to be clear: we have *not* designed an architecture or an ISA which
critically and exclusively depends on vec4 and vec4 alone.

now, whether it is a bad idea or not to have vec2, vec3 snd vec4
capability, the way that i see it is that Vulkan supports them, as does the
SPIRV compiler in e.g. AMDVLK, and we would be asking for trouble
(performance penalties, compiler complexity due to having to add predicated
autovectorisation) if we did not support them.

however, there are two nice things:

1. we are at an early phase, therefore we *can* evaluate valuable "headsup"
warnings such as the one you give, jason (so thank you)

2. as a flexible Vector Processor, soft-programmable, then over time if the
industry moves to dropping vec4, so can we.



> That isn't too say that Mesa is there wrong choice or that there aren't
> other reasons why SwiftShader would be a bad fit. However, I would
> recommend against making major architectural decipmentsions for the sole
> reason that it allows you to repeat one of the biggest architectural
> mistakes that the graphics industry as a whole managed to make and is only
> recently (last 5 years) finally gotten over.
>

consequently i am extremely grateful as the last thing we need is to spend
NLNet funds on repeating industry mistakes.

this is why i love libre hardware.  can you imagine the hell it would have
taken to get you signing an NDA just to be able to provide the insight that
you did?

:)

warmest,

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU

[Luke Kenneth Casson Leighton]

(if responding on mesa-dev please do cc me to help preserve the thread, i
am subscribed in digest mode, thanks)

the NLNet funding application documented here was successful:
https://libre-riscv.org/nlnet_2019_amdvlk_port/

we therefore have money (direct payment of tax free, tax deductible
donations from the NLNet Foundation into your bank account [1]) available
for anyone, anywhere in the world, to help create a 3D MESA Vulkan
compliant driver for a hybrid hard-soft GPU.

we considered starting from SwiftShader because it is, on initial
inspection, close to what we want. we could hypothetically have added deep
SIMD instructions, and the project would be 90% complete.

however when it comes to predication and to vector types such as vec2, vec3
and vec4, the infrastructure in SwiftShader is unable to cope. thus, if we
add custom hardware opcodes which can accelerate vector-vector operations,
SwiftShader would have been an extremely bad decision as it would be
incapable of using such hardware without a drastic redesign.

hence the reason for choosing MESA, because NIR can retain that critical
type information right up until it hits the hardware.

as you know, a hybrid CPU/GPU does not have a separate CPU and a separate
GPU, they are *one and the same*.  therefore if starting from the Intel
MESA driver or RADV, the initial work needed is to make the chosen base
actually a *software* renderer, just like SwiftShader.

this is a desirable goal and it will be important to have the code be
portable, unaccelerated, and run on at the minimum x86, and (later) the
Libre SoC.

once that phase is completed, *then* we may move to adding custom
accelerated opcodes (Transcendentals, YUV2RGB etc). bear in mind that these
will be added *to the CPU*... because the CPU *is* the GPU.

to be absolutely clear: there will be no marshalling of GPU data or
instructions, to be sent over to kernelspace IPC. the CPU will execute the
accelerated opcode (e.g atan2) directly and immediately.

this is significantly simpler than standard GPUs, saving on power
consumption and drastically simplifying debugging and application
developnent.

if this is of interest please do get in touch, and feel free to ask
questions.

best,

l.

[1] your accountant, with assistance from Bob Goudriaans, an International
Tax Law Specialist and Director of NLNet, can help confirm that the
payments from NLNet are considered charitable tax deductible donations...
*to you*.  all the International Tax Agreements are in place and the
documents available for inspection by your accountant.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU

[Luke Kenneth Casson Leighton]

On 1/9/20, Jason Ekstrand  wrote:

> Hopefully that makes the trade-off make more sense.  One other important
> factor is that, even if vec4 could, in theory, be more efficient, it's way
> easier to write a compiler if you scalarize everything.

hi jason, really appreciated the additional insight.  to explain:
we're going with an entirely innovative microarchitecture that has
(i'm leaving out a lot of details here) a Cray-style variable-length
vector front-end, a SIMD back-end (with predication), and multi-issue
decode which can *automatically* allocate and translate between the
two under a lot of conditions.

i got some kind assistance from Mitch Alsup at the beginning of last
year, where he outlined for me how the CDC 6600 really works, and how
to turn it into a multi-issue engine with very little extra effort
(basically apart from ramping up the ALUs, memory bandwidth and
register file ports, then unlike with the Tomasulo algorithm, to add
multi-issue to a a pure 6600 style Dependency Matrix is trivial)

if it's ok with you i'll let Jacob Lifshay explain, as he has been
designing and writing the Kazan driver for some time (Kazan is a
from-scratch SPIR-V to LLVM IR Shader Compiler, in rust).

> however, there are two nice things:
>>
>> 1. we are at an early phase, therefore we *can* evaluate valuable
>> "headsup" warnings such as the one you give, jason (so thank you)
>>
>
> Hooray!

:)


>> 2. as a flexible Vector Processor, soft-programmable, then over time if
>> the industry moves to dropping vec4, so can we.
>>
>
> That's very nice.  My primary reason for sending the first e-mail was that
> SwiftShader vs. Mesa is a pretty big decision that's hard to reverse after
> someone has poured several months into working on a driver and the argument
> you gave in favor of Mesa was that it supports vec4.

not quite :)  i garbled it (jacob spent some time explaining it, a few
months back, so it's 3rd hand if you know what i mean).  what i can
recall of what he said was: it's something to do with the data types,
particularly predication, being maintained as part of SPIR-V (and
NIR), which, if you drop that information, you have to use
auto-vectorisation and other rather awful tricks to get it back when
you get to the assembly level.

jacob perhaps you could clarify, here?

>  Personally, I'm still a fan of Mesa. :-)  I also won't
> hold it against anyone if they like SwiftShader; it's a neat project too.

it is... it's just... google is the number one contributor.  if there
were more (large) independent contributors, i'd be much more inclined
to view it favourably.  if they decided unilaterally that they "didn't
like our contributions", we'd have a hard fork on our hands.

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU

[Luke Kenneth Casson Leighton]

On Monday, January 13, 2020, Jacob Lifshay  wrote:

> On Thu, Jan 9, 2020 at 3:56 AM Luke Kenneth Casson Leighton
>  wrote:
> >
>
> > jacob perhaps you could clarify, here?
>
> So the major issue with the approach AMDGPU took where the SIMT to
> predicated vector translation is done by the LLVM backend is that LLVM
> doesn't really maintain a reducible CFG, which is needed to correctly
> vectorize the code without devolving to a switch-in-a-loop.




> Hopefully, that all made sense. :)


yes :) as you're actively designing this you have a way better handle on it.

also, therefore, to be clear, to anyone interested in receiving funding to
do this work, you can see that there will be someone else to work with who
knows what they're doing, technically.

thank you jacob.

jason i'd be interested to hear your thoughts on what jacob wrote, does it
alleviate your concerns, (we're not designing hardware specifically around
vec2/3/4, it simply has that capability).

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU

[Luke Kenneth Casson Leighton]

On Tuesday, January 14, 2020, Jacob Lifshay 
wrote:

> On Mon, Jan 13, 2020 at 9:39 AM Jason Ekstrand 
> wrote:
> >
> > On Mon, Jan 13, 2020 at 11:27 AM Luke Kenneth Casson Leighton <
> l...@lkcl.net> wrote:
> >> jason i'd be interested to hear your thoughts on what jacob wrote, does
> it alleviate your concerns, (we're not designing hardware specifically
> around vec2/3/4, it simply has that capability).
> >
> >
> > Not at all.  If you just want a SW renderer that runs on RISC-V, feel
> free to write one.


as we know, it would be embarrassingly low performance, not commercially
viable, therefore, logically, we can rule that out as an option to pursue :)

i don't know if you're aware of Jeff Bush's work on Nyuzi? he set out to
duplicate the work of the Intel Larrabee team (a software only GPU
experiment), in an academic way (i.e publishing everything, no matter how
"bad")

Jeff sought an answer to the question as to, ahem, why the Larrabee team
were not, ahem, "permitted" to publish GPU benchmarks for their work,
despite it having high end supercomputer-grade Vector Processing capability.

i spent several months in discussion with him, i really enjoyed the
conversations.  we established that if you were to deploy a *standard*
Vector Processor General Purpose ISA and engine (Nyuzi, Cray, MMX/SSE/AVX,
RISCV RVV), with *zero* special custom hardware for 3D (so, no custom
texturisation, no custom z buffers, no special tiled memory or associated
pixel opcodes) the performance/watt that you would get would be a QUARTER
of current commercial GPUs.

in other words you need either four times the silicon (four times the power
consumption) just to be on par with current commercial GPUs, or you have to
sell (only if completely delusional) something that's 25% the performance.

therefore, we have learned from that lesson, and will not be following that
exact route either :)

 If you want to vectorize in hardware and actually get serious performance
> out of it, I highly doubt his plan will work.  That said, I wasn't planning
> to work on it so none of this is my problem so you're welcome to take or
> leave anything I say. :-)


:)


> So, since it may not have been clearly explained before, the GPU we're
> building has masked vectorization like most other GPUs, it just that
> it additionally supports the masked vectors' elements being 1 to 4
> element subvectors.


further: this is based on RVV (RISCV Vectors) which in turn is based on the
Cray Vector system.

the plan is to *begin* from this base, and, following the strategy that's
documented in Jeff Bush's 2016 paper, assess performance based on
pixels/clock and also, again, following Jeff's work, keep a Seriously Close
Eye on the power consumption.

(we've already added 128 registers, for example, because on GPU workloads,
which are heavily LD-compute-ST on discontiguous memory areas, you
absolutely cannot afford the power penalty of swapping out large numbers of
registers through the L1/L2 cache barrier)

Jeff's strategies we will use as *iterative* guides to making improvements,
just ad he did.  he actually went through seven different designs (maybe 8
if you include the ChiselGPU triangle raster engine he wrote)

If it turns out that using subvectors makes the GPU slower, we can add
> a scalarization pass before the SIMT to vector translation, converting
> everything to using more conventional operations.


yes, exactly.  and that would be one of the kinds of tasks for which the
NLNet funding is available.

so that would be one very good example of something that would be assessed
using Jeff Bush's methodology.

what's nice about this is: it's literally an opportunity for a Software
Engineer working on MESA to, instead of saying "damnit these hardware
engineers really messed up, i feel totally powerless to fix it", to say
"this isn't good enough! i need instruction X to get better performance!"
and instead of saying "sorry we taped out already, deal with it, derwood"
we go, "okay, great, give us 2 weeks and you can test out a new instruction
X. start writing code to use it!"

i know that there is someone out there who, on reading this, is going to go
"cool! and the actual hardware's libre too, and.. wait... i get money for
this???"

:)

so again, jason, i'd like to emphasise again just how grateful i am that
you raised the issue of subvectors, because now we can put it on the list
of things to watch out for and experiment with.

and, just to be clear: we've already had this iterative approach approved
by NLNet: to start from a known-good (highly suboptimal but Vulkan
Compliant) driver and to experiment with designs (hopefully not at the
microarchitectural level) and instructions (a lot) and change the ISA
(hopefully not a lot), to, over time, reach commercially acceptable
performance.

and it's entirely

Re: [Mesa-dev] Rust drivers in Mesa

[Luke Kenneth Casson Leighton]

fransisco, alyssa et al:

you may be interested to know that the Libre-SOC Kazan Vulkan driver,
funded by NLnet, is written in rust.
https://salsa.debian.org/Kazan-team/kazan

the insights and analysis that you are going through is - was - pretty
much exactly why we chose it (or, more accurately: jacob lifshay
convinced me it was a damn good idea).

it's a big project, so we would welcome opportunities for
collaboration and cross-participation.

l.

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sun, Aug 23, 2020 at 10:36 AM vivek pandya  wrote:
>
> Hello all,
>
> I just cleanup a bit and commited code at :
> https://gitlab.freedesktop.org/vivekvpandya/mesa/-/commit/d1f29adf926eb44453db1255834575a6f7169d5f
>
> However it is not working as per my expectation (or my expectations are
> wrong)
>
> I want to see that driver fail at
> https://gitlab.freedesktop.org/vivekvpandya/mesa/-/commit/d1f29adf926eb44453db1255834575a6f7169d5f#54a82819ff146aa01755bf951d797d55a0332a32_0_43
> however in debugger control never reach there.

hm does it reach here?
https://gitlab.freedesktop.org/vivekvpandya/mesa/-/blob/d1f29adf926eb44453db1255834575a6f7169d5f/src/libre-soc/vulkan/libresoc_device.c#L105

(can i recommend a #ifdef VERBOSE_DEBUG and some printfs: it's crude
but effective and when restarting or when others try to replicate this
they will not need to set large numbers of breakpoints.  plus, the
debug print statements become a discussion anchor / reference-point,
and a form of documentation in themselves)

about that: is there an "official" MESA macro for use to do verbose
development-level debug output?  i see the radv code checks an
environment variable:
https://gitlab.freedesktop.org/vivekvpandya/mesa/-/blob/d1f29adf926eb44453db1255834575a6f7169d5f/src/amd/vulkan/radv_device.c#L2569



> I see that in
> https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e
> CreateShaderModule() is defined

hmm i don't see an equivalent createShaderModule in here:
https://gitlab.freedesktop.org/vivekvpandya/mesa/-/blob/d1f29adf926eb44453db1255834575a6f7169d5f/src/libre-soc/vulkan/libresoc_pipeline.c

also, enumerateInstanceDeviceProperties is empty:
https://gitlab.freedesktop.org/vivekvpandya/mesa/-/blob/d1f29adf926eb44453db1255834575a6f7169d5f/src/libre-soc/vulkan/libresoc_device.c#L259

whereas it is not, here:
https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e#0b80c3a6757284417a6c75db460ee183cd5e80dd_0_35

i would recommend putting debug printfs at the top of
libresoc_GetInstanceProcAddr, to get a handle (ha ha) on what
functions are being looked for.  ah: it *might* also be worthwhile
actually checking out that very early version of the broadcom driver,
liberally sprinkling it with debug printfs at least at the start of
every function, and see what is called, and in which order.

by doing the same thing in the libresoc driver that would give you an
idea of what is missing.

the other thought that occurred to me: it could just be that expecting
createGraphicsPipelines to be called is too early, and that to trigger
it, a little more of the infrastructure has to be in place, such as
responding to vkinfo:
https://gitlab.axiodl.com/AxioDL/mesa/-/blob/abd629eb3d4027b89c13158e90c6732b412e550e/src/intel/vulkan/anv_device.c#L782

just a thought.

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

[Luke Kenneth Casson Leighton]

On Sun, Aug 23, 2020 at 10:19 AM apinheiro  wrote:
> On 23/8/20 8:11, Luke Kenneth Casson Leighton wrote:
> > next step is to add 3D opcodes *directly* to the POWER9 core that we
> > are developing.
>
> Then, in addition to the drivers you already looking as reference, it
> would make sense if you take a look to Vallium, that have just landed on
> Mesa master
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6082

appreciated - we missed this one in the evaluation process (i think),
so thank you.  a primary objective is a native Vulkan driver.  correct
me if i am wrong, vallium is a "gallium-to-vulkan adapter"?  i saw
something about gallium which explained that gallium is not (yet)
entirely suited to this task?  also that there are threading
limitations in gallium and/or llvmpipe.

one of the reasons for picking a route that involves NIR is to
leverage the significant high-performance work done there, because
whilst libre-soc is a software-renderer, it's a software-renderer on
hardware that has (will have) full GPU capabilities.  if we used
gallium (or started from SwiftShader) the superb work done by NIR
passes would need to be duplicated.

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

[Luke Kenneth Casson Leighton]

On Sat, Aug 22, 2020 at 10:34 PM apinheiro  wrote:

> As Jason mentioned, to get a Vulkan driver started, you would need more
> than just one method. If you want a reference:
>
> https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e
>
> This commit added the basic skeleton for v3dv (broadcom mesa vulkan
> driver).

fantastic this is extremely helpful and much appreciated, thank you.

some background: vivek has kindly agreed to start the NLNet-funded
LibreSOC MESA Vulkan driver.  given that the LibreSOC CPU is a hybrid
CPU/VPU/GPU with an augmented POWER9 ISA (rather than "a totally
separate custom GPU with a foreign ISA completely incompatible with
POWER9"), the first step is actually a general-purpose non-accelerated
*software* Vulkan Driver, very similar to SwiftShader in concept
except:

* utilising NIR in order to take advantage of the 3D shader passes and
the information it can hold
* retaining vector, predication and texturisation intrinsics right up
to the very last second when handing over to LLVM-IR
* relying on "general" LLVM-IR to perform translation for *native*
(host) execution - not a "totally separate custom GPU..."
* initially entirely targetting *host* (native) scalar instructions
[or, if general-purpose LLVM-IR happens to use NEON, SSE etc. that's
great but not our concern]

in other words it should be possible for the LibreSOC Vulkan driver to
run on native non-accelerated CPUs - x86, POWER9, ARM, MIPS and so on.

the second step will be to add custom 3D instructions *to POWER9*, at
which point whilst we hope to retain the ability to still run on
unaccelerated hardware, it is a secondary priority, albeit a very
important one.

as there may be questions "why not start from a different point, why
not use SwiftShader or gallium" and so on, that evaluation took place
here:
https://bugs.libre-soc.org/show_bug.cgi?id=251

constructive feedback on this approach greatly appreciated:
https://bugs.libre-soc.org/show_bug.cgi?id=251#c36

with thanks and gratitude,

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

[Luke Kenneth Casson Leighton]

On Sun, Aug 23, 2020 at 1:56 AM apinheiro  wrote:

> On 22/8/20 23:59, Luke Kenneth Casson Leighton wrote:
> > constructive feedback on this approach greatly appreciated:
> > https://bugs.libre-soc.org/show_bug.cgi?id=251#c36

> In any case, those steps look good enough, although I lack any context
> of the final target.

(if i can fill in this bit)

the context is: to augment the PowerISA Instruction set to add 3D
opcodes *directly* to PowerISA, with the guidance, full knowledge and
under the supervision of the OpenPOWER Foundation.

this will include:  adding sin, cos, atan2... *to PowerISA*.  adding
texture interpolation instructions... *to PowerISA*.  adding YUV2RGB
and FP32-to-RGB conversion instructions... *to PowerISA*.

therefore, whilst the initial target is "general purpose scalar
non-accelerated non-vectorised soft-3D", this is simply because the
next step is to add 3D opcodes *directly* to the POWER9 core that we
are developing.


i mention this because normally, GPUs are considered completely
separate entities - completely separate processors.  LibreSOC will be
the first ever libre-licensed *hybrid* 3D-capable CPU, i.e. where the
*main processor* ISA is augmented to no longer need a completely
separate GPU.

i appreciate that i have said the same thing in several different
ways.  this is because hybrid CPU/VPU/GPUs are so unusual and so "not
normal industry practice" (because they're easier to sell if they're
separate) that it takes a while to sink in.

i know of only one commercial company that has developed a hybrid
CPU/VPU/GPU (they called it a GPGPU - general purpose GPU) - by
ICubeCorp. back around 2012-2015 they received government funding
sufficient to complete the IC3128 and associated VLIW compiler.  an
SGI Engineer who went on to work for both AMD and NVidia created the
ISA and designed the architecture.

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

[Luke Kenneth Casson Leighton]

On Monday, August 24, 2020, Jacob Lifshay  wrote:

Kazan isn't built on Mesa or NIR (though it was originally intended to
> integrate with Mesa). Luke decided that Libre-SOC should also have a
> similar Mesa-based driver and applied to NLNet for funding for it,


i'm amazed they said yes :) it means that we can do work on e.g LLVM under
that budget rather than under the original (constrained) one covering Kazan.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

[Luke Kenneth Casson Leighton]

On Sun, Aug 23, 2020 at 8:50 PM Dave Airlie  wrote:

> I don't want to get involved in half-thought out schemes here,

[this has been in the planning stage for... almost 2 years now?]

> but I'm
> going to indulge myself in one post.

appreciated.

> The programming model is what designs the driver:
> If your "GPU" is a scalar processor with 1000s of threads, then you
> want to operate it with a GPU driver.
> If your "GPU" is a wide-vector processor with only 10s of threads, you
> want to use llvmpipe style driver.

ironically due to it being a general-purpose processor with wide
vector processing added, and custom vectorised 3D opcodes, and no
SIMT, it strictly fits neither of those definitions, neither being
SIMT, nor SIMD, and yet having the possibility (through a NoC such as
OpenPITON) to run thousands of SMP cores (not SIMT threads: SMP
cores).

consequently we are in... "new ground".  luckily, NLNet recognise that
this is a Research Project.

> The big thing doing what Jacob did before, and from memory where he
> went wrong despite advice to the contrary is he skipped the
> "vectorises it" stage, which is highly important for vector CPU
> execution, as opposed to scalar GPU.

i saw the cross-over message, he explained why that was as part of an
early prototype (back in... 2018?)

> I'm guessing you want to add an LLVM backend for your "GPU"
> instructions (are these all vectorised?),

yes they are.  or, more to the point we're taking the *entire* scalar
POWER9 ISA and vectorising that (and extending the regfiles to 128x
64-bit entries).  vectors may be up to 64 elements (although doing so
@ 32 bit takes 1/2 the entire 128-deep FP or INT regfile)

> and just work out how to use llvmpipe and vallium.

as i am focussing primarily on the hardware, and trusting jacob and
vivek's knowledge, i am summarising.  we decided to treat the CPU,
from the perspective of this MESA driver, as more a GPU than a "SMT
multi-processor".

this will allow us the leg-room to *consider* adding SIMT at the
hardware level in the future (2+ years).  where from what i gather, if
we go with llvmpipe right now that would not be possible.

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver

[Luke Kenneth Casson Leighton]

On Monday, August 24, 2020, Dave Airlie  wrote:

>
> amdgpu is completely scalar,


it is?? waah! that's new information to me.  does it even squash vec2/3/4,
predication and swizzle?

what about the upstream amdgpu LLVM-IR?  that still preserves vector
intrinsics, right?

i'm assuming that AMDVLK preserves vector intrinsics?

AMDVLK's associated LLVM port was what ended up upstream, is that right?

I think you will hit problems with vectorisation, because it's always
> been a problem for every effort in this area, but if the CPU design is
> such that everything can be vectorised and you never hit a scalar
> path,


that's the plan.  every single scalar POWER9 opcode with very few
exceptions (branch, trap) is vectorised.

and you workout how texture derivatives work early, it might be
> something prototype-able.


good advice to plan on texture opcodes.  thank you.


> thing, or bring up this architecture on an x86 chip and see it works
> at all.


that's the plan.  phase I.  run on x86, IBM POWER9, etc. first [whilst
still preserving vector intrinsics until as late as possible]

by the time phase I is complete we hope that Simon Moll and Robin Kruppe's
LLVM-IR Vector Intrinsics will have landed, at which point we can do an
experimental LLVM port which supports LibreSOC POWER9 vector augmentation,
swizzle, transcendentals and texturisation opcodes etc.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev