Re: Getting started with Lavapipe

[Dave Airlie]

On Fri, 9 Feb 2024 at 14:38, Ashwin Bhat  wrote:
>
> Hello,
>
> During  Vulkanised 2024 I was super excited to hear and learn about Lavapipe
> https://vulkan.org/user/pages/09.events/vulkanised-2024/Vulkanised-2024-faith-ekstrand-collabora-Iago-toral-igalia.pdf
>
> Are there some basic tutorials on how to get started with setting up Lavapipe 
> swrast on Windows?
>
> I've installed LLVM and ensured it's in path. I have been trying to build 
> using meson but haven't had much success. Any pointers appreciated. Please 
> let me know if it's preferred to move this discussion/thread to issues.
>
> Here is the command I'm trying to run:
> meson setup -D llvm=true --prefix=%CD%/build/install build/  
> --buildtype=release -Dgallium-drivers=swrast -Dvulkan-drivers=swrast
>
> But I get this error:
> llvm-config found: NO need ['>= 5.0.0']
> Run-time dependency LLVM found: NO (tried cmake and config-tool)
> Looking for a fallback subproject for the dependency llvm (modules: 
> bitwriter, engine, mcdisassembler, mcjit, core, executionengine, scalaropts, 
> transformutils, instcombine, native)
> Building fallback subproject with default_library=static
>
> meson.build:1748:13: ERROR: Neither a subproject directory nor a llvm.wrap 
> file was found.

I haven't used it on Windows in a long time, but there are prebuilds

https://github.com/pal1000/mesa-dist-win

They might also help start off but also figure out what is missing in
llvm builds.

Dave.

Re: lost the way on how to trace JIT codes

[Dave Airlie]

On Wed, 6 Sept 2023 at 18:20, summer xia  wrote:
>
> I use this version: llvmpipe (LLVM 14.0.0, 256 bits Type: CPU API: 1.3.246) 
> as a backed vulkan engine. When I trace the whole pipeline that draws a 
> picture.I can trace all the C level codes as following hints:
>
> #0  lp_setup_draw_elements (vbr=0x55bcfe30, indices=0x55bcdf10, 
> nr=1023) at ../src/gallium/drivers/llvmpipe/lp_setup_vbuf.c:238
> #1  0x761d0707 in draw_pt_emit (emit=0x55bcfce0, 
> vert_info=0x7fffd966e718, prim_info=0x7fffd966e8d8) at 
> ../src/gallium/auxiliary/draw/draw_pt_emit.c:197
> #2  0x761cc208 in emit (emit=0x55bcfce0, 
> vert_info=0x7fffd966e718, prim_info=0x7fffd966e8d8) at 
> ../src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c:541
> #3  0x761cbe4c in llvm_pipeline_generic (middle=0x55bcfbd0, 
> fetch_info=0x0, in_prim_info=0x7fffd966e8d8) at 
> ../src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c:759
> #4  0x761ca5fc in llvm_middle_end_run (middle=0x55bcfbd0, 
> fetch_elts=0x55bccf10, fetch_count=683, draw_elts=0x55bcdf10, 
> draw_count=1023, prim_flags=2) at 
> ../src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c:812
> #5  0x76130283 in vsplit_flush_cache (vsplit=0x55bcced0, flags=2) 
> at ../src/gallium/auxiliary/draw/draw_pt_vsplit.c:78
> #6  0x76131236 in vsplit_segment_cache_uint (vsplit=0x55bcced0, 
> flags=2, istart=0, icount=1023, spoken=0 '\000', ispoken=0, close=0 '\000', 
> iclose=0) at ../src/gallium/auxiliary/draw/draw_pt_vsplit_tmp.h:163
> #7  0x76130f8c in vsplit_segment_simple_uint (vsplit=0x55bcced0, 
> flags=2, istart=0, icount=1023) at 
> ../src/gallium/auxiliary/draw/draw_pt_vsplit_tmp.h:173
> #8  0x7612f4cd in vsplit_run_uint (frontend=0x55bcced0, start=0, 
> count=5529600) at ../src/gallium/auxiliary/draw/draw_split_tmp.h:106
> #9  0x76122e96 in draw_pt_arrays (draw=0x55b96920, 
> prim=PIPE_PRIM_TRIANGLES, index_bias_varies=true, draw_info=0x7fffd966ec70, 
> num_draws=1) at ../src/gallium/auxiliary/draw/draw_pt.c:161
> #10 0x76122995 in draw_instances (draw=0x55b96920, 
> drawid_offset=0, info=0x55b7fb60, draws=0x7fffd966ec70, num_draws=1) at 
> ../src/gallium/auxiliary/draw/draw_pt.c:485
> #11 0x76122689 in draw_vbo (draw=0x55b96920, info=0x55b7fb60, 
> drawid_offset=0, indirect=0x0, draws=0x7fffd966ec70, num_draws=1, 
> patch_vertices=0 '\000') at ../src/gallium/auxiliary/draw/draw_pt.c:619
> #12 0x760757ee in llvmpipe_draw_vbo (pipe=0x55b8db40, 
> info=0x55b7fb60, drawid_offset=0, indirect=0x0, draws=0x7fffd966ec70, 
> num_draws=1) at ../src/gallium/drivers/llvmpipe/lp_draw_arrays.c:150
> #13 0x75c71083 in handle_draw_indexed (cmd=0x55dca790, 
> state=0x55b7faf0) at ../src/gallium/frontends/lavapipe/lvp_execute.c:2725
> #14 0x75c6f1e0 in lvp_execute_cmd_buffer (cmd_buffer=0x55b78520, 
> state=0x55b7faf0, print_cmds=false) at 
> ../src/gallium/frontends/lavapipe/lvp_execute.c:4324
> #15 0x75c6ef10 in lvp_execute_cmds (device=0x55b7e5f0, 
> queue=0x55b7f8e0, cmd_buffer=0x55b78520) at 
> ../src/gallium/frontends/lavapipe/lvp_execute.c:4621
> #16 0x75c682ba in lvp_queue_submit (vk_queue=0x55b7f8e0, 
> submit=0x55dccb80) at ../src/gallium/frontends/lavapipe/lvp_device.c:1548
> #17 0x75d651fd in vk_queue_submit_final (queue=0x55b7f8e0, 
> submit=0x55dccb80) at ../src/vulkan/runtime/vk_queue.c:377
> #18 0x75d67eef in vk_queue_submit_thread_func (_data=0x55b7f8e0) 
> at ../src/vulkan/runtime/vk_queue.c:490
> #19 0x75d45522 in impl_thrd_routine (p=0x55aa1ee0) at 
> ../src/c11/impl/threads_posix.c:67
> #20 0x77894b43 in start_thread (arg=) at 
> ./nptl/pthread_create.c:442
> #21 0x77926a00 in clone3 () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
>
>
> But when I want to make clear what this method's function :
>
> /* Run vertex fetch shader */
>   clipped = fpme->current_variant->jit_func(&fpme->llvm->jit_context,
> llvm_vert_info.verts,
> draw->pt.user.vbuffer,
> fetch_info->count,
> start,
> fpme->vertex_size,
> draw->pt.vertex_buffer,
> draw->instance_id,
> vertex_id_offset,
> draw->start_instance,
> elts,
> draw->pt.user.drawid,
> draw->pt.user.viewid);
> I can't step into this function with g

Re: Lavapipe performance question during interactive drawing

[Dave Airlie]

On Fri, 5 May 2023 at 21:30, George Karpathios  wrote:
>
> Hi list,
>
> I'm using Lavapipe for Vulkan software rendering support in a modeling 
> application. I notice a large performance hit (with any Mesa version) in the 
> following scenario: The user clicks & drags the mouse in order to create a 
> simple shape (e.g. plane, cube, sphere) dynamically and the result is being 
> rendered (basic gray shading) in real-time alongside the movement of the 
> mouse. Lavapipe seems to be struggling a bit to keep up with this action as 
> the frame time goes up to over 1 second. On the other hand, on a more 
> "static" scene I can get great fps (30-60) while panning/rotating a scene, 
> after Mike Blumenkrantz's recent improvements (many thanks for those again!).
>
> I've uploaded a screenshot of the VS profiler showing the hot path at 
> https://imgur.com/a/qZBkB51  and I'd appreciate hearing your thoughts on 
> this. Thanks once more for your time.

That's a lot of fragment shader recompiles in llvmpipe_update_fs,
LP_DEBUG=fs might give some more info if you have a debug build of
mes.

Dave.

Re: Advice on modifying Lavapipe to isolate JIT compilation in separate process

[Dave Airlie]

On Thu, 27 Apr 2023 at 15:18, Josh Gargus  wrote:
>
> Thanks for your advice!  I hadn't looked at Venus, but that seems like a very 
> promising place to start.
>
> The other approach feels more approachable now too; it feels like there are 
> less "unknown unknowns", although there are plenty of known unknowns to 
> investigate (address independence was one that was already bugging be before 
> I wrote to this list).

I think it shouldn't be too horrible to work out, another option might
be to abuse the cache somehow, but I think that still needs writable +
executable which probably doesn't help, but stuff should be address
independent as I do write x86 asm programs to the cache and read them
back out, only relocating around the global symbols.

>
> It seems like Venus is the more straightforward approach, so I'm inclined to 
> just go with it.  However, it seems like there would be a performance hit 
> compared to only doing JIT compilation in a separate process.  Do you have a 
> rough sense of the performance hit of serializing everything over Venus?  The 
> answer will depend on the workload, I know.

Yeah I think you'll definitely see a large perf hit than just moving
compilation out to a separate process, I'm not sure of the raw venus
overhead numbers here, someone else might have more information
available.

Dave.

Re: Advice on modifying Lavapipe to isolate JIT compilation in separate process

[Dave Airlie]

On Thu, 27 Apr 2023 at 05:27, Josh Gargus  wrote:
>
> Hi, I'm from the Fuchsia team at Google.  We would like to provide Lavapipe 
> as an ICD within Fuchsia.  However, our default security policy is to deny 
> client apps the capability to map memory as writable/executable; we don't 
> want to relax this for every client app which uses Vulkan.  Therefore, we are 
> investigating the feasibility of splitting "Lavapipe" into two parts, one of 
> which runs in a separate process.
>
> "Lavapipe" is in quotes because we don't know quite where the split should be 
> (that's what I'm here to ask you); perhaps it wouldn't be within Lavapipe per 
> se, but instead e.g. somewhere within llvmpipe.
>
> Another important goal is to make these changes in a way that is upstreamable 
> to Mesa.
>
> We considered a few different options, deeply enough to convince ourselves 
> that none of them seems desirable.  These ranged from proxying at the Vulkan 
> API level (so that almost everything runs in a separate process) to doing 
> only compilation in the separate process (into shared memory that is only 
> executable, not writable, in the client process).

Have you considered using venus over a socket/pipe to do it at the
vulkan layer? (just asking in case you hadn't).

>
> This exploration was limited by our unfamiliarity with the corner cases of 
> implementing a Vulkan driver.  For example, we're not quite clear on how much 
> code is generated outside of vkCreateGraphics/ComputePipelines().  For 
> example is there any code generated lazily, perhaps at draw time, to optimize 
> texture sampling?  That's just one question we don't know the answer to, and 
> there are surely many other questions we haven't thought to ask.
>
> Rather than delve into such minutiae, I'll simply ask how you recommend 
> approaching this problem.  Again, the two main constraints are:
> - no JITing code in the client process
> - clean enough solution to be upstreamable

So code is generated in a lot of places, particularly at shader bind
and at draw time depending on bound textures/samplers etc. I think
your best bet would be to maybe split a client/server model in the
gallivm layer. gallivm_compile_module to gallivm_jit_function are
where the LLVM executions happen, so you'd have to construct enough of
a standalone gallivm/LLVM environment to take an LLVM module, compile
it, pass back the JITed code in shared memory like you said. I'm not
sure how memory address independent the resulting binaries from llvm
are, or if they have to be placed at the same address. There are also
a bunch of global linkages for various things that have to be hooked
up, so there would need to be some thought around those (debug printf,
coroutine malloc hooks, and clock hook).

Dave.

Re: GL Error Handling: Is Mesa Broken?

[Dave Airlie]

On Tue, 12 Jul 2022 at 09:53, Mike Blumenkrantz
 wrote:
>
> Hi,
>
> I did a GL 4.6 CTS run today on a very recent version of CTS, and I found a 
> class of tests which target failure cases (specifically return codes) for 
> various API. A number of these tests failed, which means they fail for all 
> Mesa drivers, which means the upcoming CTS release will be impossible for any 
> Mesa driver to achieve conformance with.
>
> I'd ask any and all GL experts to check out this ticket
>
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/6851
>
> and try to help see whether the tests in question are broken or whether Mesa 
> is broken.

This is likely GLES vs GL expectations. esp if these are the new GLES
tests. The tests are likely just broken.

Dave.

Re: Replacing NIR with SPIR-V?

[Dave Airlie]

On Mon, 24 Jan 2022 at 06:52, Abel Bernabeu
 wrote:
>
> Dave,
>
> Am glad for the Mesa community to support the RISC-V effort with the advice 
> given so far.
>
> I hear your concerns regarding performance. I am familiar with the Larabee 
> case and know some of the people who worked on that. However, I am not here 
> to discuss what is the RISC-V strategy for graphics beyond the fact that 
> there is a NIR backend planned. That would be offtopic for this list.

We are pretty flexible on our topics since we moved most of the day to
day work to gitlab :-)

With the current chip architectures and possible vector extensions to
RISC-V, I think using llvmpipe and your current LLVM backend would be
as efficient as you can get, modulo optimising things more for
possible use cases you have. You might be able to add some fixed
function blocks to enhance things like texturing or blending.

I would think having a NIR backend would only really show usefulness
if you moved to a SIMT architecture, now you may have plans in that
area, and that might give you more reason to do NIR. Having a SIMT
architecture would be more around designing a GPU and you'd no longer
be considering it a RISC-V cpu at all that case and running general
purpose tasks would not be a goal.

>
> Join the Graphics and ML SIG at RISC-V and let us discuss it there.
>
> First join RISC-V as an individual contributor, strategic member or community 
> member:
> https://riscv.org/membership/
>
> Then join the Graphics and ML SIG through the Working Groups Portal. Feel 
> free to ask for details privately.

Thanks for the info, I'll see if I can manage that, but my time is
pretty stretched out here.

Dave.

Re: Replacing NIR with SPIR-V?

[Dave Airlie]

On Sun, 23 Jan 2022 at 22:58, Abel Bernabeu
 wrote:
>>
>> Yes, NIR arrays and struct and nir_deref to deal with them but, by the time 
>> you get into the back-end, all the nir_derefs are gone and you're left with 
>> load/store messages with actual addresses (either a 64-bit memory address or 
>> a index+offset pair for a bound resource).  Again, unless you're going to 
>> dump straight into LLVM, you really don't want to handle that in your 
>> back-end unless you really have to.
>
>
> That is the thing: there is already a community maintained LLVM backend for 
> RISC-V and I need to see how to get value from that effort. And that is a 
> very typical escenario for new architectures. There is already an LLVM 
> backend for a programmable device and someone asks: could you do some 
> graphics around this without spending millions?

No.

If you want something useful, it's going to cost millions over the
lifetime of creating it. This stuff is hard, it needs engineers who
understand it and they usually have to be paid.

RISC-V as-is isn't going to make a good compute core for a GPU. I
don't think any of the implementations are the right design. as long
as people get sucked into thinking it might, there'll be millions
wasted. SIMT vs SIMD is just making SSE-512 type decisions or
recreating Intel Larrabee efforts. Nobody has made an effective GPU in
this fashion. You'd need someone to create a new GPU with it's own
instruction set (maybe dervied from RISC-V), but with it's own
specialised compute core.

The alternate more tractable project is to possibly make sw rendering
(with llvmpipe) on RISC-V more palatable, but that's really just
optimising llvmpipe and the LLVM backend and maybe finding a few
instructions to enhance things. It might be possible to use a texture
unit to speed things up and really for software rendering and hw
rendering, memory bandwidth is a lot of the problem to solve.

Dave.

Re: revenge of CALLOC_STRUCT

[Dave Airlie]

On Sun, 26 Dec 2021 at 20:37, Jose Fonseca  wrote:
>
> I believe that as long as the CALLOC_STRUCT continue to get paired with right 
> FREE call (or equivalent if these get renamed) either way should work for us. 
>  Whatever option proposed gets followed, there's a risk these can get out of 
> balanced, but the risk seems comparable.
>
>
> For context, IIRC, the main reason these macros remain useful for VMware is 
> the sad state of memory debugging tools on Windows.  AFAICT, best hope of one 
> day deprecating this would be use AddressSanitizer, which is supported on 
> MSVC [1], but unfortunately not yet on MinGW w/ GCC [2], and we rely upon a 
> lot for day-to-day development, using Linux cross-compilation.  Using MinGW 
> w/ Clang cross compiler seems be a way to overcome this difficulty, but that 
> too was still in somewhat experimental state when I last tried it.
>
>

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14325

Is my attempt to rebalance things, there are a few current imbalance
I'd like to address before merging mesa/st code.

Dave.

revenge of CALLOC_STRUCT

[Dave Airlie]

Hey,

Happy holidays, and as though to consider over the break,

We have the vmware used MALLOC/FREE/CALLOC/CALLOC_STRUCT wrappers used
throughout gallium.

We have ST_CALLOC_STRUCT in use in the mesa state tracker, not used in gallium.

