Re: [Mesa-dev] Rust drivers in Mesa
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
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
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
Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver
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
--- 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
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
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
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] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU
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 chan
Re: [Mesa-dev] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU
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
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
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
Re: [Mesa-dev] NLNet Funding Application, EUR 50, 000, for help porting AMDVLK or MESA RADV to the Libre RISC-V Hybrid CPU/GPU.
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
[Mesa-dev] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU
(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
[Mesa-dev] NLNet Funding Application, EUR 50, 000, for help porting AMDVLK or MESA RADV to the Libre RISC-V Hybrid CPU/GPU.
(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] very strange intermittent frame-dropping
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
Re: [Mesa-dev] very strange intermittent frame-dropping
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
Re: [Mesa-dev] very strange intermittent frame-dropping
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
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
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
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 wrote: > Hi, > > On 04.04.2017 14:10, Luke Kenneth Casson Leighton wrote: >> >> 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" > > > 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
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Apr 4, 2017 at 12:10 PM, Luke Kenneth Casson Leighton 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
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
[Mesa-dev] very strange intermittent frame-dropping
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