Merging the state tracker into mesa proper, and even prior to this a
few CALLOC_STRUCT have started to leak into src/mesa/*.

Now I don't think we want that, but CALLOC_STRUCT is a genuinely
useful macro on it's own,
I'm considering just defined a calloc_struct instead for the
non-gallium use that goes with malloc/calloc/free.

Any opinions, or should mesa just get u_memory.h support for Xmas?

Dave.

Re: Moving code around, post classic

[Dave Airlie]

On Tue, 7 Dec 2021 at 09:51, Dylan Baker  wrote:
>
> Classic is gone, and the cleanups have begun, obviously. There is
> another cleanup that I had in mind, which is moving src/mesa into
> src/gallium/frontends/mesa. This makes the build system a little
> cleaner, as currently we do some bending over backwards to get gallium,
> mesa, and their tests built in the right order. But that's a big ol `git
> mv`, and when I proposed it Dave and Ilia suggested it would be best to
> do all of the post-classic code motion at once. So, let's talk about
> what we want to move, and where we want to move it.
>
> Among the suggestions we had were:
>
> 1. Move src/mesa into src/gallium/frontends/mesa (I have patches for
>this)
>
>Seems like a pretty obvoius thing to do, given that all of the other
>gallium state trackers live there (OpenCL, video, d3d9, etc)

I'm against this just for history finding reasons, although git tracks
file renames it AFAIK fails to track directories, so you can only
follow the files not the whole subdir back through history once you
move it.

But I guess enough people want to see it happen, and it will.

>
> 2. Move src/compiler/glsl into src/gallium/frontends/mesa as well
>
> Given that there are now no? drivers that use GLSL-IR directly, it
> might make sense to move the glsl compiler into the mesa
> state_tracker, and just have that lower to TGSI or NIR, and treat
> GLSL-IR as an implementation detail of the OpenGL frontend.
>
> Unfortunately, there are a lot of code outside of glsl that uses the
> linked list implementation in the glsl compiler, and not the on in
> util.
>
> 3. Move src/gallium* to src/
>
> This was suggested, though given the existance of Vulkan, it wasn't
> clear that this was a good idea or not
>
> 4. What to do about the src/loader, src/glx, src/egl, src/mapi,
>src/glapi
>
> These are all part of OpenGL, but not really part of gallium, but if
> we don't move src/gallium/* to src/ does it make sense to leave them
> in the root?

src/opengl ?

Dave.

Re: [Mesa-dev] Enabling Mesa video frontends on top of D3D12 gallium driver

[Dave Airlie]

On Thu, 18 Nov 2021 at 18:45, Sil Vilerino
 wrote:
>
> Hello mesa-dev community,
>
>
>
> We are starting to work on adding support for D3D12 Video acceleration in the 
> mesa gallium D3D12 driver so that mesa frontends such as VA, VDPAU, etc can 
> leverage HW acceleration in those environments.
>
> To begin with we are working in a mesa fork project on a simple video decoder 
> prototype that implements the pipe_video_codec and pipe_video_buffer 
> interfaces with a D3D12 backend.
>

Welcome, to start I'm not authorative on this area of Mesa at all,
I've just started investigating vaapi and vulkan video decode.

I'm not really sure who understands all the ins/outs, I've cc'ed two
AMD contacts who have worked on this code.

> Wayland/Software screen creation in VA_DRIVER_INIT_FUNC
> In our d3d12 gallium driver, we rely on the EGL/GLX and the DRI frontend to 
> handle the pure swrast screen creation as our virtualized environment doesn’t 
> have devices listed under /dev/dri/*.
> The default for gstreamer/vainfo initialization code in WSL seems to be to 
> create a Wayland display and pass it to VAInitialize. If we go ahead and 
> create a pure software wayland d3d12_screen in 
> VA_DRIVER_INIT_FUNC(VADriverContextP ctx) we hit vaGetSurfaceBufferWl() is 
> not implemented at VAAPI Gallium state tracker (#587) · Issues · Mesa / mesa 
> · GitLab when trying to run a simple gstreamer pipeline that decodes with 
> VAAPI (and d3d12 video backend) and presents to screen in a display sink.
> From vaGetSurfaceBufferWl() is not implemented at VAAPI Gallium state tracker 
> (#587) · Issues · Mesa / mesa · GitLab discussion, it looks like “the change 
> removing "NOT_IMPLEMENTED" is wayland display should be opened with DRM code 
> path, and it's already implemented. the code here is not general switch to 
> turn on the wayland support on vaapi, it's just one of the steps to complete 
> that support and which has been implemented.”
> Could you please provide some details on the high level design of how wayland 
> supports for libva and gallium video drivers ?
> Which of the currently implemented paths in mesa is currently recommended in 
> general for video driver implementors: Wayland with DRM fd device or X 
> DRI/DR3?
> What’d be a recommended way of supporting pure swrast screens like d3d12 for 
> libva in VA_DRIVER_INIT_FUNC?
>
> Are there any objections to having a pure sw (no DRM devices) screen ?
> Another alternative we discussed was to enable VGEM in the WSL kernel and 
> create a wayland swrast screen using a kms_dri_create_winsys with the virtual 
> DRM device FD but that’d still require more work to support wayland 
> presentation to screen code paths (see next section below).
> Recommended present path
> Assuming we create a wayland screen (pure software or using VGEM + DRM) in 
> VA_DRIVER_INIT_FUNC, once end_frame() finishes execution and we have the 
> decoded image in pipe_video_buffer *target, what are the supported and 
> recommended paths for presenting to screen?
> Looks like both VDPAU (vlVdpPresentationQueueDisplay) and VAAPI 
> (vlVaPutSurface) call texture_from_drawable() to pass the associated 
> pipe_resource texture to flush_frontbuffer(), but the texture_from_drawable() 
> function seems only implemented on X backends 
> (vl_winsys_dri3/vl_winsys_dri.c) and not for vl_winsys_swrast/vl_winsys_drm. 
> As it’s mentioned that there’s support for wayland on vaapi, we’d like to get 
> some clarity on how the presentation path is designed here.

My expectation here is that making it operate like the GL paths is
probably what you want, and that if you are not using wayland there,
you shouldn't be doing it here. If you are there then adding support
for it here would be required.

I haven't investigated vaapi on wayland at all, and I probably need to
look into that soon, I'd expect adding proper support for presenting
would be a good feature to add there.

Currently at least using things like mplayer -hwdec=vaapi, the vaapi
code is just used to do the decode into dma-buf on Linux and then that
is handed off to a separate GL context for presentation.

Dave.

Re: [Mesa-dev] First merge request, should it have been noticed by now?

[Dave Airlie]

On Sun, 14 Nov 2021, 08:38 Autumn,  wrote:

> Hello! I submitted my first merge request to the Mesa GitLab earlier
> this month:
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13671
>
> It hasn't been noticed yet as far as I can tell. I don't need it
> reviewed quickly or anything, but I want to check if this is normal.
> Should I not have marked it "draft" as a precaution against merging the
> two commits I don't have the hardware to test?
>

I'm aware of it, just haven't had much time to do llvmpipe stuff past few
weeks, it just requires me paging back in quite a bit of history so I
sometimes wait until I have a few things in the area.

Dave.

>
> -- Autumn
>
>

Re: [Mesa-dev] vulkan video + beta header enables

[Dave Airlie]

On Fri, 5 Nov 2021 at 11:59, Jason Ekstrand  wrote:
>
> On Thu, Nov 4, 2021 at 8:53 PM Dave Airlie  wrote:
> >
> > Just polling for opinions here on how best to move forward with
> > enabling the provisional vulkan beta headers in Mesa and the fallout
> > from doing so for people importing updated vulkan headers.
> >
> > Do we want to allow beta/provisional features in main?
>
> IMO, it's fine as long as you never land the final patch which flips
> on the extension or, if you do, make sure it's very carefully guarded.

Well it's a bunch of extensions unfortunately.

Like do we want a meson option vulkan_beta?
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13685

If we have a vulkan-beta option, does that just enabling building with
the extensions or does it turn on those extensions?
or should we have another meson option for that or even an out of tree
patch in an MR as you suggest?

Dave.

[Mesa-dev] vulkan video + beta header enables

[Dave Airlie]

Just polling for opinions here on how best to move forward with
enabling the provisional vulkan beta headers in Mesa and the fallout
from doing so for people importing updated vulkan headers.

Do we want to allow beta/provisional features in main?

Do we want to do it only under a meson option that distros never enable?

If we do, who is responsible for updating the beta code on new header
import, since the video headers are under quite regular changes?

Dave.

Re: [Mesa-dev] struct gl_context

[Dave Airlie]

On Fri, 24 Sept 2021 at 16:35, an0oo0nym0oo0us OoO
 wrote:
>
> Hello everyone,
>
> I'm new to Mesa3D, and have read its source code for a last few days. I 
> cannot find where "struct gl_context" definition. Can you help me find it out?

src/mesa/main/mtypes.h

irc.oftc.net:#dri-devel is also available for answering these sort of
things faster.

Dave.

Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Dave Airlie]

> The texture has been taken from the wikipedia page
> https://en.wikipedia.org/wiki/Anisotropic_filtering#/media/File:Anisotropic_filtering_en.png
>
> The following images show results for both settings:
>
> image with anisotropic filtering (16)
> https://pasteboard.co/JNyFRkr.png
>
> image without anisotropic filtering
> https://pasteboard.co/JNyFlWb.png
>
> Andreas

Hey Andreas,

I've been away from this topic for a while, but I finally got back to
it, and I'm trying to pass the Vulkan/GL cts tests.

I reviewed the softpipe code and I think I found a bug in it vs the
original paper.

I've created an MR
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11917
with my proposed fix.

I'd really appreciate it if you could take a look.

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

Re: [Mesa-dev] Crocus causes image corruption and GPU HANG on GM45 - GMA 4500 MHD (and missing extensions)

[Dave Airlie]

On Sat, 10 Jul 2021 at 11:12, Jan Beich  wrote:
>
> Wladislav Artsimovich  writes:
>
> > Finally, on Gen4/Gen5 iGPUs, crocus does not expose
> > GL_EXT_gpu_shader4, thus modern GLSL functions are missing targets and
> > no "GL_ARB_blend_func_extended", as is normally possible on with i915
> > and documented here:
> > https://lists.freedesktop.org/archives/mesa-dev/2021-May/225249.html

I feel this email had some info I've missed.

GM45 in mesa master should now expose
GL_EXT_gpu_shader4/GL_ARB_blend_func_extended.

Dave.

>
> Could be related to the following:
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11693
> https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/706
>
> Both propagated downstream:
> https://github.com/freebsd/freebsd-ports/commit/d17122bb82e0 (mesa-devel)
> https://github.com/freebsd/freebsd-ports/commit/9339d0b45118 (xwayland-devel)
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] dma-buf: Document dma-buf implicit fencing/resv fencing rules

[Dave Airlie]

nted me at AMDGPU_GEM_CREATE_EXPLICIT_SYNC, which I
> entirely missed.
>
> This is great because it means the amdgpu specific piece for proper
> implicit fence handling exists already, and that since a while. The
> only thing that's now missing is
> - fishing the implicit fences out of a shared object at the right time
> - setting the exclusive implicit fence slot at the right time.
>
> Jason has a patch series to fill that gap with a bunch of generic
> ioctl on the dma-buf fd:
>
> https://lore.kernel.org/dri-devel/20210520190007.534046-1-ja...@jlekstrand.net/
>
> v3: Since Christian has fixed amdgpu now in
>
> commit 8c505bdc9c8b955223b054e34a0be9c3d841cd20 (drm-misc/drm-misc-next)
> Author: Christian König 
> Date:   Wed Jun 9 13:51:36 2021 +0200
>
> drm/amdgpu: rework dma_resv handling v3
>
> Use the audit covered in this commit message as the excuse to update
> the dma-buf docs around dma_buf.resv usage across drivers.
>
> Since dynamic importers have different rules also hammer these in
> again while we're at it.
>
> v4:
> - Add the missing "through the device" in the dynamic section that I
>   overlooked.
> - Fix a kerneldoc markup mistake, the link didn't connect
>

This is pretty epic commit msg, thanks for the investment, the commit
msg should be required reading.

Reviewed-by: Dave Airlie 

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

Re: [Mesa-dev] [Intel-gfx] [RFC PATCH 1/2] drm/doc/rfc: i915 GuC submission / DRM scheduler

[Dave Airlie]

On Sat, 5 Jun 2021 at 03:39, Daniel Vetter  wrote:
>
> On Wed, May 26, 2021 at 04:33:56PM -0700, Matthew Brost wrote:
> > Add entry for i915 GuC submission / DRM scheduler integration plan.
> > Follow up patch with details of new parallel submission uAPI to come.
> >
> > v2:
> >  (Daniel Vetter)
> >   - Expand explaination of why bonding isn't supported for GuC
> > submission
> >   - CC some of the DRM scheduler maintainers
> >   - Add priority inheritance / boosting use case
> >   - Add reasoning for removing in order assumptions
> >  (Daniel Stone)
> >   - Add links to priority spec
> >
> > Cc: Christian König 
> > Cc: Luben Tuikov 
> > Cc: Alex Deucher 
> > Cc: Steven Price 
> > Cc: Jon Bloomfield 
> > Cc: Jason Ekstrand 
> > Cc: Dave Airlie 
> > Cc: Daniel Vetter 
> > Cc: Jason Ekstrand 
> > Cc: dri-de...@lists.freedesktop.org
> > Signed-off-by: Matthew Brost 
>
> You have a one-line hunk in the next patch that probably should be here.
> With that moved.
>
> Reviewed-by: Daniel Vetter 

Acked-by: Dave Airlie 

And yes having the todos for GuC tracked would be good externally, so
pressure can be applied for new fw releases with those features.

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

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

[Dave Airlie]

On Tue, 27 Apr 2021 at 22:06, Christian König
 wrote:
>
> Correct, we wouldn't have synchronization between device with and without 
> user queues any more.
>
> That could only be a problem for A+I Laptops.

Since I think you mentioned you'd only be enabling this on newer
chipsets, won't it be a problem for A+A where one A is a generation
behind the other?

I'm not really liking where this is going btw, seems like a ill
thought out concept, if AMD is really going down the road of designing
hw that is currently Linux incompatible, you are going to have to
accept a big part of the burden in bringing this support in to more
than just amd drivers for upcoming generations of gpu.

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

Re: [Mesa-dev] [PATCH v4] drm/doc/rfc: i915 DG1 uAPI

[Dave Airlie]

On Tue, 20 Apr 2021 at 02:45, Matthew Auld  wrote:
>
> Add an entry for the new uAPI needed for DG1. Also add the overall
> upstream plan, including some notes for the TTM conversion.
>
> v2(Daniel):
>   - include the overall upstreaming plan
>   - add a note for mmap, there are differences here for TTM vs i915
>   - bunch of other suggestions from Daniel
> v3:
>  (Daniel)
>   - add a note for set/get caching stuff
>   - add some more docs for existing query and extensions stuff
>   - add an actual code example for regions query
>   - bunch of other stuff
>  (Jason)
>   - uAPI change(!):
> - try a simpler design with the placements extension
> - rather than have a generic setparam which can cover multiple
>   use cases, have each extension be responsible for one thing
>   only
> v4:
>  (Daniel)
>   - add some more notes for ttm conversion
>   - bunch of other stuff
>  (Jason)
>   - uAPI change(!):
> - drop all the extra rsvd members for the region_query and
>   region_info, just keep the bare minimum needed for padding

Staying out of the ioctl's being over engineering, I hope they have a
good future use case.

The plan seems like a good plan.

Acked-by: Dave Airlie 

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

Re: [Mesa-dev] Merging virtio-gpu vulkan driver

[Dave Airlie]

On Tue, 6 Apr 2021 at 03:22, Chia-I Wu  wrote:
>
> Hi list,
>
> We are looking to merge virtio-gpu vulkan driver
>
>   https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5800
>
> On the good side, the driver is conformant with Vulkan 1.2 (vtest) and
> Vulkan 1.1 (virtio-gpu).  I only tried it on a handful of games (e.g.,
> Dota 2, Hades on Proton with D3D and Vulkan backends, and some
> others), but it appeared to work with reasonable framerates.  I was
> told that it works with other games as well.
>
> I tried Basemark GPU a month ago on a Core i7-7820HQ.  The fps numbers were
>
>   quality highend: native 17.07, vtest 16.83, virtio-gpu 16.65
>   quality medium: native 98.19, vtest 91.15, virtio-gpu 92.29
>   quality simple: native 327.52, vtest 317.17, virtio-gpu 283.02
>
> On the bad side, the driver requires
>
>   VIRTIO_GPU_F_RESOURCE_BLOB (kernel 5.11 but not supported by qemu)
>   VIRTIO_GPU_F_CONTEXT_INIT (to be upstreamed[1])
>
> As a result, it can only be tested with crosvm[2] or vtest[3].
>

I've no major objections to merging this in an experimental state, not
having qemu support is of course an annoyance but at some point I
suppose that bridge will have to be crossed.

My main worry with no qemu support is locking in crosvm specific
behaviours that we later can't get back out of.

> We develop using anv as the host driver mostly.  Simple samples work
> when the host driver is radv, but games hit a host KVM bug quickly.
> The issue has been reported and we expect it to be fixed by upstream.
>
> The protocol for Vulkan command serialization is not finalized either.
> The driver is still marked experimental and must be enabled with
> -Dvulkan-drivers=virtio-experimental.  The plan is to mark the driver
> stable after the kernel ABI and the protocol ABI are finalized.

Sounds good.

Is the virglrenderer side merged? or is it a case of both sides
landing close to each other.

Dave.
>
> [1] https://gitlab.freedesktop.org/virgl/drm-misc-next/-/commits/context-init/
> [2] KVM-based VMM written in Rust
> https://chromium.googlesource.com/chromiumos/platform/crosvm/
> [3] vtest is a part of virglrenderer and is what I use for most of the
> developments
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] docs: consistent language

[Dave Airlie]

On Mon, 15 Mar 2021 at 22:44, Erik Faye-Lund
 wrote:
>
> TLDR; I'm proposing to standardize on US English in our public-facing
> documentation.
>
> I proposed an MR a while back that changed the only occurrence of the
> UK English spelling "optimisation" for the US English spelling
> "optimization", which is already used 34 times in the docs. I've done
> similar changes in the past.
>
> But this time Ian brought up the good point that picking a preferred
> language should probably be done using group consensus on the mailing
> list than just picking what's currently most popular.
>
> So, I hereby propose to pick US English as our default language for
> user-facing documentation.
>
> I'm not proposing to force anyone to use a particular English variant
> for things like comments, commit messages or variable names. I don't
> think there's much value in enforcing that, and I think it'd be
> perfectly fine if any particular driver wanted to pick a particular
> variant of English.
>
> The main reason I want to standardize on an English variant is that I'm
> trying create a word-list for domain-specific/technical language to
> detect spelling mistakes in the docs more easily. And not having to add
> both US and UK English words makes this list easier to maintain. I'm
> not planning on going 100% systematically though the dictionary to
> detect UK English words that might be in my system dictionary, just to
> fix the words that currently cause me (a tiny amount of) pain ;)
>
> The main reason why I'm proposing US English over for instance UK
> English is that this seems to be the dominant variant currently in the
> documentation. So it seems like the pragmatic choice to me.
>
> Thoughts? Any objections to sticking to US English in the docs?

All good, though I'm in the most likely to screw this up category,

I'm never sure when to use s or z so it usually ends up being rather random,
I think I've mostly got my outbreaks of colour under control.

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

Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Dave Airlie]

On Mon, 8 Feb 2021 at 19:04, Andreas Fänger  wrote:
>
>
> Am 08.02.2021 05:14, schrieb Dave Airlie:
> > On Wed, 3 Feb 2021 at 02:58, Michel Dänzer  wrote:
> >>
> >> On 2021-02-02 5:55 p.m., Michel Dänzer wrote:
> >> > On 2021-02-02 6:44 a.m., Dave Airlie wrote:
> >> >> On Mon, 1 Feb 2021 at 16:50, Dave Airlie  wrote:
> >> >>>
> >> >>> On Thu, 7 Jan 2021 at 21:11, Andreas Fänger 
> >> >>> wrote:
> >> >>>>
> >> >>>>>> don’t know why the current softpipe/swrast implementation
> >> >>>>>> shouldn’t be conformant.
> >> >>>>
> >> >>>>> Interesting I hadn't known we had a correct impl in mesa, the
> >> >>>>> features.txt has said "softpipe and llvmpipe advertise 16x
> >> >>>>> anisotropy but simply ignore the setting"
> >> >>>>> so I never dug any deeper. I'll consider a port of this to llvmpipe
> >> >>>>> at some point, making it efficient might be tricky.
> >> >>>>
> >> >>>> It seems that features.txt hasn't been updated regarding this
> >> >>>> functionality; softpipe has "real" anisotropy since 2011.
> >> >>>>
> >> >>>>> I'll consider a port of this to llvmpipe at some point, making it
> >> >>>>> efficient might be tricky.
> >> >>>> That would be great. As anisotropic filtering is often an option
> >> >>>> which can be set by a user, I guess most people turn it off to get
> >> >>>> higher framerates. But in our use case, high quality renderings are
> >> >>>> required, so we accept the longer render times to get the best
> >> >>>> quality; hopefully a llvmpipe port would be faster than the old
> >> >>>> swrast implementation (we are only using the fixed rendering
> >> >>>> pipeline/no shaders in conjunction with the OpenMP patch for
> >> >>>> speeding up GL_POLYGON_SMOOTH_HINT)
> >> >>>>
> >> >>>> Andreas
> >> >>>
> >> >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804
> >> >>>
> >> >>> Is my first pass at writing the code for this I've no idea if this is
> >> >>> anyway correct, but I'm just letting everyone know I've started
> >> >>> working on it, and mipmap_tunnel doesn't look immediately wrong.
> >> >>
> >> >> Olay the code in the MR above seems to work in most cases now and
> >> >> seems to operate like softpipe.
> >> >>
> >> >> However I'm seeing a trace failure
> >> >> https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/humus/Portals.trace/
> >> >>
> >> >
> >> > The floor at the bottom left of the Actual image definitely looks odd,
> >> > there's a hard line between the rock patterns.
> >>
> >> Not to mention the wall tiles having different sizes, with a hard line
> >> as well.
> >>
> >> Definitely looks like a bug to me, which wouldn't be noticeable with
> >> special test textures made up of different solid colours per mip
> >> level.
> >
> > I've fixed all the issues in that area, and I believe llvmpipe and
> > softpipe mostly produce the same or very similiar results.
> >
> > I'm not overly impressed though by the texture quality at least the
> > furmark trace shows as very blurry.
> >
> > Also the Vulkan CTS expects linear aniso to operate differently to how
> > this has done it.
> >
> > Andreas, can you comment on this trace?
> > https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7150044/gputest/furmark.trace/
> >
> > I'm pretty sure softpipe looks the same locally for the same trace,
> > and it just seems overly blurry.
>
> 1) Is it blurry in all cases you have tried or are there test cases
> where it is better?

I've only noticed it with furmark, but I don't have a lot of test
cases, the GL CTS passes, the Vulkan CTS does look blurry and fails
but it's unlikely that is due to the blur.

> 2) Are the results better compared to linear?

I'm not sure, better is pretty subjective measure here,

> 3) Is the reference image produced with another anisotropy
> implementation or with linear?

The reference image is produced with whatever llvmpipe path was taken
before this, which I assume is linear.

>
> If 2) is not what you expect, then maybe the softpipe version is not
> correct (anymore).
>
> In general, I remember that results are a bit more blurry (compared to
> linear) in the non-anisotropy case, ie. when textures are displayed
> undistorted at 100%. But this doesn't seem to be the case in the trace
> image here.

I'd be interested in any test data you have or any output, afaics the
llvmpipe output pretty much matches the softpipe output and if the
softpipe output is currently acceptable then we should merge the MR to
equalise them, and then fix any subsequent things on top in parallel.

I'd like to solve the VK CTS issue which does a linear vs anisotropic
compare and expects only a moderate amount of difference and we seem
to exceed the difference threshold.

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

Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Dave Airlie]

On Wed, 3 Feb 2021 at 02:58, Michel Dänzer  wrote:
>
> On 2021-02-02 5:55 p.m., Michel Dänzer wrote:
> > On 2021-02-02 6:44 a.m., Dave Airlie wrote:
> >> On Mon, 1 Feb 2021 at 16:50, Dave Airlie  wrote:
> >>>
> >>> On Thu, 7 Jan 2021 at 21:11, Andreas Fänger 
> >>> wrote:
> >>>>
> >>>>>> don’t know why the current softpipe/swrast implementation
> >>>>>> shouldn’t be conformant.
> >>>>
> >>>>> Interesting I hadn't known we had a correct impl in mesa, the
> >>>>> features.txt has said "softpipe and llvmpipe advertise 16x
> >>>>> anisotropy but simply ignore the setting"
> >>>>> so I never dug any deeper. I'll consider a port of this to llvmpipe
> >>>>> at some point, making it efficient might be tricky.
> >>>>
> >>>> It seems that features.txt hasn't been updated regarding this
> >>>> functionality; softpipe has "real" anisotropy since 2011.
> >>>>
> >>>>> I'll consider a port of this to llvmpipe at some point, making it
> >>>>> efficient might be tricky.
> >>>> That would be great. As anisotropic filtering is often an option
> >>>> which can be set by a user, I guess most people turn it off to get
> >>>> higher framerates. But in our use case, high quality renderings are
> >>>> required, so we accept the longer render times to get the best
> >>>> quality; hopefully a llvmpipe port would be faster than the old
> >>>> swrast implementation (we are only using the fixed rendering
> >>>> pipeline/no shaders in conjunction with the OpenMP patch for
> >>>> speeding up GL_POLYGON_SMOOTH_HINT)
> >>>>
> >>>> Andreas
> >>>
> >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804
> >>>
> >>> Is my first pass at writing the code for this I've no idea if this is
> >>> anyway correct, but I'm just letting everyone know I've started
> >>> working on it, and mipmap_tunnel doesn't look immediately wrong.
> >>
> >> Olay the code in the MR above seems to work in most cases now and
> >> seems to operate like softpipe.
> >>
> >> However I'm seeing a trace failure
> >> https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/humus/Portals.trace/
> >>
> >
> > The floor at the bottom left of the Actual image definitely looks odd,
> > there's a hard line between the rock patterns.
>
> Not to mention the wall tiles having different sizes, with a hard line
> as well.
>
> Definitely looks like a bug to me, which wouldn't be noticeable with
> special test textures made up of different solid colours per mip level.

I've fixed all the issues in that area, and I believe llvmpipe and
softpipe mostly produce the same or very similiar results.

I'm not overly impressed though by the texture quality at least the
furmark trace shows as very blurry.

Also the Vulkan CTS expects linear aniso to operate differently to how
this has done it.

Andreas, can you comment on this trace?
https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7150044/gputest/furmark.trace/

I'm pretty sure softpipe looks the same locally for the same trace,
and it just seems overly blurry.

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

Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Dave Airlie]

On Mon, 1 Feb 2021 at 16:50, Dave Airlie  wrote:
>
> On Thu, 7 Jan 2021 at 21:11, Andreas Fänger  wrote:
> >
> > >> don’t know why the current softpipe/swrast implementation shouldn’t be 
> > >> conformant.
> >
> > >Interesting I hadn't known we had a correct impl in mesa, the features.txt 
> > >has said "softpipe and llvmpipe advertise 16x anisotropy but simply ignore 
> > >the setting"
> > >so I never dug any deeper. I'll consider a port of this to llvmpipe at 
> > >some point, making it efficient might be tricky.
> >
> > It seems that features.txt hasn't been updated regarding this 
> > functionality; softpipe has "real" anisotropy since 2011.
> >
> > > I'll consider a port of this to llvmpipe at some point, making it 
> > > efficient might be tricky.
> > That would be great. As anisotropic filtering is often an option which can 
> > be set by a user, I guess most people turn it off to get higher framerates. 
> > But in our use case, high quality renderings are required, so we accept the 
> > longer render times to get the best quality; hopefully a llvmpipe port 
> > would be faster than the old swrast implementation (we are only using the 
> > fixed rendering pipeline/no shaders in conjunction with the OpenMP patch 
> > for speeding up GL_POLYGON_SMOOTH_HINT)
> >
> > Andreas
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804
>
> Is my first pass at writing the code for this I've no idea if this is
> anyway correct, but I'm just letting everyone know I've started
> working on it, and mipmap_tunnel doesn't look immediately wrong.

Olay the code in the MR above seems to work in most cases now and
seems to operate like softpipe.

However I'm seeing a trace failure
https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/humus/Portals.trace/

that worries me that maybe the softpipe code isn't great, I'm going to
try and reproduce the traces on softpipe locally to see how they look.

I'd appreciate any testing that can be given to this code by preexisting users.

Dave.

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

Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Dave Airlie]

On Thu, 7 Jan 2021 at 21:11, Andreas Fänger  wrote:
>
> >> don’t know why the current softpipe/swrast implementation shouldn’t be 
> >> conformant.
>
> >Interesting I hadn't known we had a correct impl in mesa, the features.txt 
> >has said "softpipe and llvmpipe advertise 16x anisotropy but simply ignore 
> >the setting"
> >so I never dug any deeper. I'll consider a port of this to llvmpipe at some 
> >point, making it efficient might be tricky.
>
> It seems that features.txt hasn't been updated regarding this functionality; 
> softpipe has "real" anisotropy since 2011.
>
> > I'll consider a port of this to llvmpipe at some point, making it efficient 
> > might be tricky.
> That would be great. As anisotropic filtering is often an option which can be 
> set by a user, I guess most people turn it off to get higher framerates. But 
> in our use case, high quality renderings are required, so we accept the 
> longer render times to get the best quality; hopefully a llvmpipe port would 
> be faster than the old swrast implementation (we are only using the fixed 
> rendering pipeline/no shaders in conjunction with the OpenMP patch for 
> speeding up GL_POLYGON_SMOOTH_HINT)
>
> Andreas

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804

Is my first pass at writing the code for this I've no idea if this is
anyway correct, but I'm just letting everyone know I've started
working on it, and mipmap_tunnel doesn't look immediately wrong.

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

Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Dave Airlie]

On Thu, 7 Jan 2021 at 18:49, Andreas Fänger  wrote:
>
> Hi Dave,
>
>
>
> don’t know why the current softpipe/swrast implementation shouldn’t be 
> conformant.

Interesting I hadn't known we had a correct impl in mesa, the
features.txt has said
"softpipe and llvmpipe advertise 16x anisotropy but simply ignore the setting"

so I never dug any deeper. I'll consider a port of this to llvmpipe at
some point, making it efficient might be tricky.

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

Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Dave Airlie]

On Thu, 7 Jan 2021, 17:31 Andreas Fänger,  wrote:

> Hi Dave,
>
>
>
> sounds good. Is there a particular reason not to port the softpipe anisotropic
> filter implementation (or from swrast, they are almost identical)?
> Wouldn’t that be easier to implement as it is based on the gallium
> infrastructure already?
>

I hadn't really looked at mesa I had thought the aniso impl weren't
conformant, I'll look again next week when I get back to work.

Dave.

>
>
> Andreas
>
>
>
> *Von:* mesa-dev  *Im Auftrag von *Dave
> Airlie
> *Gesendet:* Donnerstag, 7. Januar 2021 05:56
> *An:* Brian Paul 
> *Cc:* mesa-dev ;
> mesa-us...@lists.freedesktop.org
> *Betreff:* Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of
> classic OSMesa
>
>
>
>
>
> I have some plans nothing firm to add some sort of aniso to llvmpipe. I
> was considering porting code from swiftshader, maybe I can bump it up the
> priority list.
>
>
>
> Dave.
>
>
>
> On Tue, 5 Jan 2021, 06:02 Brian Paul,  wrote:
>
>
>
>  Forwarded Message 
> Subject:[Mesa-users] Issues with removal of classic OSMesa
> Date:   Thu, 31 Dec 2020 12:56:04 +0100
> From:   Andreas Fänger 
> To: mesa-us...@lists.freedesktop.org
>
> Hi,
>
> I've just seen that classic OSMesa has been removed (again) from Mesa3D
> a few weeks ago with this commit "mesa: Retire classic OSMesa".
>
> We are still actively using classical OSMesa for high quality rendering
> of still images in a headless environment with no GPU support
> (server-based rendering on windows and linux)
>
> Unfortunately, none of the alternative software renderers provide all
> the features that we require, which is antialiasing and anisotropic
> filtering. The current state is (correct me if I'm wrong)
>
> * softpipe: anisotropic filtering is supported, no antialiasing
>
> * llvmpipe: no anisotropic filtering, has MSAA
>
>
>
>
>
> * openswr: no anisotropic filtering, has MSAA, no OSMesa interface (?)
>
> We had hoped that classical OSMesa is only removed when there is a full
> replacement after the discussions in 2016 when OSMesa was about to be
> removed for the first time
>
> https://lists.freedesktop.org/archives/mesa-dev/2016-March/109665.html
>
> https://lists.freedesktop.org/archives/mesa-users/2016-March/001132.html
>
> and the commit that reverted the removal
>
>
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=9601815b4be886f4d92bf74916de98f3bdb7275c
>
> Are there any plans to enhance the renderers so that at least one of
> them is providing both anisotropic filtering and antialiasing?
>
> As far as I know, anisotropic texture filtering is also one of the
> OpenGL 4.6 requirements.
>
> In 2016 I was told that there are only very few developers involved in
> llvmpipe and that chances are not high that someone is going to port the
> softpipe anisotropic filtering implementation as llvmpipe is much more
> complex. Is there any change in that situation?
>
>
>
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Dave Airlie]

I have some plans nothing firm to add some sort of aniso to llvmpipe. I was
considering porting code from swiftshader, maybe I can bump it up the
priority list.

Dave.

On Tue, 5 Jan 2021, 06:02 Brian Paul,  wrote:

>
>
>  Forwarded Message 
> Subject:[Mesa-users] Issues with removal of classic OSMesa
> Date:   Thu, 31 Dec 2020 12:56:04 +0100
> From:   Andreas Fänger 
> To: mesa-us...@lists.freedesktop.org
>
> Hi,
>
> I've just seen that classic OSMesa has been removed (again) from Mesa3D
> a few weeks ago with this commit "mesa: Retire classic OSMesa".
>
> We are still actively using classical OSMesa for high quality rendering
> of still images in a headless environment with no GPU support
> (server-based rendering on windows and linux)
>
> Unfortunately, none of the alternative software renderers provide all
> the features that we require, which is antialiasing and anisotropic
> filtering. The current state is (correct me if I'm wrong)
>
> * softpipe: anisotropic filtering is supported, no antialiasing
>
> * llvmpipe: no anisotropic filtering, has MSAA


>
>
> * openswr: no anisotropic filtering, has MSAA, no OSMesa interface (?)
>
> We had hoped that classical OSMesa is only removed when there is a full
> replacement after the discussions in 2016 when OSMesa was about to be
> removed for the first time
>
> https://lists.freedesktop.org/archives/mesa-dev/2016-March/109665.html
>
> https://lists.freedesktop.org/archives/mesa-users/2016-March/001132.html
>
> and the commit that reverted the removal
>
>
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=9601815b4be886f4d92bf74916de98f3bdb7275c
>
> Are there any plans to enhance the renderers so that at least one of
> them is providing both anisotropic filtering and antialiasing?
>
> As far as I know, anisotropic texture filtering is also one of the
> OpenGL 4.6 requirements.
>
> In 2016 I was told that there are only very few developers involved in
> llvmpipe and that chances are not high that someone is going to port the
> softpipe anisotropic filtering implementation as llvmpipe is much more
> complex. Is there any change in that situation?
>
>
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] NIR to TGSI for Vulkan SPIRV shaders

[Dave Airlie]

It's not supported and not useful in any way. TGSI llvmpipe is missing a
lot of features.

Dave

On Thu, 19 Nov 2020, 18:35 Tommy Chou,  wrote:

> Hi,
>
> When running Vulkan code through lavapipe, SPIRV shaders are first
> converted to NIR. Is it possible to further translate or dump that NIR to
> TGSI format or is it unsupported? I tried running vkcube with
> LP_DEBUG=tgsi,tgsi_ir but it segfaulted.
>
> Thanks,
> Tommy
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] clover's interface to clang

[Dave Airlie]

On Thu, 12 Nov 2020 at 06:37, Dave Airlie  wrote:
>
> On Thu, 12 Nov 2020 at 06:23, Francisco Jerez  wrote:
> >
> > I don't remember the specifics of why we ended up interfacing with Clang
> > this way.  What is technically wrong with it, specifically?  I don't
> > have any objection to switching to the Driver and Compilation interface,
> > nor to translating the "-cl-denorms-are-zero" option to whatever the
> > current option name is so the current Clang interfacing keeps working.
>
> Currently we pass a bunch of options from the user directly to the
> clang cc1 internals. Up until recently this wasn't a problem as the
> cc1 just happened to allow this and the options matched up. But this
> was only ever a happy accident.
>
> Now the options don't match up. What you are meant to do is pass the
> options to the clang Driver and it gives you back a cc1 job which has
> the cc1 specific arguments for what you passed to the driver.
>
> So Driver sees "-cl-denorms-are-zero" and gives us back a compilation
> job for cc1 which has some internal -f flags in it.
>
> Otherwise clover has to keep track of the internal cc1 flags and remap
> things itself which might not be easily discoverable moving forward.

I hacked a bit of a PoC up today for this
https://gitlab.freedesktop.org/airlied/mesa/-/commit/0981cd24ae6653ef058cbcbb5465f65d0cfdae65

Will try and make it better.

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

Re: [Mesa-dev] clover's interface to clang

[Dave Airlie]

On Thu, 12 Nov 2020 at 06:23, Francisco Jerez  wrote:
>
> I don't remember the specifics of why we ended up interfacing with Clang
> this way.  What is technically wrong with it, specifically?  I don't
> have any objection to switching to the Driver and Compilation interface,
> nor to translating the "-cl-denorms-are-zero" option to whatever the
> current option name is so the current Clang interfacing keeps working.

Currently we pass a bunch of options from the user directly to the
clang cc1 internals. Up until recently this wasn't a problem as the
cc1 just happened to allow this and the options matched up. But this
was only ever a happy accident.

Now the options don't match up. What you are meant to do is pass the
options to the clang Driver and it gives you back a cc1 job which has
the cc1 specific arguments for what you passed to the driver.

So Driver sees "-cl-denorms-are-zero" and gives us back a compilation
job for cc1 which has some internal -f flags in it.

Otherwise clover has to keep track of the internal cc1 flags and remap
things itself which might not be easily discoverable moving forward.

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

[Mesa-dev] clover's interface to clang

[Dave Airlie]

Hey all (mostly Tom).

I've been learning new things today since Matt pushed a patch to clang
to remove "-cl-denorms-are-zero" from cc1 options. I thought this was
a regression or we should hack things to pass a different flag (which
I did locally for testing), but Matt informed me clover is likely
interfacing to clang wrong.

The correct way to do things seems to be to build up a set of command
line args pass those to the Driver, create a Compilation object, with
jobs, and then execute each job in turns, one of the jobs would be a
cc1 job and the driver would have all the correct arguments for it.

Now I'll likely dig into this a bit more, but I was wondering if
anyone knows historically why this wasn't done. I know for example
with clover we really only want to use a the cc1 pass since at least
for the NIR backend we just want to emit LLVM bytecode and pass it to
the spirv conversion, so using the driver might be overkill.

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

[Mesa-dev] llvmpipe is OpenGL 4.5 conformant.

[Dave Airlie]

Just to let everyone know, a month ago I submitted the 20.2 llvmpipe
driver for OpenGL 4.5 conformance under the SPI/X.org umbrella, and it
is now official[1].

Thanks to everyone who helped me drive this forward, and to all the
contributors both to llvmpipe and the general Mesa stack that enabled
this.

Big shout out to Roland Scheidegger for helping review the mountain of
patches I produced in this effort.

My next plans involved submitting lavapipe for Vulkan 1.0, it's at 99%
or so CTS, but there are line drawing, sampler accuracy and some snorm
blending failure I have to work out.
I also ran the OpenCL 3.0 conformance suite against clover/llvmpipe
yesterday and have some vague hopes of driving that to some sort of
completion.

(for GL 4.6 only texture anisotropy is really missing, I've got
patches for SPIR-V support, in case someone was feeling adventurous).

Dave.

[1] 
https://www.khronos.org/conformance/adopters/conformant-products/opengl#submission_272
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Rust drivers in Mesa

[Dave Airlie]

On Fri, 2 Oct 2020 at 15:01, Jason Ekstrand  wrote:
>
> On Thu, Oct 1, 2020 at 10:56 PM Rob Clark  wrote:
> >
> > On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig
> >  wrote:
> > >
> > > Implications for the build system vary. Rust prefers to be built by its
> > > own package manager, Cargo, which is tricky to integrate with other
> > > build systems. Actually, Meson has native support for Rust, invoking the
> > > compiler directly and skipping Cargo, as if it were C code. This support
> > > is not widely adopted as it prevents linking with external libraries
> > > ("crates", in Rust parlance), with discussions between Rust and Meson
> > > developers ending in a stand-still [1]. For Mesa, this might be just
> > > fine. Our out-of-tree run-time dependencies are minimal for the C code,
> > > and Rust's standard library largely avoids the need for us to maintain a
> > > Rust version of util/ in-tree. If this proves impractical in the
> > > long-term, it is possible to integrate Cargo with Meson on our end [2].
> > >
> >
> > drive-by comment: for something like a gl driver that a lot of other
> > things depend on, making it harder for us to depend on other external
> > things is actually a good thing
>
> Generally, I'm a fan in concept.  Generally, I feel like rust has most
> of what I like from C++ without most of what I don't like.  I
> particularly like it's error handling mechanism, for instance.  That
> said, when it comes to things like the borrow checker, my little bit
> of rust experience says that it doesn't actually remove bugs so much
> as move them around.
>
> What's been stopping me is practicalities.  Not only build systems but
> the way in which everything in mesa is interconnected.  Your
> suggestion for building the entire back-end compiler with C-wrapped
> helpers for NIR->compiler translation may be workable.  We might also
> be able to write NIR wrappers sufficient for reading NIR.  It's not
> actually that much API surface if all you want to do is read the data
> structure.
>
> I've also thought of breaking off a component like ISL and converting
> it.  However, all the nicely contained pieces are also the ones that
> wouldn't benefit as much. :-/
>

My feeling is the pieces that would benefit the most are the things
touch the real world, GLSL compiler, SPIR-V handling, maybe some of
the GL API space, but I also feel these are the messiest things to
move to rust. I'm not sure you'd get much benefit from vulkan API
space or touching kernel interfaces as much. Granted a backend
compiler might be the easiest place to experiment.

I think the problem is you really want to justify that whatever you
introduce using rust is sufficiently better along any axis than c/c++
to justify the enhanced build time requirements and maintenance,
otherwise someone will just rewrite it in C/C++ to avoid having to
pull a rust compiler into their distro requires.

Dave.
___
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

[Dave Airlie]

On Mon, 24 Aug 2020 at 10:12, Jacob Lifshay  wrote:
>
> On Sun, Aug 23, 2020, 17:08 Luke Kenneth Casson Leighton  
> wrote:
>>
>>
>>
>> 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?
>
>
> yes, iirc.
>>
>>
>> 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?
>
>
> no, that is the existing LLVM backend from AMD's opengl/opencl drivers. 
> amdvlk came later.

Those are the same codebase, amdvlk just uses a fork of llvm, but the
differences are only minor changes for impedance mismatch and release
timing, they never diverge more than necessary.

Dave.
___
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

[Dave Airlie]

On Mon, 24 Aug 2020 at 09:10, Jacob Lifshay  wrote:
>
> On Sun, Aug 23, 2020, 15:55 Dave Airlie  wrote:
>>
>> What is your work submission model then, Vulkan is designed around
>> having work submitted to a secondary processor from a control
>> processor. Do you intend for the device to be used only as a
>> coprocessor, or as a CPU for normal tasks that can then use the
>> features in their threads, because none of the API are designed around
>> that model. They have a running thread of execution that queues stuff
>> up to a separate execution domain.
>
>
> It's intended to be a combination, where CPU threads schedule work and render 
> threads dequeue and run the work, probably using something like Rayon:
> https://github.com/rayon-rs/rayon
>
> When a CPU thread waits in the Vulkan driver, it can possibly be used as a 
> render thread instead of blocking on a futex, avoiding needing excessive 
> numbers of Linux kernel-level threads.
>
> The CPU and render threads run on the same cores, as scheduled by Linux.
>>
>>
>> What represents a vulkan queue,
>
>
> The rayon task queues.
>
>> what will be recorded into vulkan
>> command buffers,
>
>
> a command sequence encoded as bytecode, a list of Rust enums, or something 
> similar.
>
>> what will execute those command buffers.
>
>
> the render threads will dequeue the command buffers, run through all the 
> commands in them, and schedule the appropriate rendering tasks to rayon's 
> task execution mechanism.
>
>> These are
>> the questions you need to ask yourself and answer before writing any
>> code.
>
>

It's hard to know then what you can expect to leverage from Mesa for
that sort of architecture, the SPIRV->NIR translation, and then you
probably want some sort of driver specific NIR->LLVM translation,
amdgpu is completely scalar, llvmpipe is manually vectorised, swr does
something like you might want, afaik it does a scalar translation and
then magic execution (but I haven't dug into it except to fix
interfaces).

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, and you workout how texture derivatives work early, it might be
something prototype-able.

But none of the current mesa drivers are even close to this
architecture, llvmpipe or swr are probably a bit closer than anything,
so it's likely you'll be doing most of this out-of-tree anyways. My
other feeling is it sounds like over architecting, and reaching for
the stars here, where it might be practical to bring vallium/llvmpipe
up on the architecture first then work out how to do the big new
thing, or bring up this architecture on an x86 chip and see it works
at all.

Dave.
___
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

[Dave Airlie]

On Mon, 24 Aug 2020 at 07:25, Luke Kenneth Casson Leighton
 wrote:
>
> 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".

What is your work submission model then, Vulkan is designed around
having work submitted to a secondary processor from a control
processor. Do you intend for the device to be used only as a
coprocessor, or as a CPU for normal tasks that can then use the
features in their threads, because none of the API are designed around
that model. They have a running thread of execution that queues stuff
up to a separate execution domain.

What represents a vulkan queue, what will be recorded into vulkan
command buffers, what will execute those command buffers. These are
the questions you need to ask yourself and answer before writing any
code.

Dave.
___
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

[Dave Airlie]

> (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 don't want to get involved in half-thought out schemes here, but I'm
going to indulge myself in one post.

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.

llvmpipe takes NIR, vectorises it, converts it to LLVM IR, and uses
LLVM to create an executable piece of code that for rasterization and
compute is run multiple times across multiple threads on the CPU.

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'm guessing you want to add an LLVM backend for your "GPU"
instructions (are these all vectorised?), and just work out how to use
llvmpipe and vallium. Any perceived design issues in llvmpipe will be
totally in the noise compared to designing a CPU rasterizer by
yourself.

But I'd also suggest not distracting people here with too much noise,
if loading a skeleton vulkan driver is this hard, writing a rasterizer
is infinitely harder.

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

[Mesa-dev] CI for vallium question

[Dave Airlie]

meson-gallium builds all the gallium drivers but no vulkan drivers.
meson-vulkan builds all the vulkan driver but no gallium.

I've changed the enable to be -Dvulkan-drivers=swrast to enable it, so
I suppose the former is more suitable, but just looking for
suggestions.

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

Re: [Mesa-dev] swrast gallium provider doesn't work on Solaris SPARC (Mesa 20 with LLVM 10)

[Dave Airlie]

FYI:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5677

Dave.

On Thu, 21 May 2020 at 05:14, Roland Scheidegger  wrote:
>
> Oh I missed that sparc is big endian.
> Still not sure where the llvm IR would differ but indeed some different
> unpacking somewhere could explain things.
> (And I'd guess we'd get issues reported for other big endian archs soon
> enough too...)
>
> Roland
>
>
> Am 19.05.20 um 22:00 schrieb Adam Jackson:
> > On Wed, 2020-05-13 at 18:27 +0200, Petr Sumbera wrote:
> >> Hi,
> >>
> >> I have difficulties with Mesa update from version Mesa 18 (LLVM 6) where
> >> it used to work.
> >>
> >> Now with Mesa 20 and LLVM 10 glxgears doesn't show wheels but just some
> >> random rectangles. Please see attached picture.
> >>
> >> Any idea what could be possibly wrong?
> >
> > You have the misfortune to be using a big-endian CPU, and that
> > corruption looks quite a lot like the vertex processing stage getting
> > channel order wrong. Since the internals of both TGSI and NIR ought to
> > be endian-indifferent, I suspect the error would be at point where you
> > acquire the vertex data from the app and need to do machine-specific
> > unpacking, but that's just a guess. Dumping the IR generated by each
> > should hopefully be instructive.
> >
> > It might also be worth trying to build Mesa 20 against LLVM 6 to see if
> > that points to anything in LLVM, but that's probably a bit less likely.
> >
> > - ajax
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Csroland%40vmware.com%7C257d443c503846a91b3708d7fc2f4a38%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637255152405729735&sdata=6bzf3CQhwNaivcjX4%2BnqxjDJ2TaIdI8MDArHSwgVxSo%3D&reserved=0
> >
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 2/4] gallium/auxiliary: Add helper support for bptc format compress/decompress

[Dave Airlie]

On Wed, 27 Jun 2018 at 06:36, Denis Pauk  wrote:
>
> Reuse code shared with mesa/main/texcompress_bptc.
>
> v2: Use block decompress function
> v3: Include static bptc code from texcompress_bptc_tmp.h
> Suggested-by: Marek Olšák 
>
> Signed-off-by: Denis Pauk 
> CC: Nicolai Hähnle 
> CC: Marek Olšák 
> CC: Gert Wollny 
> ---

Hi Denis,

not sure you are still around or interested in this code, but I've
recently run Vulkan CTS over it and it fails some bc7 tests.

It also fails a piglit test that I'm not sure is related or not yet.

It only seems to be a corner case failure, like 6 or 7 pixels in the
CTS cases, but I'm wondering if you have any insight or memory of
where it might diverge.

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

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Dave Airlie]

On Sat, 29 Feb 2020 at 05:34, Eric Anholt  wrote:
>
> On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie  wrote:
> >
> > On Fri, 28 Feb 2020 at 18:18, Daniel Stone  wrote:
> > >
> > > On Fri, 28 Feb 2020 at 03:38, Dave Airlie  wrote:
> > > > b) we probably need to take a large step back here.
> > > >
> > > > Look at this from a sponsor POV, why would I give X.org/fd.o
> > > > sponsorship money that they are just giving straight to google to pay
> > > > for hosting credits? Google are profiting in some minor way from these
> > > > hosting credits being bought by us, and I assume we aren't getting any
> > > > sort of discounts here. Having google sponsor the credits costs google
> > > > substantially less than having any other company give us money to do
> > > > it.
> > >
> > > The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> > > comparable in terms of what you get and what you pay for them.
> > > Obviously providers like Packet and Digital Ocean who offer bare-metal
> > > services are cheaper, but then you need to find someone who is going
> > > to properly administer the various machines, install decent
> > > monitoring, make sure that more storage is provisioned when we need
> > > more storage (which is basically all the time), make sure that the
> > > hardware is maintained in decent shape (pretty sure one of the fd.o
> > > machines has had a drive in imminent-failure state for the last few
> > > months), etc.
> > >
> > > Given the size of our service, that's a much better plan (IMO) than
> > > relying on someone who a) isn't an admin by trade, b) has a million
> > > other things to do, and c) hasn't wanted to do it for the past several
> > > years. But as long as that's the resources we have, then we're paying
> > > the cloud tradeoff, where we pay more money in exchange for fewer
> > > problems.
> >
> > Admin for gitlab and CI is a full time role anyways. The system is
> > definitely not self sustaining without time being put in by you and
> > anholt still. If we have $75k to burn on credits, and it was diverted
> > to just pay an admin to admin the real hw + gitlab/CI would that not
> > be a better use of the money? I didn't know if we can afford $75k for
> > an admin, but suddenly we can afford it for gitlab credits?
>
> As I think about the time that I've spent at google in less than a
> year on trying to keep the lights on for CI and optimize our
> infrastructure in the current cloud environment, that's more than the
> entire yearly budget you're talking about here.  Saying "let's just
> pay for people to do more work instead of paying for full-service
> cloud" is not a cost optimization.
>
>
> > > Yes, we could federate everything back out so everyone runs their own
> > > builds and executes those. Tinderbox did something really similar to
> > > that IIRC; not sure if Buildbot does as well. Probably rules out
> > > pre-merge testing, mind.
> >
> > Why? does gitlab not support the model? having builds done in parallel
> > on runners closer to the test runners seems like it should be a thing.
> > I guess artifact transfer would cost less then as a result.
>
> Let's do some napkin math.  The biggest artifacts cost we have in Mesa
> is probably meson-arm64/meson-arm (60MB zipped from meson-arm64,
> downloaded by 4 freedreno and 6ish lava, about 100 pipelines/day,
> makes ~1.8TB/month ($180 or so).  We could build a local storage next
> to the lava dispatcher so that the artifacts didn't have to contain
> the rootfs that came from the container (~2/3 of the insides of the
> zip file), but that's another service to build and maintain.  Building
> the drivers once locally and storing it would save downloading the
> other ~1/3 of the inside of the zip file, but that requires a big
> enough system to do builds in time.
>
> I'm planning on doing a local filestore for google's lava lab, since I
> need to be able to move our xml files off of the lava DUTs to get the
> xml results we've become accustomed to, but this would not bubble up
> to being a priority for my time if I wasn't doing it anyway.  If it
> takes me a single day to set all this up (I estimate a couple of
> weeks), that costs my employer a lot more than sponsoring the costs of
> the inefficiencies of the system that has accumulated.

I'm not trying to knock the engineering works the CI contributors have
done at all, but I've never se

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Dave Airlie]

On Fri, 28 Feb 2020 at 18:18, Daniel Stone  wrote:
>
> On Fri, 28 Feb 2020 at 03:38, Dave Airlie  wrote:
> > b) we probably need to take a large step back here.
> >
> > Look at this from a sponsor POV, why would I give X.org/fd.o
> > sponsorship money that they are just giving straight to google to pay
> > for hosting credits? Google are profiting in some minor way from these
> > hosting credits being bought by us, and I assume we aren't getting any
> > sort of discounts here. Having google sponsor the credits costs google
> > substantially less than having any other company give us money to do
> > it.
>
> The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> comparable in terms of what you get and what you pay for them.
> Obviously providers like Packet and Digital Ocean who offer bare-metal
> services are cheaper, but then you need to find someone who is going
> to properly administer the various machines, install decent
> monitoring, make sure that more storage is provisioned when we need
> more storage (which is basically all the time), make sure that the
> hardware is maintained in decent shape (pretty sure one of the fd.o
> machines has had a drive in imminent-failure state for the last few
> months), etc.
>
> Given the size of our service, that's a much better plan (IMO) than
> relying on someone who a) isn't an admin by trade, b) has a million
> other things to do, and c) hasn't wanted to do it for the past several
> years. But as long as that's the resources we have, then we're paying
> the cloud tradeoff, where we pay more money in exchange for fewer
> problems.

Admin for gitlab and CI is a full time role anyways. The system is
definitely not self sustaining without time being put in by you and
anholt still. If we have $75k to burn on credits, and it was diverted
to just pay an admin to admin the real hw + gitlab/CI would that not
be a better use of the money? I didn't know if we can afford $75k for
an admin, but suddenly we can afford it for gitlab credits?

> Yes, we could federate everything back out so everyone runs their own
> builds and executes those. Tinderbox did something really similar to
> that IIRC; not sure if Buildbot does as well. Probably rules out
> pre-merge testing, mind.

Why? does gitlab not support the model? having builds done in parallel
on runners closer to the test runners seems like it should be a thing.
I guess artifact transfer would cost less then as a result.

> The reason we hadn't worked everything out in advance of deploying is
> because Mesa has had 3993 MRs in the not long over a year since
> moving, and a similar number in GStreamer, just taking the two biggest
> users. At the start it was 'maybe let's use MRs if you want to but
> make sure everything still goes through the list', and now it's
> something different. Similarly the CI architecture hasn't been
> 'designed', so much as that people want to run dEQP and Piglit on
> their hardware pre-merge in an open fashion that's actually accessible
> to people, and have just done it.
>
> Again, if you want everything to be centrally
> designed/approved/monitored/controlled, that's a fine enough idea, and
> I'd be happy to support whoever it was who was doing that for all of
> fd.o.

I don't think we have any choice but to have someone centrally
controlling it, You can't have a system in place that lets CI users
burn largs sums of money without authorisation, and that is what we
have now.

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

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Dave Airlie]

On Fri, 28 Feb 2020 at 07:27, Daniel Vetter  wrote:
>
> Hi all,
>
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
>
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially includes all the
> CI integration. Modern development process and tooling, yay!
>
> The bad news: The cost in growth has also been tremendous, and it's
> breaking our bank account. With reasonable estimates for continued
> growth we're expecting hosting expenses totalling 75k USD this year,
> and 90k USD next year. With the current sponsors we've set up we can't
> sustain that. We estimate that hosting expenses for gitlab.fd.o
> without any of the CI features enabled would total 30k USD, which is
> within X.org's ability to support through various sponsorships, mostly
> through XDC.
>
> Note that X.org does no longer sponsor any CI runners themselves,
> we've stopped that. The huge additional expenses are all just in
> storing and serving build artifacts and images to outside CI runners
> sponsored by various companies. A related topic is that with the
> growth in fd.o it's becoming infeasible to maintain it all on
> volunteer admin time. X.org is therefore also looking for admin
> sponsorship, at least medium term.
>
> Assuming that we want cash flow reserves for one year of gitlab.fd.o
> (without CI support) and a trimmed XDC and assuming no sponsor payment
> meanwhile, we'd have to cut CI services somewhere between May and June
> this year. The board is of course working on acquiring sponsors, but
> filling a shortfall of this magnitude is neither easy nor quick work,
> and we therefore decided to give an early warning as soon as possible.
> Any help in finding sponsors for fd.o is very much appreciated.

a) Ouch.

b) we probably need to take a large step back here.

Look at this from a sponsor POV, why would I give X.org/fd.o
sponsorship money that they are just giving straight to google to pay
for hosting credits? Google are profiting in some minor way from these
hosting credits being bought by us, and I assume we aren't getting any
sort of discounts here. Having google sponsor the credits costs google
substantially less than having any other company give us money to do
it.

If our current CI architecture is going to burn this amount of money a
year and we hadn't worked this out in advance of deploying it then I
suggest the system should be taken offline until we work out what a
sustainable system would look like within the budget we have, whether
that be never transferring containers and build artifacts from the
google network, just having local runner/build combos etc.

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

[Mesa-dev] size of LP_MAX_VBUF_SIZE

[Dave Airlie]

Hey,

Anyone know why LP_MAX_VBUF_SIZE is only 4K?

Tess submits > 100K verts to the draw pipeline, which start to split
them, due to the 4K size of the above it splits 50 vertices per vbuf,
however it then calls draw_reset_vertex_ids which iterates over all
100K vertices each time.

I might try fixing the reset, but I wondered why this was only sending
50 vertices at a time to the rasterizer.

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

Re: [Mesa-dev] Profile-guides optimizations

[Dave Airlie]

On Fri, 14 Feb 2020 at 08:22, Marek Olšák  wrote:
>
> I wonder what PGO really does other than placing likely/unlikely.

With LTO it can do a lot more, like grouping hot functions into closer
regions so they avoid TLB misses and faults etc.

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

Re: [Mesa-dev] CVE-2019-19520: Local privilege escalation via xlock

[Dave Airlie]

On Thu, 5 Dec 2019 at 13:42, Jonathan Gray  wrote:
>
> Until very recently OpenBSD built xlockmore against Mesa.  xlock is
> setgid auth.  As described by Qualys in their advisory
> https://marc.info/?l=oss-security&m=157549260013521&w=2
> "CVE-2019-19520: Local privilege escalation via xlock"
> the setuid check in the loader for LIBGL_DRIVERS_PATH does not handle
> this.
>
Should we just use secure_getenv?

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

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Dave Airlie]

On Wed, 4 Dec 2019 at 10:39, Marek Olšák  wrote:
>
> Hi,
>
> Here are 2 proposals to simplify and better optimize the GL->Gallium 
> translation.
>
> 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> Classic drivers won't share any code with master. glvnd will load them, but 
> glvnd is not ready for this yet.
>
> 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, 
> mesa/vbo, mesa/program, and drivers/dri/common need to be forked and 
> mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target 
> location.
>
> Option 2 is more acceptable to people who want to keep classic drivers in the 
> tree and it can be done right now.

These both seem pretty horrible to me right now. Like i965 still
supports a lot of hardware that exists right now even if we move to
iris.

I sorta feel there should be a
3) make life harder for classic drivers and optimise things more for
gallium add more dd.h entrypoints, force the classic drivers to jump
through hoops to degallium.

I don't like forking src/mesa/main/* because really 99% of it is just
a GL frontend implementation, most bugs in it will be in a fork and
vice-versa, I'd rather refine the abstraction between mesa and
backends if possible to reduce the overheads.

I'm probably not convinced that any benefit is worth accepting 1 or 2
above, but hey I've been persuaded before to do crazy things.

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

Re: [Mesa-dev] r600

[Dave Airlie]

On Wed, 27 Nov 2019 at 21:08, Gert Wollny  wrote:
>
> Hello Dave,
>
> I was wondering how much interest you still have in R600? I'm preparing
> to start feeding my NIR work as MRs to continue my work in-tree. It is
> currently only for Evergreen and still far from feature parity
> with TGSI (no tesselation, no images, nor SSBOs), some things regress,
> but some things are also fixed, so obviously the backend will only be
> enabled on explicit request.
>
> Before that I'd like to un-tabbify the whole r600 driver code, because
> all the other parts of mesa I've been touching use spaces, and it makes
> it more convenient to have the same WS handling everywhere.
>
> Whould this be okay with you?

I'm not against it from a style point of view, but from a it totally
breaks git history, blame, cherry-picking and many other useful things
I'd really ask you to reconsider and just use editorconfig. Maybe r600
is quiet enough now we don't have to worry about that much backports
or cherry-pick, so I'll leave it up to you.

At least leave sb alone since we probably want to kill that someday if
your NIR backend gets there, and I doubt you want to touch it too much
either.

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

Re: [Mesa-dev] gl_nir_lower_samplers_as_deref vs drawpixels lowering

[Dave Airlie]

On Tue, 26 Nov 2019 at 05:19, Marek Olšák  wrote:
>
> The way shader variants work in st/mesa is that NIR is generated, finalized, 
> and stored in the cache. This helps the most common case when there is only 
> one variant. If shader variants make changes to NIR, like adding samplers, 
> uniforms, and inputs, it needs to be finalized again, which means many passes 
> have to be run again.
>

So this is what's happening, we are calling the gl_nir lowering pass
twice, once for the main shader, once for the variant, the call for
the variant messes up.

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

[Mesa-dev] gl_nir_lower_samplers_as_deref vs drawpixels lowering

[Dave Airlie]

I was asked to use some newer radeonsi code in my tgsi info gathering
wrapper for NIR. One of the things it does is use
nir->info.textures_used.

Now with the piglit test draw-pixel-with-texture there is a reentrancy
issue with the passes.

We create a shader and gl_nir_lower_samplers_as_deref get called on
it, this sets nir->info.textures_used to 1, and it also lowers all
texture derefs in the shader.

The shader gets used in a variant later for drawpixels, the drawpixels
lowering then adds it's own "drawpix" sampler an accesses it with
derefs. Then gl_nir_lower_samplers_as_deref gets called again for the
whole shader in finalisation, but this time the first set of derefs
have already been lowered so it only lowers the new drawpix ones, and
sets nir->info.textures_used to 2 (it's a bitfield), it should be 3.

Are the other drivers seeing this? any ideas on what needs to be
fixed, the nir sampler lowering could I suppose record
nir->info.textures_used for non-deref textures as well.

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

Re: [Mesa-dev] [PATCH] gallivm: Fix saturated signed psub/padd intrinsics on llvm 8

[Dave Airlie]

>
> From: Roland Scheidegger 

Thanks,

Reviewed-by: Dave Airlie 

>
> LLVM 8 did remove both the signed and unsigned sse2/avx intrinsics in
> the end, and provide arch-independent llvm intrinsics instead.
> Fixes a crash when using snorm framebuffers (tested with piglit
> arb_color_buffer_float-render GL_RGBA8_SNORM -auto).
>
> CC: 
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_arit.c | 28 -
>  1 file changed, 10 insertions(+), 18 deletions(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c 
> b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> index 6b7ce9aacf9..53ee00e6767 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> @@ -465,7 +465,7 @@ lp_build_add(struct lp_build_context *bld,
>  return bld->one;
>
>if (!type.floating && !type.fixed) {
> - if (LLVM_VERSION_MAJOR >= 9) {
> + if (LLVM_VERSION_MAJOR >= 8) {
>  char intrin[32];
>  intrinsic = type.sign ? "llvm.sadd.sat" : "llvm.uadd.sat";
>  lp_format_intrinsic(intrin, sizeof intrin, intrinsic, 
> bld->vec_type);
> @@ -474,11 +474,9 @@ lp_build_add(struct lp_build_context *bld,
>   if (type.width * type.length == 128) {
>  if (util_cpu_caps.has_sse2) {
> if (type.width == 8)
> - intrinsic = type.sign ? "llvm.x86.sse2.padds.b" :
> - LLVM_VERSION_MAJOR < 8 ? 
> "llvm.x86.sse2.paddus.b" : NULL;
> + intrinsic = type.sign ? "llvm.x86.sse2.padds.b" : 
> "llvm.x86.sse2.paddus.b";
> if (type.width == 16)
> - intrinsic = type.sign ? "llvm.x86.sse2.padds.w" :
> - LLVM_VERSION_MAJOR < 8 ? 
> "llvm.x86.sse2.paddus.w" : NULL;
> + intrinsic = type.sign ? "llvm.x86.sse2.padds.w" : 
> "llvm.x86.sse2.paddus.w";
>  } else if (util_cpu_caps.has_altivec) {
> if (type.width == 8)
>intrinsic = type.sign ? "llvm.ppc.altivec.vaddsbs" : 
> "llvm.ppc.altivec.vaddubs";
> @@ -489,11 +487,9 @@ lp_build_add(struct lp_build_context *bld,
>   if (type.width * type.length == 256) {
>  if (util_cpu_caps.has_avx2) {
> if (type.width == 8)
> -  intrinsic = type.sign ? "llvm.x86.avx2.padds.b" :
> -  LLVM_VERSION_MAJOR < 8 ? 
> "llvm.x86.avx2.paddus.b" : NULL;
> +  intrinsic = type.sign ? "llvm.x86.avx2.padds.b" : 
> "llvm.x86.avx2.paddus.b";
> if (type.width == 16)
> -  intrinsic = type.sign ? "llvm.x86.avx2.padds.w" :
> -  LLVM_VERSION_MAJOR < 8 ? 
> "llvm.x86.avx2.paddus.w" : NULL;
> +  intrinsic = type.sign ? "llvm.x86.avx2.padds.w" : 
> "llvm.x86.avx2.paddus.w";
>  }
>   }
>}
> @@ -793,7 +789,7 @@ lp_build_sub(struct lp_build_context *bld,
>  return bld->zero;
>
>if (!type.floating && !type.fixed) {
> - if (LLVM_VERSION_MAJOR >= 9) {
> + if (LLVM_VERSION_MAJOR >= 8) {
>  char intrin[32];
>  intrinsic = type.sign ? "llvm.ssub.sat" : "llvm.usub.sat";
>  lp_format_intrinsic(intrin, sizeof intrin, intrinsic, 
> bld->vec_type);
> @@ -802,11 +798,9 @@ lp_build_sub(struct lp_build_context *bld,
>   if (type.width * type.length == 128) {
>  if (util_cpu_caps.has_sse2) {
> if (type.width == 8)
> -  intrinsic = type.sign ? "llvm.x86.sse2.psubs.b" :
> -  LLVM_VERSION_MAJOR < 8 ? 
> "llvm.x86.sse2.psubus.b" : NULL;
> +  intrinsic = type.sign ? "llvm.x86.sse2.psubs.b" : 
> "llvm.x86.sse2.psubus.b";
> if (type.width == 16)
> -  intrinsic = type.sign ? "llvm.x86.sse2.psubs.w" :
> -  LLVM_VERSION_MAJOR < 8 ? 
> "llvm.x86.sse2.psubus.w" : NULL;
> +  intrinsic = type.sign ? "llvm.x86.sse2.psubs.w" : 
> "llvm.x86.sse2.psubus.w";
>  } else if (util_cpu_caps.has_altivec) {
> if (type.width == 8)
>intrinsic = type.sign ? "ll

Re: [Mesa-dev] [PATCH] gallivm: use fallback code for mul_hi with llvm >= 7.0

[Dave Airlie]

On Fri, 30 Aug 2019 at 00:55, Roland Scheidegger  wrote:
>
> Am 29.08.19 um 15:05 schrieb Jose Fonseca:
> > This change is
> >
> >   Reviewed-by: Jose Fonseca 
> >
> > Regarding follow up change, do you think the LLVM pattern is sane/doable?
> Yes, should be doable and not too bad (I did not verify that what we're
> doing doesn't actually get recognized, since it's theoretically possible
> some other lowering could produce the pattern, although it seems unlikely).
> I think though this code isn't hit a lot - it was once used by draw,
> which is why I noticed the suboptimal code generated and added the
> optimized version, but nowadays it's just for mulhi, so should be fairly
> rare in practice.
>
>
> >
> > If not we should try ask them to reconsider relying strictly upon
> > pattern matching.  I get the feeling upstream LLVM is throwing the baby
> > with the water with these changes.  I do understand the advantages of
> > moving away from vendor specific intrinsics, but I think that for things
> > which have no natural representation on LLVM base IR, they should add a
> > vendor-agnostic intrinsic, for example a new "/llvm.mulhi.*"  set of
> > instrinsics/, as narrow pattern matching is bound to produce performance
> > cliffs nobody will notice.
> They did add new generic intrinsics for some things, but not this one
> indeed.
> I'm not exactly a big fan of this pattern matching in favor of
> intrinsics neither, at least if the patterns are non-trivial...

Btw In working on something else, I found the padd and psub intrinsic
paths seem to fail at least on LLVM 8.

I don't have an example test to show though.

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

Re: [Mesa-dev] libdrm versioning - switch to 19.0.0?

[Dave Airlie]

On Fri, 11 Oct 2019 at 14:56, Rob Clark  wrote:
>
> On Thu, Oct 10, 2019 at 7:46 PM Jason Ekstrand  wrote:
> >
> > On October 10, 2019 15:15:29 Marek Olšák  wrote:
> >>
> >> Hi,
> >>
> >> I expect to make a new libdrm release soon. Any objections to changing the 
> >> versioning scheme?
> >>
> >> Current: 2.4.n
> >> n = starts from 0, incremented per release
> >>
> >> New proposals:
> >> year.n.0 (19.0.0)
> >
> >
> >
> > Following the Mesa convention seems reasonable.
> >
>
> can't we get to 2.4.999?
>
> j/k, I also agree that following mesa convention seems reasonable
>
> BR,
> -R

Are we talking package version and library version or just package?

Changing the library version major would be a larger undertaking, we
probably should have been changing the minor for ages.

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

Re: [Mesa-dev] [PATCH] llvmpipe: fix CALLOC vs. free mismatches

[Dave Airlie]

On Fri, 6 Sep 2019 at 12:13,  wrote:
>
> From: Roland Scheidegger 
>
> Should fix some issues we're seeing. And use REALLOC instead of realloc.

Oops sorry

Reviewed-by: Dave Airlie 
> ---
>  src/gallium/drivers/llvmpipe/lp_cs_tpool.c | 6 +++---
>  src/gallium/drivers/llvmpipe/lp_state_cs.c | 3 ++-
>  2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_cs_tpool.c 
> b/src/gallium/drivers/llvmpipe/lp_cs_tpool.c
> index 04495727e1c..6f1b4e2ee55 100644
> --- a/src/gallium/drivers/llvmpipe/lp_cs_tpool.c
> +++ b/src/gallium/drivers/llvmpipe/lp_cs_tpool.c
> @@ -65,7 +65,7 @@ lp_cs_tpool_worker(void *data)
>   cnd_broadcast(&task->finish);
> }
> mtx_unlock(&pool->m);
> -   free(lmem.local_mem_ptr);
> +   FREE(lmem.local_mem_ptr);
> return 0;
>  }
>
> @@ -105,7 +105,7 @@ lp_cs_tpool_destroy(struct lp_cs_tpool *pool)
>
> cnd_destroy(&pool->new_work);
> mtx_destroy(&pool->m);
> -   free(pool);
> +   FREE(pool);
>  }
>
>  struct lp_cs_tpool_task *
> @@ -148,6 +148,6 @@ lp_cs_tpool_wait_for_task(struct lp_cs_tpool *pool,
> mtx_unlock(&pool->m);
>
> cnd_destroy(&task->finish);
> -   free(task);
> +   FREE(task);
> *task_handle = NULL;
>  }
> diff --git a/src/gallium/drivers/llvmpipe/lp_state_cs.c 
> b/src/gallium/drivers/llvmpipe/lp_state_cs.c
> index 1645a185cb2..a26cbf4df22 100644
> --- a/src/gallium/drivers/llvmpipe/lp_state_cs.c
> +++ b/src/gallium/drivers/llvmpipe/lp_state_cs.c
> @@ -1123,8 +1123,9 @@ cs_exec_fn(void *init_data, int iter_idx, struct 
> lp_cs_local_mem *lmem)
> memset(&thread_data, 0, sizeof(thread_data));
>
> if (lmem->local_size < job_info->req_local_mem) {
> +  lmem->local_mem_ptr = REALLOC(lmem->local_mem_ptr, lmem->local_size,
> +job_info->req_local_mem);
>lmem->local_size = job_info->req_local_mem;
> -  lmem->local_mem_ptr = realloc(lmem->local_mem_ptr, lmem->local_size);
> }
> thread_data.shared = lmem->local_mem_ptr;
>
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallivm: disable accurate cube corner for integer textures.

[Dave Airlie]

From: Dave Airlie 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111511
---
 src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c 
b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
index adb6adf143a..69dba78ac8a 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
@@ -1039,6 +1039,10 @@ lp_build_sample_image_linear(struct 
lp_build_sample_context *bld,
 
accurate_cube_corners = ACCURATE_CUBE_CORNERS && seamless_cube_filter;
 
+   /* disable accurate cube corners for integer textures. */
+   if (is_gather && 
util_format_is_pure_integer(bld->static_texture_state->format))
+  accurate_cube_corners = FALSE;
+
lp_build_extract_image_sizes(bld,
 &bld->int_size_bld,
 bld->int_coord_type,
-- 
2.21.0

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

Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration

[Dave Airlie]

On Tue, 27 Aug 2019 at 20:30, Jose Fonseca  wrote:
>
> FYI, I've followed Eric Engestroms' instructions for better Mesa <-> AppVeyor 
> integration.  (Thanks Eric.)
>
> I haven't tested, but hopefully this new integration method should now 
> trigger Appveyor builds on pull requests too, which should come handy.
>
> I'm still keeping the old webhook method integration around (with a different 
> name.)  So the list might receive duplicate notifications.  I'll disable this 
> when we're satisfied the new method works well.
>
> For the record, these Appveyor runs are running on a separate Appveyor 
> account dedicated for Mesa and FDO projects like Piglit, and not my personal 
> Appveyor account.

It appears all the results are going to mesa-dev, is there a way to
send them to the same ppl that would get them from gitlab?

I push to some of my PRs quite a lot (esp when llvm version wrangling).

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

Re: [Mesa-dev] [PATCH] gallivm: use fallback code for mul_hi with llvm >= 7.0

[Dave Airlie]

Reviewed-by: Dave Airlie 

On Thu, 29 Aug 2019 at 05:37,  wrote:
>
> From: Roland Scheidegger 
>
> LLVM 7.0 ditched the pmulu intrinsics.
> This is only a trivial patch to use the fallback code instead.
> It'll likely produce atrocious code since the pattern doesn't match what
> llvm itself uses in its autoupgrade paths, hence the pattern won't be
> recognized.
>
> Should fix https://bugs.freedesktop.org/show_bug.cgi?id=111496
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_arit.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c 
> b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> index c4931c0b230..f1866c6625f 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> @@ -1169,8 +1169,13 @@ lp_build_mul_32_lohi_cpu(struct lp_build_context *bld,
>  * https://llvm.org/bugs/show_bug.cgi?id=30845
>  * So, whip up our own code, albeit only for length 4 and 8 (which
>  * should be good enough)...
> +* FIXME: For llvm >= 7.0 we should match the autoupgrade pattern
> +* (bitcast/and/mul/shuffle for unsigned, bitcast/shl/ashr/mul/shuffle
> +* for signed), which the fallback code does not, without this llvm
> +* will likely still produce atrocious code.
>  */
> -   if ((bld->type.length == 4 || bld->type.length == 8) &&
> +   if (HAVE_LLVM < 0x0700 &&
> +   (bld->type.length == 4 || bld->type.length == 8) &&
> ((util_cpu_caps.has_sse2 && (bld->type.sign == 0)) ||
>  util_cpu_caps.has_sse4_1)) {
>const char *intrinsic = NULL;
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Difference between TransformFeedback Gallium <-> Vulkan (V3D)

[Dave Airlie]

On Tue, 27 Aug 2019 at 09:03, Andreas Bergmeier  wrote:
>
> > Be warned that the way the Intel streamout hardware works is really weird.  
> > It's designed from the perspective of something walking a buffer and trying 
> > to figure out which outputs to grab.  This is completely backwards (or 
> > inside-out, whichever is weirder) from the API which is written from the 
> > perspective of a shader shoving data into a buffer.  If you're looking at 
> > the ANV code, it's really easy to get turned around.
>
> Thanks. Currently I am trying to orient on Intel, since it
> a, seems the closest non-capability wise and
> b, if push comes to shove, I might be able to compile a new libvulkanintel.so 
> and start tracing with that
>
> What do you think would be the better reference? RADV?

One thing to remember is you don't need XFB for a conformant vulkan
driver, the extension isn't even an official one. It's probably the
last place to start :-)

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

[Mesa-dev] [PATCH] gallivm: fix atomic compare-and-swap

[Dave Airlie]

From: Dave Airlie 

Not sure how I missed this before, but compswap was hitting an
assert here as it is it's own special case.

Fixes: b5ac381d8f ("gallivm: add buffer operations to the tgsi->llvm 
conversion.")
---
 src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c 
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 31f6f082acc..7c747f38e7a 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -3585,6 +3585,8 @@ atomic_emit(
case TGSI_OPCODE_ATOMIMAX:
   op = LLVMAtomicRMWBinOpMax;
   break;
+   case TGSI_OPCODE_ATOMCAS:
+  break;
default:
   assert(0);
   return;
-- 
2.21.0

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

Re: [Mesa-dev] [PATCH] gallivm: fix a missing argument to CreateAtomicCmpXchg

[Dave Airlie]

On Fri, 2 Aug 2019 at 13:08, Brian Paul  wrote:
>
> On 08/01/2019 04:56 PM, Charmaine Lee wrote:
> > This patch fixes a missing argument to CreateAtomicCmpXchg for older
> > version of LLVM.

Does this pass CI? please try a pull request.

We've got a bug open
https://bugs.freedesktop.org/show_bug.cgi?id=02 but nobody has
worked out why CI builds fine against 3.4 etc.

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

[Mesa-dev] [PATCH] nir: use common deref has indirect code in scratch lowering.

[Dave Airlie]

From: Dave Airlie 

This doesn't seem to need it's own copy here.
---
 src/compiler/nir/nir_lower_scratch.c | 16 +---
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/src/compiler/nir/nir_lower_scratch.c 
b/src/compiler/nir/nir_lower_scratch.c
index df0d3f43124..aacc2ddca08 100644
--- a/src/compiler/nir/nir_lower_scratch.c
+++ b/src/compiler/nir/nir_lower_scratch.c
@@ -34,20 +34,6 @@
 #include "nir_builder.h"
 #include "nir_deref.h"
 
-static bool
-deref_has_indirect(nir_deref_instr *deref)
-{
-   while (deref->deref_type != nir_deref_type_var) {
-  if (deref->deref_type == nir_deref_type_array &&
-  nir_src_as_const_value(deref->arr.index) == NULL)
- return true;
-
-  deref = nir_deref_instr_parent(deref);
-   }
-
-   return false;
-}
-
 static void
 lower_load_store(nir_builder *b,
  nir_intrinsic_instr *intrin,
@@ -128,7 +114,7 @@ nir_lower_vars_to_scratch(nir_shader *shader,
 if (!(deref->mode & modes))
continue;
 
-if (!deref_has_indirect(nir_src_as_deref(intrin->src[0])))
+if 
(!nir_deref_instr_has_indirect(nir_src_as_deref(intrin->src[0])))
continue;
 
 nir_variable *var = nir_deref_instr_get_variable(deref);
-- 
2.21.0

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

Re: [Mesa-dev] How to build mesa to run vulkan application on Intel HD graphics?

[Dave Airlie]

On Wed, 24 Jul 2019 at 11:55, Xu, Xing  wrote:
>
> Hi, I tried to add some logs as below in file 
> ./src/vulkan/wsi/wsi_common_x11.c (x11_queue_present):
>
> printf("%s,%d\n",__FUNCTION__,__LINE__);
>
> assert(0);
>
> but got nothing(no logs and assert didn’t happen) when I run my application.
>
>
>
> Here is how I build run my applications:
>
> 1), Build install
>
> meson configure builddir -Dvulkan-drivers=intel
>
> ninja -C builddir/
>
> meson configure builddir -Dprefix=/tmp/install
>
> sudo ninja -C builddir/ install
>
>
>
> 2), Run
>
> export LD_LIBRARY_PATH=/tmp/install/lib/x86_64-linux-gnu/:$LD_LIBRARY_PATH
>
> export LIBGL_DRIVERS_PATH=/tmp/install/lib/x86_64-linux-gnu/dri
>
> ./angle_end2end_tests

For vulkan you have to set VK_ICD_FILENAMES and point at the
/tmp/install/share/vulkan/icd.d/intel_icd.x86_64.json

use vulkaninfo to debug.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radv: put back VGT_FLUSH at ring init on gfx10

[Dave Airlie]

From: Dave Airlie 

I can find no evidence that removing this is a good idea.

Fixes: 9b116173b6a ("radv: do not emit VGT_FLUSH on GFX10")
---
 src/amd/vulkan/radv_device.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index b397a9a8aa0..8dd24cb8192 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -2753,10 +2753,8 @@ radv_get_preamble_cs(struct radv_queue *queue,
radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
radeon_emit(cs, EVENT_TYPE(V_028A90_VS_PARTIAL_FLUSH) | 
EVENT_INDEX(4));
 
-   if (queue->device->physical_device->rad_info.chip_class 
< GFX10) {
-   radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
-   radeon_emit(cs, EVENT_TYPE(V_028A90_VGT_FLUSH) 
| EVENT_INDEX(0));
-   }
+   radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
+   radeon_emit(cs, EVENT_TYPE(V_028A90_VGT_FLUSH) | 
EVENT_INDEX(0));
}
 
radv_emit_gs_ring_sizes(queue, cs, esgs_ring_bo, esgs_ring_size,
-- 
2.21.0

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

[Mesa-dev] [PATCH] radv: reset the window scissor with no clear state.

[Dave Airlie]

From: Dave Airlie 

IF we don't have clear state (which gfx10 doesn't currently)
we will fix to reset the scissor. AMDVLK will leave it set
to something else.

Marek also has this fix for radeonsi pending.
---
 src/amd/vulkan/si_cmd_buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index 6fe447ef2e9..0efa169d674 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -202,7 +202,7 @@ si_emit_graphics(struct radv_physical_device 
*physical_device,
/* CLEAR_STATE doesn't clear these correctly on certain generations.
 * I don't know why. Deduced by trial and error.
 */
-   if (physical_device->rad_info.chip_class <= GFX7) {
+   if (physical_device->rad_info.chip_class <= GFX7 || 
!physical_device->has_clear_state) {
radeon_set_context_reg(cs, 
R_028B28_VGT_STRMOUT_DRAW_OPAQUE_OFFSET, 0);
radeon_set_context_reg(cs, R_028204_PA_SC_WINDOW_SCISSOR_TL,
   S_028204_WINDOW_OFFSET_DISABLE(1));
-- 
2.21.0

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

[Mesa-dev] [PATCH] radv: fix crash in shader tracing.

[Dave Airlie]

From: Dave Airlie 

Enabling tracing, and then having a vmfault, can leads to a segfault
before we print out the traces, as if a meta shader is executing
and we don't have the NIR for it.

Just pass the stage and give back a default.

Fixes: 9b9ccee4d64 ("radv: take LDS into account for compute shader occupancy 
stats")
---
 src/amd/vulkan/radv_nir_to_llvm.c | 8 ++--
 src/amd/vulkan/radv_private.h | 1 +
 src/amd/vulkan/radv_shader.c  | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c
index 3e18303879e..c08789a4361 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -4244,9 +4244,10 @@ ac_setup_rings(struct radv_shader_context *ctx)
 
 unsigned
 radv_nir_get_max_workgroup_size(enum chip_class chip_class,
+   gl_shader_stage stage,
const struct nir_shader *nir)
 {
-   switch (nir->info.stage) {
+   switch (stage) {
case MESA_SHADER_TESS_CTRL:
return chip_class >= GFX7 ? 128 : 64;
case MESA_SHADER_GEOMETRY:
@@ -4257,6 +4258,8 @@ radv_nir_get_max_workgroup_size(enum chip_class 
chip_class,
return 0;
}
 
+   if (!nir)
+   return chip_class >= GFX9 ? 128 : 64;
unsigned max_workgroup_size = nir->info.cs.local_size[0] *
nir->info.cs.local_size[1] *
nir->info.cs.local_size[2];
@@ -4340,7 +4343,8 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct 
ac_llvm_compiler *ac_llvm,
for (int i = 0; i < shader_count; ++i) {
ctx.max_workgroup_size = MAX2(ctx.max_workgroup_size,
  
radv_nir_get_max_workgroup_size(ctx.options->chip_class,
-   
shaders[i]));
+ 
shaders[i]->info.stage,
+ 
shaders[i]));
}
 
if (ctx.ac.chip_class >= GFX10) {
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 931d4039397..f1f30887e01 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -2138,6 +2138,7 @@ void radv_compile_nir_shader(struct ac_llvm_compiler 
*ac_llvm,
 const struct radv_nir_compiler_options *options);
 
 unsigned radv_nir_get_max_workgroup_size(enum chip_class chip_class,
+gl_shader_stage stage,
 const struct nir_shader *nir);
 
 /* radv_shader_info.h */
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index bcc050a86cc..8f24a6d72b0 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -1232,7 +1232,7 @@ generate_shader_stats(struct radv_device *device,
 lds_increment);
} else if (stage == MESA_SHADER_COMPUTE) {
unsigned max_workgroup_size =
-   radv_nir_get_max_workgroup_size(chip_class, 
variant->nir);
+   radv_nir_get_max_workgroup_size(chip_class, stage, 
variant->nir);
lds_per_wave = (conf->lds_size * lds_increment) /
   DIV_ROUND_UP(max_workgroup_size, 64);
}
-- 
2.21.0

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

Re: [Mesa-dev] [PATCH] radv: Only save the descriptor set if we have one.

[Dave Airlie]

Reviewed-by: Dave Airlie 

On Wed, 17 Jul 2019 at 11:01, Bas Nieuwenhuizen  
wrote:
>
> After reset, if valid does not contain the relevant bit the descriptor
> can be != NULL but still not be valid.
>
> CC: 
> ---
>  src/amd/vulkan/radv_meta.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_meta.c b/src/amd/vulkan/radv_meta.c
> index 5e619c2f181..448a6168bd2 100644
> --- a/src/amd/vulkan/radv_meta.c
> +++ b/src/amd/vulkan/radv_meta.c
> @@ -86,7 +86,7 @@ radv_meta_save(struct radv_meta_saved_state *state,
>
> if (state->flags & RADV_META_SAVE_DESCRIPTORS) {
> state->old_descriptor_set0 = descriptors_state->sets[0];
> -   if (!state->old_descriptor_set0)
> +   if (!(descriptors_state->valid & 1) || 
> !state->old_descriptor_set0)
> state->flags &= ~RADV_META_SAVE_DESCRIPTORS;
> }
>
> --
> 2.21.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radv: use correct register setter for ngg hw addr

[Dave Airlie]

From: Dave Airlie 

this shouldn't matter, but it's good to be correct.
---
 src/amd/vulkan/radv_pipeline.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 5cdfe6d24eb..c7660c2900c 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -3408,7 +3408,7 @@ radv_pipeline_generate_hw_ngg(struct radeon_cmdbuf 
*ctx_cs,
 
radeon_set_sh_reg_seq(cs, R_00B320_SPI_SHADER_PGM_LO_ES, 2);
radeon_emit(cs, va >> 8);
-   radeon_emit(cs, va >> 40);
+   radeon_emit(cs, S_00B324_MEM_BASE(va >> 40));
radeon_set_sh_reg_seq(cs, R_00B228_SPI_SHADER_PGM_RSRC1_GS, 2);
radeon_emit(cs, shader->config.rsrc1);
radeon_emit(cs, shader->config.rsrc2);
-- 
2.21.0

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

[Mesa-dev] [PATCH] radv/gfx10: set the pgm rsrc3/4 regs using index sh reg set

[Dave Airlie]

From: Dave Airlie 

This is ported from AMDVLK, it's probably not requires unless
we want to use "real time queues", but it might be nice to just have
in place.
---
 src/amd/common/sid.h   |  1 +
 src/amd/vulkan/radv_cs.h   | 18 +++
 src/amd/vulkan/si_cmd_buffer.c | 42 +++---
 3 files changed, 42 insertions(+), 19 deletions(-)

diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h
index d464b6a110e..0b996e54884 100644
--- a/src/amd/common/sid.h
+++ b/src/amd/common/sid.h
@@ -196,6 +196,7 @@
 #define PKT3_INCREMENT_CE_COUNTER  0x84
 #define PKT3_INCREMENT_DE_COUNTER  0x85
 #define PKT3_WAIT_ON_CE_COUNTER0x86
+#define PKT3_SET_SH_REG_INDEX  0x9B
 #define PKT3_LOAD_CONTEXT_REG  0x9F /* new for VI */
 
 #define PKT_TYPE_S(x)   (((unsigned)(x) & 0x3) << 30)
diff --git a/src/amd/vulkan/radv_cs.h b/src/amd/vulkan/radv_cs.h
index eb1aedb0327..d21acba7e8e 100644
--- a/src/amd/vulkan/radv_cs.h
+++ b/src/amd/vulkan/radv_cs.h
@@ -97,6 +97,24 @@ static inline void radeon_set_sh_reg(struct radeon_cmdbuf 
*cs, unsigned reg, uns
radeon_emit(cs, value);
 }
 
+static inline void radeon_set_sh_reg_idx(const struct radv_physical_device 
*pdevice,
+struct radeon_cmdbuf *cs,
+unsigned reg, unsigned idx,
+unsigned value)
+{
+   assert(reg >= SI_SH_REG_OFFSET && reg < SI_SH_REG_END);
+   assert(cs->cdw + 3 <= cs->max_dw);
+   assert(idx);
+
+   unsigned opcode = PKT3_SET_SH_REG_INDEX;
+   if (pdevice->rad_info.chip_class < GFX10)
+   opcode = PKT3_SET_SH_REG;
+
+   radeon_emit(cs, PKT3(opcode, 1, 0));
+   radeon_emit(cs, (reg - SI_SH_REG_OFFSET) >> 2 | (idx << 28));
+   radeon_emit(cs, value);
+}
+
 static inline void radeon_set_uconfig_reg_seq(struct radeon_cmdbuf *cs, 
unsigned reg, unsigned num)
 {
assert(reg >= CIK_UCONFIG_REG_OFFSET && reg < CIK_UCONFIG_REG_END);
diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index a832dbd89eb..f789cdd1ce6 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -262,20 +262,24 @@ si_emit_graphics(struct radv_physical_device 
*physical_device,
if (physical_device->rad_info.chip_class >= GFX7) {
if (physical_device->rad_info.chip_class >= GFX10) {
/* Logical CUs 16 - 31 */
-   radeon_set_sh_reg(cs, R_00B404_SPI_SHADER_PGM_RSRC4_HS,
- S_00B404_CU_EN(0x));
-   radeon_set_sh_reg(cs, R_00B204_SPI_SHADER_PGM_RSRC4_GS,
- S_00B204_CU_EN(0x) |
- 
S_00B204_SPI_SHADER_LATE_ALLOC_GS_GFX10(0));
-   radeon_set_sh_reg(cs, R_00B104_SPI_SHADER_PGM_RSRC4_VS,
- S_00B104_CU_EN(0x));
-   radeon_set_sh_reg(cs, R_00B004_SPI_SHADER_PGM_RSRC4_PS,
- S_00B004_CU_EN(0x));
+   radeon_set_sh_reg_idx(physical_device,
+ cs, 
R_00B404_SPI_SHADER_PGM_RSRC4_HS,
+ 3, S_00B404_CU_EN(0x));
+   radeon_set_sh_reg_idx(physical_device,
+ cs, 
R_00B204_SPI_SHADER_PGM_RSRC4_GS,
+ 3, S_00B204_CU_EN(0x) |
+ 
S_00B204_SPI_SHADER_LATE_ALLOC_GS_GFX10(0));
+   radeon_set_sh_reg_idx(physical_device,
+ cs, 
R_00B104_SPI_SHADER_PGM_RSRC4_VS,
+ 3, S_00B104_CU_EN(0x));
+   radeon_set_sh_reg_idx(physical_device,
+ cs, 
R_00B004_SPI_SHADER_PGM_RSRC4_PS,
+ 3, S_00B004_CU_EN(0x));
}
 
if (physical_device->rad_info.chip_class >= GFX9) {
-   radeon_set_sh_reg(cs, R_00B41C_SPI_SHADER_PGM_RSRC3_HS,
- S_00B41C_CU_EN(0x) | 
S_00B41C_WAVE_LIMIT(0x3F));
+   radeon_set_sh_reg_idx(physical_device, cs, 
R_00B41C_SPI_SHADER_PGM_RSRC3_HS,
+ 3, S_00B41C_CU_EN(0x) | 
S_00B41C_WAVE_LIMIT(0x3F));
} else {
radeon_set_sh_reg(cs, R_00B51C_SPI_SHADER_PGM_RSRC3_LS,
  S_00B51C_CU_EN(0x) | 
S_00B51C_WAV

[Mesa-dev] [PATCH] radv/gfx10: don't set array pitch field on images

[Dave Airlie]

From: Dave Airlie 

Setting this seems to be broken, amdvlk only sets it for quilted
textures which I'm not sure what those are.

Fixes: dEQP-VK.glsl.texture_functions.query.texturesize*3d*
---
 src/amd/vulkan/radv_image.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index ccbec36849e..66a948fde4a 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -682,7 +682,7 @@ gfx10_make_texture_descriptor(struct radv_device *device,
 */
state[4] = S_00A010_DEPTH(type == V_008F1C_SQ_RSRC_IMG_3D ? depth - 1 : 
last_layer) |
   S_00A010_BASE_ARRAY(first_layer);
-   state[5] = S_00A014_ARRAY_PITCH(!!(type == V_008F1C_SQ_RSRC_IMG_3D)) |
+   state[5] = S_00A014_ARRAY_PITCH(0) |
   S_00A014_MAX_MIP(image->info.samples > 1 ?
util_logbase2(image->info.samples) :
image->info.levels - 1) |
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH] radv/gfx10: update OVERWRITE_COMBINER_{MRT_SHARING, WATERMARK}

[Dave Airlie]

r-b.

On Thu, 11 Jul 2019 at 23:51, Samuel Pitoiset  wrote:
>
> DCC related, mirror RadeonSI.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 20 
>  1 file changed, 4 insertions(+), 16 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index b7ee0ff6422..a2a4cb0adb2 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -1856,7 +1856,6 @@ radv_emit_framebuffer_state(struct radv_cmd_buffer 
> *cmd_buffer)
> int i;
> struct radv_framebuffer *framebuffer = cmd_buffer->state.framebuffer;
> const struct radv_subpass *subpass = cmd_buffer->state.subpass;
> -   unsigned num_bpp64_colorbufs = 0;
>
> /* this may happen for inherited secondary recording */
> if (!framebuffer)
> @@ -1872,7 +1871,6 @@ radv_emit_framebuffer_state(struct radv_cmd_buffer 
> *cmd_buffer)
> int idx = subpass->color_attachments[i].attachment;
> struct radv_attachment_info *att = 
> &framebuffer->attachments[idx];
> struct radv_image_view *iview = att->attachment;
> -   struct radv_image *image = iview->image;
> VkImageLayout layout = subpass->color_attachments[i].layout;
>
> radv_cs_add_buffer(cmd_buffer->device->ws, cmd_buffer->cs, 
> att->attachment->bo);
> @@ -1882,9 +1880,6 @@ radv_emit_framebuffer_state(struct radv_cmd_buffer 
> *cmd_buffer)
> radv_emit_fb_color_state(cmd_buffer, i, att, iview, layout);
>
> radv_load_color_clear_metadata(cmd_buffer, iview, i);
> -
> -   if (image->planes[0].surface.bpe >= 8)
> -   num_bpp64_colorbufs++;
> }
>
> if (subpass->depth_stencil_attachment) {
> @@ -1923,19 +1918,12 @@ radv_emit_framebuffer_state(struct radv_cmd_buffer 
> *cmd_buffer)
> if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX8) 
> {
> bool disable_constant_encode =
> 
> cmd_buffer->device->physical_device->has_dcc_constant_encode;
> -   uint8_t watermark = 4; /* Default value for GFX8. */
> -
> -   /* For optimal DCC performance. */
> -   if (cmd_buffer->device->physical_device->rad_info.chip_class 
> >= GFX9) {
> -   if (num_bpp64_colorbufs >= 5) {
> -   watermark = 8;
> -   } else {
> -   watermark = 6;
> -   }
> -   }
> +   enum chip_class chip_class =
> +   
> cmd_buffer->device->physical_device->rad_info.chip_class;
> +   uint8_t watermark = chip_class >= GFX10 ? 6 : 4;
>
> radeon_set_context_reg(cmd_buffer->cs, 
> R_028424_CB_DCC_CONTROL,
> -  
> S_028424_OVERWRITE_COMBINER_MRT_SHARING_DISABLE(1) |
> +  
> S_028424_OVERWRITE_COMBINER_MRT_SHARING_DISABLE(chip_class <= GFX9) |
>
> S_028424_OVERWRITE_COMBINER_WATERMARK(watermark) |
>
> S_028424_DISABLE_CONSTANT_ENCODE_REG(disable_constant_encode));
> }
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] llvmpipe: make remove_shader_variant static.

[Dave Airlie]

From: Dave Airlie 

this isn't used outside this file.
---
 src/gallium/drivers/llvmpipe/lp_state_fs.c | 2 +-
 src/gallium/drivers/llvmpipe/lp_state_fs.h | 4 
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_state_fs.c 
b/src/gallium/drivers/llvmpipe/lp_state_fs.c
index ab285bed1ca..b05997a3aab 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_fs.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_fs.c
@@ -3023,7 +3023,7 @@ llvmpipe_bind_fs_state(struct pipe_context *pipe, void 
*fs)
  * Remove shader variant from two lists: the shader's variant list
  * and the context's variant list.
  */
-void
+static void
 llvmpipe_remove_shader_variant(struct llvmpipe_context *lp,
struct lp_fragment_shader_variant *variant)
 {
diff --git a/src/gallium/drivers/llvmpipe/lp_state_fs.h 
b/src/gallium/drivers/llvmpipe/lp_state_fs.h
index 28eccde17f8..dc04df8bd94 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_fs.h
+++ b/src/gallium/drivers/llvmpipe/lp_state_fs.h
@@ -145,8 +145,4 @@ struct lp_fragment_shader
 void
 lp_debug_fs_variant(const struct lp_fragment_shader_variant *variant);
 
-void
-llvmpipe_remove_shader_variant(struct llvmpipe_context *lp,
-   struct lp_fragment_shader_variant *variant);
-
 #endif /* LP_STATE_FS_H_ */
-- 
2.21.0

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

[Mesa-dev] [PATCH] radeonsi: fix undefined shift in macro definition

[Dave Airlie]

From: Dave Airlie 

Pointed out by coverity
---
 src/gallium/drivers/radeonsi/si_perfcounter.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_perfcounter.c 
b/src/gallium/drivers/radeonsi/si_perfcounter.c
index ad7f1eb3d99..75bd61730da 100644
--- a/src/gallium/drivers/radeonsi/si_perfcounter.c
+++ b/src/gallium/drivers/radeonsi/si_perfcounter.c
@@ -126,7 +126,7 @@ static const unsigned si_pc_shader_type_bits[] = {
 /* Max counters per HW block */
 #define SI_QUERY_MAX_COUNTERS 16
 
-#define SI_PC_SHADERS_WINDOWING (1 << 31)
+#define SI_PC_SHADERS_WINDOWING (1u << 31)
 
 struct si_query_group {
struct si_query_group *next;
-- 
2.21.0

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

[Mesa-dev] [PATCH] nouveau: fix frees in unsupported IR error paths.

[Dave Airlie]

From: Dave Airlie 

This is pointless in that we won't ever hit those paths in real life,
but coverity complains.

Fixes: f014ae3c7cce ("nouveau: add support for nir")
---
 src/gallium/drivers/nouveau/nv50/nv50_program.c | 1 +
 src/gallium/drivers/nouveau/nv50/nv50_state.c   | 2 ++
 src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_state.c   | 2 ++
 4 files changed, 6 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.c 
b/src/gallium/drivers/nouveau/nv50/nv50_program.c
index 940fb9ce25c..a725aedcd8e 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_program.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_program.c
@@ -346,6 +346,7 @@ nv50_program_translate(struct nv50_program *prog, uint16_t 
chipset,
   break;
default:
   assert(!"unsupported IR!");
+  free(info);
   return false;
}
 
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_state.c 
b/src/gallium/drivers/nouveau/nv50/nv50_state.c
index 228feced5d1..89558ee442f 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_state.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_state.c
@@ -768,6 +768,7 @@ nv50_sp_state_create(struct pipe_context *pipe,
   break;
default:
   assert(!"unsupported IR!");
+  free(prog);
   return NULL;
}
 
@@ -864,6 +865,7 @@ nv50_cp_state_create(struct pipe_context *pipe,
   break;
default:
   assert(!"unsupported IR!");
+  free(prog);
   return NULL;
}
 
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
index c81d8952c98..1ff9f19f139 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
@@ -594,6 +594,7 @@ nvc0_program_translate(struct nvc0_program *prog, uint16_t 
chipset,
   break;
default:
   assert(!"unsupported IR!");
+  free(info);
   return false;
}
 
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
index 2ab51c8529e..7c0f605dc16 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
@@ -607,6 +607,7 @@ nvc0_sp_state_create(struct pipe_context *pipe,
   break;
default:
   assert(!"unsupported IR!");
+  free(prog);
   return NULL;
}
 
@@ -739,6 +740,7 @@ nvc0_cp_state_create(struct pipe_context *pipe,
   break;
default:
   assert(!"unsupported IR!");
+  free(prog);
   return NULL;
}
 
-- 
2.21.0

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

Re: [Mesa-dev] [PATCH v2 1/3] mapi: add static_date offset to MaxShaderCompilerThreadsKHR

[Dave Airlie]

Oops on new ext in master,

Reviewed-by: Dave Airlie  for the v2 series.

On Sat, 8 Jun 2019 at 01:47, Emil Velikov  wrote:
>
> From: Emil Velikov 
>
> As elaborated in the next patch, there is some hidden ABI that
> effectively require most entrypoints to be listed in the file.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110302
> Cc: Marek Olšák 
> Fixes: c5c38e831ee ("mesa: implement ARB/KHR_parallel_shader_compile")
> Signed-off-by: Emil Velikov 
> Reviewed-by: Dave Airlie 
> ---
> No changes since v1.
> ---
>  src/mapi/glapi/gen/static_data.py | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/mapi/glapi/gen/static_data.py 
> b/src/mapi/glapi/gen/static_data.py
> index bc49324348f..dc1926327da 100644
> --- a/src/mapi/glapi/gen/static_data.py
> +++ b/src/mapi/glapi/gen/static_data.py
> @@ -1453,6 +1453,7 @@ offsets = {
>  "TexParameterxv": 1417,
>  "BlendBarrier": 1418,
>  "PrimitiveBoundingBox": 1419,
> +"MaxShaderCompilerThreadsKHR": 1420,
>  }
>
>  functions = [
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] mapi: add static_date offset to MaxShaderCompilerThreadsKHR

[Dave Airlie]

Okay I talked to Emil last night about these, and while I'm not happy
with the situation we are in, replacing one job of the generator with
a new generator that does half the job, really doesn't get us
anywhere, I wished we'd blocked all of this earlier in favour of
replacing the generators wholesale so both sides were generated from
the same code. What we have now is inherently fragile, even if what we
had before might have been considered ugly.

I'm begrudingly giving a for both of these, just to unblock 19.1.

Reviewed-by: Dave Airlie 

Emil I think you should give serious consideration to unwinding all of
this in master, and trying again when you can wholesale replace the
generator from out XML with a generator from Khronos XML, generating
two different parts of the tree from different XML isn't a solution we
should ever have considered.

Dave

On Thu, 6 Jun 2019 at 02:24, Emil Velikov  wrote:
>
> From: Emil Velikov 
>
> As elaborated in the next patch, there is some hidden ABI that
> effectively require most entrypoints to be listed in the file.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110302
> Cc: Marek Olšák 
> Fixes: c5c38e831ee ("mesa: implement ARB/KHR_parallel_shader_compile")
> Signed-off-by: Emil Velikov 
> ---
>  src/mapi/glapi/gen/static_data.py | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/mapi/glapi/gen/static_data.py 
> b/src/mapi/glapi/gen/static_data.py
> index bc49324348f..dc1926327da 100644
> --- a/src/mapi/glapi/gen/static_data.py
> +++ b/src/mapi/glapi/gen/static_data.py
> @@ -1453,6 +1453,7 @@ offsets = {
>  "TexParameterxv": 1417,
>  "BlendBarrier": 1418,
>  "PrimitiveBoundingBox": 1419,
> +"MaxShaderCompilerThreadsKHR": 1420,
>  }
>
>  functions = [
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Error: unsupported relocations

[Dave Airlie]

On Mon, 3 Jun 2019 at 11:37, Jan Vesely  wrote:
>
> On Mon, 2019-06-03 at 11:12 +1000, Dave Airlie wrote:
> > On Mon, 3 Jun 2019 at 10:58, Jan Vesely  wrote:
> > > On Sun, 2019-06-02 at 20:09 -0400, James Harvey wrote:
> > > > I've started a thread on the llvm mailing list.  See
> > > > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2F2019-June%2F132750.html&data=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7Ce7c33507211c4512c6ad08d6e7c09d49%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636951211793224808&sdata=lyayMkDxUbTCye%2BynlBZ8sp%2Fc4u5kS4pv%2B2MMeSegoM%3D&reserved=0
> > > >
> > > > I don't know if it's needed, but if anyone has a commit in llvm that
> > > > started this, that might be helpful.
> > >
> > > thanks. however most LLVM developers contributing to AMDGPU backend
> > > are AMD folks. The ROCm based stack can handle relocations, so it's up
> > > to a volunteer to step up and post a patch (either for mesa or llvm).
> > > Fewer relocations should mean faster dispatch, so you they should be
> > > interested in taking the LLVM fix.
> > >
> > > I've started looking, but the elf structure lists relocations against
> > > a section (STT_SECTION), so I still don't know where to get target
> > > address.
> >
> > Jan,
> >
> > this is clearly inline not working, not relocs. We never get the
> > missing function to relocate it.
>
> The imagemagick issue might be missed inlining.
> I'm working on call* piglits, which mark functions as 'noinline' to
> force function calls.
> the code clearly expects relative function address:
> s_getpc_b64 s[8:9]
> s_add_u32 s8, s8, i64_func_void@rel32@lo+4
> s_addc_u32 s9, s9, i64_func_void@rel32@hi+4
> s_mov_b32 s32, s10
> s_swappc_b64 s[30:31], s[8:9]
> Inspecting the asm and symbol table, the callee functions are there.
> It might be that relocations issued for amdgcn-mesa-mesa3d triple are
> busted, I'd expect it to use single 4B relative pointer, but last time
> I talked to Matt he said it looked correct.

Okay so this doesn't appear to be that.
commit 5d567dc137d20a9d9654076fbdab8ceddb6748dc (HEAD, refs/bisect/new)
Author: Matt Arsenault 
Date:   Thu Feb 28 00:40:32 2019 +

AMDGPU: Enable function calls by default
LLVM 8 release fails to inline some functions, this commit in llvm 9
fixes that for some reason.

Which is totally the opposite of what i'd expect here.

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

Re: [Mesa-dev] Error: unsupported relocations

[Dave Airlie]

On Mon, 3 Jun 2019 at 10:42, Jan Vesely  wrote:
>
> On Mon, 2019-06-03 at 09:14 +1000, Dave Airlie wrote:
> > On Mon, 3 Jun 2019 at 09:13, Dave Airlie  wrote:
> > > On Sun, 2 Jun 2019 at 23:13, Jan Vesely  wrote:
> > > > On Sun, 2019-06-02 at 07:17 -0400, James Harvey wrote:
> > > > > On Sun, Jun 2, 2019 at 7:01 AM Bas Nieuwenhuizen
> > > > >  wrote:
> > > > > > On Sun, Jun 2, 2019 at 12:41 PM James Harvey 
> > > > > >  wrote:
> > > > > > > So, for people running amdgpu and wanting to run ImageMagick 
> > > > > > > convert
> > > > > > > who get this error... Does this mean there is something 
> > > > > > > ImageMagick
> > > > > > > could change to prevent the error?  Or, in the meantime, is the 
> > > > > > > only
> > > > > > > option to install the amdgpu-pro opencl userspace driver with
> > > > > > > ImageMagick?  (The pro opencl driver can be extracted from 
> > > > > > > amdgpu-pro
> > > > > > > as a whole, and ran on top of the free amdgpu driver., without the
> > > > > > > rest of amdgpu-pro installed - see Arch Linux AUR package 
> > > > > > > opencl-amd.)
> > > > > >
> > > > > > So, does imagemagick actually need OpenCL? If not, you can probably
> > > > > > also uninstall you mesa opencl distro package?
> > > > >
> > > > > The mesa opencl package works fine on other programs for me and
> > > > > others, so uninstalling isn't an option.  Not sure actually without
> > > > > any OpenCL if it does it a different way or not.  ImageMagick must be
> > > > > all that's trying to call something problematic.
> > > >
> > > > It's basically any function call that was not inlined. It might even
> > > > be in a different kernel in the same module.
> > > >
> > > > Recent mesa requires some kind of ICD loader to provide opencl. if
> > > > your distro uses ocl-icd package to provide ICD loader, you can use
> > > > OCL_ICD_VENDORS env var to select ICD drivers.
> > > >
> > > > something like 'OCD_ICD_VENDORS=/var/empty' (any directory other than
> > > > /etc/OpenCL/vendors will do) effectively disables OpenCL by reporting
> > > > 0 available platforms.
> > >
> > > It looks like an llvm8 not inlining everything properly bug.
> > >
> > > with llvm9 I just get a gpu hang when it does inline everything, but
> > > with 8 it fails to inline applyResizeFilter.
> > >
> > > llvm8 or some command line option passed to it might need a fix.
> >
> > Uggh changing the original CL C code in ImageMagic to static inline "fixes" 
> > it.
>
> sounds a bit like https://reviews.llvm.org/D62707. static inline
> function might be internalized/marked alwaysinline. CLOVER_DEBUG=llvm
> would tell more.
> I'm not sure why it'd produce GPU hangs. It might be a llvm-git bug,
> my daily testing only covers CL piglits.

I tried backporting this to llvm8, didn't seem to help, going to dig deeper.

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

Re: [Mesa-dev] Error: unsupported relocations

[Dave Airlie]

On Mon, 3 Jun 2019 at 10:58, Jan Vesely  wrote:
>
> On Sun, 2019-06-02 at 20:09 -0400, James Harvey wrote:
> > I've started a thread on the llvm mailing list.  See
> > http://lists.llvm.org/pipermail/llvm-dev/2019-June/132750.html
> >
> > I don't know if it's needed, but if anyone has a commit in llvm that
> > started this, that might be helpful.
>
> thanks. however most LLVM developers contributing to AMDGPU backend
> are AMD folks. The ROCm based stack can handle relocations, so it's up
> to a volunteer to step up and post a patch (either for mesa or llvm).
> Fewer relocations should mean faster dispatch, so you they should be
> interested in taking the LLVM fix.
>
> I've started looking, but the elf structure lists relocations against
> a section (STT_SECTION), so I still don't know where to get target
> address.

Jan,

this is clearly inline not working, not relocs. We never get the
missing function to relocate it.

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

Re: [Mesa-dev] Error: unsupported relocations

[Dave Airlie]

On Mon, 3 Jun 2019 at 09:13, Dave Airlie  wrote:
>
> On Sun, 2 Jun 2019 at 23:13, Jan Vesely  wrote:
> >
> > On Sun, 2019-06-02 at 07:17 -0400, James Harvey wrote:
> > > On Sun, Jun 2, 2019 at 7:01 AM Bas Nieuwenhuizen
> > >  wrote:
> > > > On Sun, Jun 2, 2019 at 12:41 PM James Harvey  
> > > > wrote:
> > > > > So, for people running amdgpu and wanting to run ImageMagick convert
> > > > > who get this error... Does this mean there is something ImageMagick
> > > > > could change to prevent the error?  Or, in the meantime, is the only
> > > > > option to install the amdgpu-pro opencl userspace driver with
> > > > > ImageMagick?  (The pro opencl driver can be extracted from amdgpu-pro
> > > > > as a whole, and ran on top of the free amdgpu driver., without the
> > > > > rest of amdgpu-pro installed - see Arch Linux AUR package opencl-amd.)
> > > >
> > > > So, does imagemagick actually need OpenCL? If not, you can probably
> > > > also uninstall you mesa opencl distro package?
> > >
> > > The mesa opencl package works fine on other programs for me and
> > > others, so uninstalling isn't an option.  Not sure actually without
> > > any OpenCL if it does it a different way or not.  ImageMagick must be
> > > all that's trying to call something problematic.
> >
> > It's basically any function call that was not inlined. It might even
> > be in a different kernel in the same module.
> >
> > Recent mesa requires some kind of ICD loader to provide opencl. if
> > your distro uses ocl-icd package to provide ICD loader, you can use
> > OCL_ICD_VENDORS env var to select ICD drivers.
> >
> > something like 'OCD_ICD_VENDORS=/var/empty' (any directory other than
> > /etc/OpenCL/vendors will do) effectively disables OpenCL by reporting
> > 0 available platforms.
>
> It looks like an llvm8 not inlining everything properly bug.
>
> with llvm9 I just get a gpu hang when it does inline everything, but
> with 8 it fails to inline applyResizeFilter.
>
> llvm8 or some command line option passed to it might need a fix.

Uggh changing the original CL C code in ImageMagic to static inline "fixes" it.

Dave.

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

Re: [Mesa-dev] Error: unsupported relocations

[Dave Airlie]

On Sun, 2 Jun 2019 at 23:13, Jan Vesely  wrote:
>
> On Sun, 2019-06-02 at 07:17 -0400, James Harvey wrote:
> > On Sun, Jun 2, 2019 at 7:01 AM Bas Nieuwenhuizen
> >  wrote:
> > > On Sun, Jun 2, 2019 at 12:41 PM James Harvey  
> > > wrote:
> > > > So, for people running amdgpu and wanting to run ImageMagick convert
> > > > who get this error... Does this mean there is something ImageMagick
> > > > could change to prevent the error?  Or, in the meantime, is the only
> > > > option to install the amdgpu-pro opencl userspace driver with
> > > > ImageMagick?  (The pro opencl driver can be extracted from amdgpu-pro
> > > > as a whole, and ran on top of the free amdgpu driver., without the
> > > > rest of amdgpu-pro installed - see Arch Linux AUR package opencl-amd.)
> > >
> > > So, does imagemagick actually need OpenCL? If not, you can probably
> > > also uninstall you mesa opencl distro package?
> >
> > The mesa opencl package works fine on other programs for me and
> > others, so uninstalling isn't an option.  Not sure actually without
> > any OpenCL if it does it a different way or not.  ImageMagick must be
> > all that's trying to call something problematic.
>
> It's basically any function call that was not inlined. It might even
> be in a different kernel in the same module.
>
> Recent mesa requires some kind of ICD loader to provide opencl. if
> your distro uses ocl-icd package to provide ICD loader, you can use
> OCL_ICD_VENDORS env var to select ICD drivers.
>
> something like 'OCD_ICD_VENDORS=/var/empty' (any directory other than
> /etc/OpenCL/vendors will do) effectively disables OpenCL by reporting
> 0 available platforms.

It looks like an llvm8 not inlining everything properly bug.

with llvm9 I just get a gpu hang when it does inline everything, but
with 8 it fails to inline applyResizeFilter.

llvm8 or some command line option passed to it might need a fix.

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

Re: [Mesa-dev] [PATCH 2/2] mesa: unreference current winsys buffers when unbinding winsys buffers

[Dave Airlie]

https://bugs.freedesktop.org/show_bug.cgi?id=110721

Maybe be a little less trigger happy with the tags, can we get these
reverted in stable :-) and master as well maybe.

Dave.

On Tue, 21 May 2019 at 02:32, Charmaine Lee  wrote:
>
>
> >From: Brian Paul 
> >Sent: Monday, May 20, 2019 6:39 AM
> >To: Charmaine Lee; mesa-dev@lists.freedesktop.org; Neha Bhende; 
> >marek.ol...@amd.com
> >Subject: Re: [PATCH 2/2] mesa: unreference current winsys buffers when 
> >unbinding winsys buffers
>
> >Both look OK to me.  Do they need to be tagged with "Cc:
> mesa-sta...@lists.freedesktop.org" for the stable branches?
>
> >Reviewed-by: Brian Paul 
>
> Yes, I will add the tag.  Thanks Brian for reviewing.
>
> -Charmaine
>
>
>
> >On 05/18/2019 07:46 PM, Charmaine Lee wrote:
> >> This fixes surface leak when no winsys buffers are bound.
> >> ---
> >>   src/mesa/main/context.c | 4 
> >>   1 file changed, 4 insertions(+)
> >>
> >> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
> >> index 34da16b..04ef4d5 100644
> >> --- a/src/mesa/main/context.c
> >> +++ b/src/mesa/main/context.c
> >> @@ -1765,6 +1765,10 @@ _mesa_make_current( struct gl_context *newCtx,
> >>
> >>check_init_viewport(newCtx, drawBuffer->Width, 
> >> drawBuffer->Height);
> >> }
> >> +  else {
> >> + _mesa_reference_framebuffer(&newCtx->WinSysDrawBuffer, NULL);
> >> + _mesa_reference_framebuffer(&newCtx->WinSysReadBuffer, NULL);
> >> +  }
> >>
> >> if (newCtx->FirstTimeCurrent) {
> >>handle_first_current(newCtx);
> >>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] vtn: create cast with type stride.

[Dave Airlie]

From: Dave Airlie 

When creating function parameters, we create pointers from ssa
values, this creates nir casts with stride 0, however we have
no where else to get this value from. Later passes to lower
explicit io need this stride value to do the right thing.
---
 src/compiler/spirv/vtn_variables.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index 1e888bb8bbe..ee76230768c 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1945,7 +1945,7 @@ vtn_pointer_from_ssa(struct vtn_builder *b, nir_ssa_def 
*ssa,
   const struct glsl_type *deref_type = ptr_type->deref->type;
   if (!vtn_pointer_is_external_block(b, ptr)) {
  ptr->deref = nir_build_deref_cast(&b->nb, ssa, nir_mode,
-   deref_type, 0);
+   deref_type, ptr_type->stride);
   } else if (vtn_type_contains_block(b, ptr->type) &&
  ptr->mode != vtn_variable_mode_phys_ssbo) {
  /* This is a pointer to somewhere in an array of blocks, not a
-- 
2.21.0

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

Re: [Mesa-dev] possibly incorrect cut-n-paste in ac_llvm_build.c

[Dave Airlie]

ping? nha? mareko maybe?

Dave.

On Fri, 17 May 2019 at 12:02, Dave Airlie  wrote:
>
> mesa-19.1.0-rc2/src/amd/common/ac_llvm_build.c:4019: copy_paste_error:
> "result_exclusive" in "ws->result_exclusive" looks like a copy-paste
> error.
>
> +   if (ws->enable_inclusive)
> +   ws->result_inclusive = ac_build_alu_op(ctx,
> ws->result_exclusive, ws->src, ws->op);
> +   if (ws->enable_exclusive)
> +   ws->result_exclusive = ac_build_alu_op(ctx,
> ws->result_exclusive, ws->extra, ws->op);
>
> Is that right? maybe a comment?
>
> Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] nir_opt_copy_prop_vars doing the wrong thing

[Dave Airlie]

https://gitlab.freedesktop.org/airlied/mesa/tree/nir-copy-props-cast-test

Contains a unit test that triggers it for me.

Dave.

On Sat, 11 May 2019 at 09:54, Jason Ekstrand  wrote:
>
> We have unit tests for that pass.  Maybe you could write one which exercises 
> the issue?  It'd help in debugging.
>
> On Thu, May 9, 2019 at 8:12 PM Dave Airlie  wrote:
>>
>> I've got a bunch of cases where copy prop vars is getting things wrong
>> around casts, it finds a store to an vec2 but ends up with the
>> writemask staying at 0x3 but the item being store being a single
>> 64-bit.
>>
>> Debug is attached below.
>>
>> Dave.
>>
>> nir_lower_memcpy_deref
>> shader: MESA_SHADER_KERNEL
>> local-size: 0, 0, 0 (variable)
>> shared-size: 1
>> inputs: 16
>> outputs: 0
>> uniforms: 0
>> shared: 0
>> decl_var shader_in INTERP_MODE_NONE uint64_t @0 (0.x, 0, 0)
>> decl_var shader_in INTERP_MODE_NONE uint64_t @1 (1.x, 8, 0)
>> decl_function __wrapped_vload2_private (0 params)
>>
>> impl __wrapped_vload2_private {
>> decl_var  INTERP_MODE_NONE uint[3] @2
>> block block_0:
>> /* preds: */
>> vec1 64 ssa_0 = deref_var &@0 (shader_in uint64_t)
>> vec1 64 ssa_1 = intrinsic load_deref (ssa_0) (0) /* access=0 */
>> vec1 64 ssa_2 = deref_var &@1 (shader_in uint64_t)
>> vec1 64 ssa_3 = intrinsic load_deref (ssa_2) (0) /* access=0 */
>> vec1 64 ssa_4 = load_const (0x   0 /* 0.00 */)
>> vec1 64 ssa_5 = load_const (0x   0 /* 0.00 */)
>> vec1 64 ssa_6 = deref_cast (uint *)ssa_1 (global uint)
>> vec1 64 ssa_7 = deref_cast (uvec2 *)ssa_3 (global uvec2)
>> vec1 32 ssa_8 = intrinsic load_deref (ssa_6) (0) /* access=0 */
>> vec1 64 ssa_9 = deref_var &@2 (function_temp uint[3])
>> vec1 64 ssa_10 = deref_cast (uint[3] *)ssa_9 (function_temp uint[3])
>> vec1 64 ssa_11 = load_const (0x   0 /* 0.00 */)
>> vec1 64 ssa_13 = load_const (0x   0 /* 0.00 */)
>> vec1 64 ssa_14 = deref_array &(*ssa_9)[0] (function_temp uint) /* &@2[0] 
>> */
>> intrinsic store_deref (ssa_14, ssa_8) (1, 0) /* wrmask=x */ /* access=0 
>> */
>> vec1 64 ssa_15 = deref_cast (uint *)ssa_1 (global uint)
>> vec1 64 ssa_16 = load_const (0x   1 /* 0.00 */)
>> vec1 64 ssa_17 = deref_ptr_as_array &(*ssa_15)[1] (global uint) /*
>> &(*(uint *)ssa_1)[1] */
>> vec1 32 ssa_18 = intrinsic load_deref (ssa_17) (0) /* access=0 */
>> vec1 64 ssa_19 = deref_var &@2 (function_temp uint[3])
>> vec1 64 ssa_20 = deref_cast (uint[3] *)ssa_19 (function_temp uint[3])
>> vec1 64 ssa_21 = load_const (0x   0 /* 0.00 */)
>> vec1 64 ssa_23 = load_const (0x   1 /* 0.00 */)
>> vec1 64 ssa_24 = deref_array &(*ssa_19)[1] (function_temp uint) /* 
>> &@2[1] */
>> intrinsic store_deref (ssa_24, ssa_18) (1, 0) /* wrmask=x */ /* access=0 
>> */
>> vec1 64 ssa_25 = deref_cast (uint *)ssa_1 (global uint)
>> vec1 64 ssa_26 = load_const (0x   2 /* 0.00 */)
>> vec1 64 ssa_27 = deref_ptr_as_array &(*ssa_25)[2] (global uint) /*
>> &(*(uint *)ssa_1)[2] */
>> vec1 32 ssa_28 = intrinsic load_deref (ssa_27) (0) /* access=0 */
>> vec1 64 ssa_29 = deref_var &@2 (function_temp uint[3])
>> vec1 64 ssa_30 = deref_cast (uint[3] *)ssa_29 (function_temp uint[3])
>> vec1 64 ssa_31 = load_const (0x   0 /* 0.00 */)
>> vec1 64 ssa_33 = load_const (0x   2 /* 0.00 */)
>> vec1 64 ssa_34 = deref_array &(*ssa_29)[2] (function_temp uint) /* 
>> &@2[2] */
>> intrinsic store_deref (ssa_34, ssa_28) (1, 0) /* wrmask=x */ /* access=0 
>> */
>> vec1 64 ssa_35 = deref_cast (uvec2 *)ssa_14 (function_temp uvec2)
>> vec2 32 ssa_37 = intrinsic load_deref (ssa_35) (0) /* access=0 */
>> intrinsic store_deref (ssa_7, ssa_37) (3, 0) /* wrmask=xy */ /* access=0 
>> */
>> vec1 64 ssa_38 = deref_cast (uvec2 *)ssa_24 (function_temp uvec2)
>> vec2 32 ssa_40 = intrinsic load_deref (ssa_38) (0) /* access=0 */
>> vec1 64 ssa_41 = deref_cast (uvec2 *)ssa_3 (global uvec2)
>> vec1 64 ssa_42 = load_const (0x   1 /* 0.00 */)
>> vec1 64 ssa_43 = deref_ptr_as_array &(*ssa_41)[1] (global uvec2)
>> /* &(*(uvec2 *)ssa_3)[1] */
>> intrinsic store_deref (ssa_43, ssa_40) (3, 0) /* wrmask=xy */ /* 
>> access=0 */
>> /* succs: block_1 */
>>

[Mesa-dev] [PATCH] nir/validate: fix crash if entry is null.

[Dave Airlie]

From: Dave Airlie 

we validate assert entry just before this, but since that doesn't
stop execution, we need to check entry before the next validation
assert.
---
 src/compiler/nir/nir_validate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_validate.c b/src/compiler/nir/nir_validate.c
index 8278176564f..b087b0da12d 100644
--- a/src/compiler/nir/nir_validate.c
+++ b/src/compiler/nir/nir_validate.c
@@ -388,7 +388,7 @@ validate_var_use(nir_variable *var, validate_state *state)
 {
struct hash_entry *entry = _mesa_hash_table_search(state->var_defs, var);
validate_assert(state, entry);
-   if (var->data.mode == nir_var_function_temp)
+   if (entry && var->data.mode == nir_var_function_temp)
   validate_assert(state, (nir_function_impl *) entry->data == state->impl);
 }
 
-- 
2.21.0

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

[Mesa-dev] [PATCH 1/4] glsl: init packed in more constructors.

[Dave Airlie]

From: Dave Airlie 

src/compiler/glsl_types.cpp:577: uninit_member: Non-static class member 
"packed" is not initialized in this constructor nor in any functions that it 
calls.

from Coverity.

Fixes: 659f333b3a4 (glsl: add packed for struct types)
---
 src/compiler/glsl_types.cpp | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index 9938b3df450..8e5087e2e1a 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -50,7 +50,7 @@ glsl_type::glsl_type(GLenum gl_type,
gl_type(gl_type),
base_type(base_type), sampled_type(GLSL_TYPE_VOID),
sampler_dimensionality(0), sampler_shadow(0), sampler_array(0),
-   interface_packing(0), interface_row_major(row_major),
+   interface_packing(0), interface_row_major(row_major), packed(0),
vector_elements(vector_elements), matrix_columns(matrix_columns),
length(0), explicit_stride(explicit_stride)
 {
@@ -85,7 +85,7 @@ glsl_type::glsl_type(GLenum gl_type, glsl_base_type base_type,
base_type(base_type), sampled_type(type),
sampler_dimensionality(dim), sampler_shadow(shadow),
sampler_array(array), interface_packing(0),
-   interface_row_major(0),
+   interface_row_major(0), packed(0),
length(0), explicit_stride(0)
 {
this->mem_ctx = ralloc_context(NULL);
@@ -134,7 +134,7 @@ glsl_type::glsl_type(const glsl_struct_field *fields, 
unsigned num_fields,
base_type(GLSL_TYPE_INTERFACE), sampled_type(GLSL_TYPE_VOID),
sampler_dimensionality(0), sampler_shadow(0), sampler_array(0),
interface_packing((unsigned) packing),
-   interface_row_major((unsigned) row_major),
+   interface_row_major((unsigned) row_major), packed(0),
vector_elements(0), matrix_columns(0),
length(num_fields), explicit_stride(0)
 {
@@ -159,7 +159,7 @@ glsl_type::glsl_type(const glsl_type *return_type,
gl_type(0),
base_type(GLSL_TYPE_FUNCTION), sampled_type(GLSL_TYPE_VOID),
sampler_dimensionality(0), sampler_shadow(0), sampler_array(0),
-   interface_packing(0), interface_row_major(0),
+   interface_packing(0), interface_row_major(0), packed(0),
vector_elements(0), matrix_columns(0),
length(num_params), explicit_stride(0)
 {
@@ -188,7 +188,7 @@ glsl_type::glsl_type(const char *subroutine_name) :
gl_type(0),
base_type(GLSL_TYPE_SUBROUTINE), sampled_type(GLSL_TYPE_VOID),
sampler_dimensionality(0), sampler_shadow(0), sampler_array(0),
-   interface_packing(0), interface_row_major(0),
+   interface_packing(0), interface_row_major(0), packed(0),
vector_elements(1), matrix_columns(1),
length(0), explicit_stride(0)
 {
@@ -534,7 +534,7 @@ glsl_type::glsl_type(const glsl_type *array, unsigned 
length,
  unsigned explicit_stride) :
base_type(GLSL_TYPE_ARRAY), sampled_type(GLSL_TYPE_VOID),
sampler_dimensionality(0), sampler_shadow(0), sampler_array(0),
-   interface_packing(0), interface_row_major(0),
+   interface_packing(0), interface_row_major(0), packed(0),
vector_elements(0), matrix_columns(0),
length(length), name(NULL), explicit_stride(explicit_stride)
 {
-- 
2.21.0

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

[Mesa-dev] [PATCH 4/4] glsl/nir: init non-static class member.

[Dave Airlie]

From: Dave Airlie 

glsl_to_nir.cpp:276: uninit_member: Non-static class member "sig" is not 
initialized in this constructor nor in any functions that it calls.

Reported by coverity
---
 src/compiler/glsl/glsl_to_nir.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index a51d39c4753..d21ad90505e 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -270,6 +270,7 @@ nir_visitor::nir_visitor(gl_context *ctx, nir_shader 
*shader)
this->result = NULL;
this->impl = NULL;
this->deref = NULL;
+   this->sig = NULL;
memset(&this->b, 0, sizeof(this->b));
 }
 
-- 
2.21.0

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

[Mesa-dev] [PATCH 2/4] glsl: init non-static class member in link uniforms.

[Dave Airlie]

From: Dave Airlie 

link_uniforms.cpp:477: uninit_member: Non-static class member 
"shader_storage_blocks_write_access" is not initialized in this constructor nor 
in any functions that it calls.

Reported by coverity.
---
 src/compiler/glsl/link_uniforms.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/link_uniforms.cpp 
b/src/compiler/glsl/link_uniforms.cpp
index aa96227a7e1..641d38689bf 100644
--- a/src/compiler/glsl/link_uniforms.cpp
+++ b/src/compiler/glsl/link_uniforms.cpp
@@ -472,7 +472,8 @@ public:
   bool use_std430_as_default)
   : prog(prog), map(map), uniforms(uniforms),
 use_std430_as_default(use_std430_as_default), values(values),
-bindless_targets(NULL), bindless_access(NULL)
+bindless_targets(NULL), bindless_access(NULL),
+shader_storage_blocks_write_access(9)
{
}
 
-- 
2.21.0

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

[Mesa-dev] [PATCH 3/4] imgui: fix undefined behaviour bitshift.

[Dave Airlie]

From: Dave Airlie 

imgui_draw.cpp:1781: error[shiftTooManyBitsSigned]: Shifting signed 32-bit 
value by 31 bits is undefined behaviour

Reported by coverity
---
 src/imgui/imgui_draw.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/imgui/imgui_draw.cpp b/src/imgui/imgui_draw.cpp
index 1d4e1d51692..c69c01ee801 100644
--- a/src/imgui/imgui_draw.cpp
+++ b/src/imgui/imgui_draw.cpp
@@ -1778,7 +1778,7 @@ static void UnpackBoolVectorToFlatIndexList(const 
ImBoolVector* in, ImVectorpush_back((int)((it - it_begin) << 5) + bit_n);
 }
 
-- 
2.21.0

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

[Mesa-dev] possibly incorrect cut-n-paste in ac_llvm_build.c

[Dave Airlie]

mesa-19.1.0-rc2/src/amd/common/ac_llvm_build.c:4019: copy_paste_error:
"result_exclusive" in "ws->result_exclusive" looks like a copy-paste
error.

+   if (ws->enable_inclusive)
+   ws->result_inclusive = ac_build_alu_op(ctx,
ws->result_exclusive, ws->src, ws->op);
+   if (ws->enable_exclusive)
+   ws->result_exclusive = ac_build_alu_op(ctx,
ws->result_exclusive, ws->extra, ws->op);

Is that right? maybe a comment?

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

[Mesa-dev] undefined behaviour in spirv_to_nir.c

[Dave Airlie]

Coverity gave me this:

mesa-19.1.0-rc2/src/compiler/spirv/spirv_to_nir.c:1987:
overlapping_assignment: Assigning "src[1][i].u8" to "src[1][i].u32",
which have overlapping memory locations and different types.

and the following lines, I think it's actually undefined behaviour wrt
the C spec.

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

Re: [Mesa-dev] [Review Request (master branch)] draw: fix memory leak introduced 7720ce32a

[Dave Airlie]

On Fri, 17 May 2019 at 07:42, Neha Bhende  wrote:
>
> We need to free memory allocation PrimitiveOffsets in draw_gs_destroy().
> This fixes memory leak found while running piglit on windows.

Reviewed-by: Dave Airlie 
>
> Fixes: 7720ce32a ("draw: add support to tgsi paths for geometry streams. 
> (v2)")
>
> Tested with piglit
>
> Reviewed-by: Brian Paul 
> Reviewed-by: Charmaine Lee 
> ---
>  src/gallium/auxiliary/draw/draw_gs.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/draw/draw_gs.c 
> b/src/gallium/auxiliary/draw/draw_gs.c
> index 6420cfbb261..c752163ee05 100644
> --- a/src/gallium/auxiliary/draw/draw_gs.c
> +++ b/src/gallium/auxiliary/draw/draw_gs.c
> @@ -753,8 +753,10 @@ void draw_gs_destroy( struct draw_context *draw )
>  {
> int i;
> if (draw->gs.tgsi.machine) {
> -  for (i = 0; i < TGSI_MAX_VERTEX_STREAMS; i++)
> +  for (i = 0; i < TGSI_MAX_VERTEX_STREAMS; i++) {
>   align_free(draw->gs.tgsi.machine->Primitives[i]);
> + align_free(draw->gs.tgsi.machine->PrimitiveOffsets[i]);
> +  }
>tgsi_exec_machine_destroy(draw->gs.tgsi.machine);
> }
>  }
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] ac: rename SI-CIK-VI to GFX6-GFX7-GFX8

[Dave Airlie]

> From: Marek Olšák 

It would be nice to have a reasoning why, I assume that is what they
are called internally and in the kernel, but it would be good to
mention something to justify it in the commit msg.

Acked-by: Dave Airlie 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] ac: add comments to chip enums

[Dave Airlie]

Reviewed-by: Dave Airlie 

On Wed, 15 May 2019 at 12:17, Marek Olšák  wrote:
>
> From: Marek Olšák 
>
> ---
>  src/amd/common/amd_family.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/src/amd/common/amd_family.h b/src/amd/common/amd_family.h
> index 185ba029763..eed6553d44b 100644
> --- a/src/amd/common/amd_family.h
> +++ b/src/amd/common/amd_family.h
> @@ -50,5 +50,5 @@ enum radeon_family {
>  CHIP_RV560,
>  CHIP_RV570,
> -CHIP_R600,
> +CHIP_R600, /* R6xx */
>  CHIP_RV610,
>  CHIP_RV630,
> @@ -58,9 +58,9 @@ enum radeon_family {
>  CHIP_RS780,
>  CHIP_RS880,
> -CHIP_RV770,
> +CHIP_RV770,/* R7xx */
>  CHIP_RV730,
>  CHIP_RV710,
>  CHIP_RV740,
> -CHIP_CEDAR,
> +CHIP_CEDAR,/* Evergreen */
>  CHIP_REDWOOD,
>  CHIP_JUNIPER,
> @@ -73,17 +73,17 @@ enum radeon_family {
>  CHIP_TURKS,
>  CHIP_CAICOS,
> -CHIP_CAYMAN,
> +CHIP_CAYMAN,   /* Northern Islands */
>  CHIP_ARUBA,
> -CHIP_TAHITI,
> +CHIP_TAHITI,   /* GFX6 (Southern Islands) */
>  CHIP_PITCAIRN,
>  CHIP_VERDE,
>  CHIP_OLAND,
>  CHIP_HAINAN,
> -CHIP_BONAIRE,
> +CHIP_BONAIRE,  /* GFX7 (Sea Islands) */
>  CHIP_KAVERI,
>  CHIP_KABINI,
>  CHIP_HAWAII,
>  CHIP_MULLINS,
> -CHIP_TONGA,
> +CHIP_TONGA,/* GFX8 (Volcanic Islands & Polaris) */
>  CHIP_ICELAND,
>  CHIP_CARRIZO,
> @@ -94,5 +94,5 @@ enum radeon_family {
>  CHIP_POLARIS12,
>  CHIP_VEGAM,
> -CHIP_VEGA10,
> +CHIP_VEGA10,   /* GFX9 (Vega) */
>  CHIP_VEGA12,
>  CHIP_VEGA20,
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] nir_opt_copy_prop_vars doing the wrong thing

[Dave Airlie]

I've got a bunch of cases where copy prop vars is getting things wrong
around casts, it finds a store to an vec2 but ends up with the
writemask staying at 0x3 but the item being store being a single
64-bit.

Debug is attached below.

Dave.

nir_lower_memcpy_deref
shader: MESA_SHADER_KERNEL
local-size: 0, 0, 0 (variable)
shared-size: 1
inputs: 16
outputs: 0
uniforms: 0
shared: 0
decl_var shader_in INTERP_MODE_NONE uint64_t @0 (0.x, 0, 0)
decl_var shader_in INTERP_MODE_NONE uint64_t @1 (1.x, 8, 0)
decl_function __wrapped_vload2_private (0 params)

impl __wrapped_vload2_private {
decl_var  INTERP_MODE_NONE uint[3] @2
block block_0:
/* preds: */
vec1 64 ssa_0 = deref_var &@0 (shader_in uint64_t)
vec1 64 ssa_1 = intrinsic load_deref (ssa_0) (0) /* access=0 */
vec1 64 ssa_2 = deref_var &@1 (shader_in uint64_t)
vec1 64 ssa_3 = intrinsic load_deref (ssa_2) (0) /* access=0 */
vec1 64 ssa_4 = load_const (0x   0 /* 0.00 */)
vec1 64 ssa_5 = load_const (0x   0 /* 0.00 */)
vec1 64 ssa_6 = deref_cast (uint *)ssa_1 (global uint)
vec1 64 ssa_7 = deref_cast (uvec2 *)ssa_3 (global uvec2)
vec1 32 ssa_8 = intrinsic load_deref (ssa_6) (0) /* access=0 */
vec1 64 ssa_9 = deref_var &@2 (function_temp uint[3])
vec1 64 ssa_10 = deref_cast (uint[3] *)ssa_9 (function_temp uint[3])
vec1 64 ssa_11 = load_const (0x   0 /* 0.00 */)
vec1 64 ssa_13 = load_const (0x   0 /* 0.00 */)
vec1 64 ssa_14 = deref_array &(*ssa_9)[0] (function_temp uint) /* &@2[0] */
intrinsic store_deref (ssa_14, ssa_8) (1, 0) /* wrmask=x */ /* access=0 */
vec1 64 ssa_15 = deref_cast (uint *)ssa_1 (global uint)
vec1 64 ssa_16 = load_const (0x   1 /* 0.00 */)
vec1 64 ssa_17 = deref_ptr_as_array &(*ssa_15)[1] (global uint) /*
&(*(uint *)ssa_1)[1] */
vec1 32 ssa_18 = intrinsic load_deref (ssa_17) (0) /* access=0 */
vec1 64 ssa_19 = deref_var &@2 (function_temp uint[3])
vec1 64 ssa_20 = deref_cast (uint[3] *)ssa_19 (function_temp uint[3])
vec1 64 ssa_21 = load_const (0x   0 /* 0.00 */)
vec1 64 ssa_23 = load_const (0x   1 /* 0.00 */)
vec1 64 ssa_24 = deref_array &(*ssa_19)[1] (function_temp uint) /* &@2[1] */
intrinsic store_deref (ssa_24, ssa_18) (1, 0) /* wrmask=x */ /* access=0 */
vec1 64 ssa_25 = deref_cast (uint *)ssa_1 (global uint)
vec1 64 ssa_26 = load_const (0x   2 /* 0.00 */)
vec1 64 ssa_27 = deref_ptr_as_array &(*ssa_25)[2] (global uint) /*
&(*(uint *)ssa_1)[2] */
vec1 32 ssa_28 = intrinsic load_deref (ssa_27) (0) /* access=0 */
vec1 64 ssa_29 = deref_var &@2 (function_temp uint[3])
vec1 64 ssa_30 = deref_cast (uint[3] *)ssa_29 (function_temp uint[3])
vec1 64 ssa_31 = load_const (0x   0 /* 0.00 */)
vec1 64 ssa_33 = load_const (0x   2 /* 0.00 */)
vec1 64 ssa_34 = deref_array &(*ssa_29)[2] (function_temp uint) /* &@2[2] */
intrinsic store_deref (ssa_34, ssa_28) (1, 0) /* wrmask=x */ /* access=0 */
vec1 64 ssa_35 = deref_cast (uvec2 *)ssa_14 (function_temp uvec2)
vec2 32 ssa_37 = intrinsic load_deref (ssa_35) (0) /* access=0 */
intrinsic store_deref (ssa_7, ssa_37) (3, 0) /* wrmask=xy */ /* access=0 */
vec1 64 ssa_38 = deref_cast (uvec2 *)ssa_24 (function_temp uvec2)
vec2 32 ssa_40 = intrinsic load_deref (ssa_38) (0) /* access=0 */
vec1 64 ssa_41 = deref_cast (uvec2 *)ssa_3 (global uvec2)
vec1 64 ssa_42 = load_const (0x   1 /* 0.00 */)
vec1 64 ssa_43 = deref_ptr_as_array &(*ssa_41)[1] (global uvec2)
/* &(*(uvec2 *)ssa_3)[1] */
intrinsic store_deref (ssa_43, ssa_40) (3, 0) /* wrmask=xy */ /* access=0 */
/* succs: block_1 */
block block_1:
}

nir_opt_copy_prop_vars
## nir_copy_prop_vars_impl for __wrapped_vload2_private
# block0

  vec1 64 ssa_0 = deref_var &unnamed (shader_in uint64_t)
  vec1 64 ssa_1 = intrinsic load_deref (ssa_0) (0) /* access=0 */
uint64_t unnamed: ssa_1

  vec1 64 ssa_2 = deref_var &unnamed (shader_in uint64_t)
  vec1 64 ssa_3 = intrinsic load_deref (ssa_2) (0) /* access=0 */
uint64_t unnamed: ssa_1
uint64_t unnamed: ssa_3

  vec1 64 ssa_6 = deref_cast (uint *)ssa_1 (global uint)
  vec1 64 ssa_7 = deref_cast (uvec2 *)ssa_3 (global uvec2)
  vec1 32 ssa_8 = intrinsic load_deref (ssa_6) (0) /* access=0 */
uint64_t unnamed: ssa_1
uint64_t unnamed: ssa_3
uint (uint *)ssa_1: ssa_8

  vec1 64 ssa_9 = deref_var &unnamed (function_temp uint[3])
  vec1 64 ssa_10 = deref_cast (uint[3] *)ssa_9 (function_temp uint[3])
  vec1 64 ssa_14 = deref_array &(*ssa_9)[0] (function_temp uint) /*
&unnamed[0] */
  intrinsic store_deref (ssa_14, ssa_8) (1, 0) /* wrmask=x */ /* access=0 */
uint64_t unnamed: ssa_1
uint64_t unnamed: ssa_3
uint (uint *)ssa_1: ssa_8
uint unnamed[0]: ssa_8

  vec1 64 ssa_15 = deref_cast (uint *)ssa_1 

[Mesa-dev] [PATCH] kmsro: add _dri.so to two of the kmsro drivers.

[Dave Airlie]

From: Dave Airlie 

---
 src/gallium/targets/dri/meson.build | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/targets/dri/meson.build 
b/src/gallium/targets/dri/meson.build
index dd40969a166..45daf647960 100644
--- a/src/gallium/targets/dri/meson.build
+++ b/src/gallium/targets/dri/meson.build
@@ -78,8 +78,8 @@ foreach d : [[with_gallium_kmsro, [
'pl111_dri.so',
'repaper_dri.so',
'rockchip_dri.so',
-   'st7586.so',
-   'st7735r.so',
+   'st7586_dri.so',
+   'st7735r_dri.so',
   'sun4i-drm_dri.so',
  ]],
  [with_gallium_radeonsi, 'radeonsi_dri.so'],
-- 
2.20.1

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