Re: GBM as standalone buffer allocator

[Rob Clark]

On Mon, Oct 23, 2023 at 6:22 AM Srinivas Pullakavi (QUIC)
 wrote:
>
> Hi,
>
>
>
> We are planning to enhance GBM as a standalone buffer allocator, which can be 
> used for all multi-media clients. Ex: video, camera, display etc;
>
>
>
> GBM create device expects a file descriptor to be passed, which points to drm 
> node. This brings in a dependency on display for buffer allocation. On 
> headless devices where display driver is not present, GBM cannot be used for 
> buffer allocations. E.g. Recording cases where pipeline is setup between 
> Camera, Video, Graphics.
>

Note that you need some sort of device to allocate buffers from.  With
mesa and upstream kernel, that would be the drm device.  (However as
Adam points out, a drm device does not necessarily need a display..
for example, several vendors have compute-only GPUs (pci) which have
no display outputs.)

You might want to look at ChromeOS's minigbm.  It already handles
these cases (buffer sharing across display/gpu/video/camera).

BR,
-R

[1] https://chromium.googlesource.com/chromiumos/platform/minigbm/

>
> Could you please share your comments on what will be a good design to make 
> GBM flexible for above?
>
>
>
> Thanks,
>
> Srinivas
>
>

Re: Question: error when running [Virtio-GPU Venus->vtest]

[Rob Clark]

On Fri, Nov 4, 2022 at 1:42 AM Taylor Viktor  wrote:
>
> Dear Developers:
>
> I am referring to this document 
> https://docs.mesa3d.org/drivers/venus.html#vtest to develop vulkan related 
> functions, but every time I run vulkaninfo or vkcube some errors occur.
>
> virgl_test_server prints the following:
>
> gl_version 46 - core profile enabled vtest_client_dispatch_commands: client 
> context created. client failed: VTEST_CLIENT_ERROR_INPUT_READ

I'm not sure about the venus/vk case, but I got the same error when
trying to use virgl+vtest the other day.  I think this must have
broken semi-recently, but didn't try to bisect or figure out if the
issue was in mesa or virglrenderer

BR,
-R

Re: [ANNOUNCE] mesa 22.3.0-rc1

[Rob Clark]

On Wed, Nov 2, 2022 at 11:00 PM Tapani Pälli  wrote:
>
>
>
> On 2.11.2022 23.25, Eric Engestrom wrote:
> > Hello everyone,
> >
> > I'm happy to announce the start of a new release cycle with the first
> > release candidate, 22.3.0-rc1.
> >
> > New features (in no particular order):
> > - GL_ARB_shader_clock on llvmpipe
> > - VK_KHR_shader_clock on lavapipe
> > - Mesa-DB, the new single file cache type
> > - VK_EXT_attachment_feedback_loop_layout on RADV, lavapipe
> > - VK_KHR_global_priority on RADV
> > - GL_KHR_blend_equation_advanced_coherent on zink
> > - VK_EXT_load_store_op_none on RADV
> > - VK_EXT_mutable_descriptor_type on RADV
> > - VK_EXT_shader_atomic_float on lvp
> > - VK_EXT_shader_atomic_float2 on lvp
> > - GL_NV_shader_atomic_float on llvmpipe
> > - VK_EXT_image_robustness on v3dv
> > - VK_EXT_extended_dynamic_state3 on lavapipe
> > - VK_EXT_extended_dynamic_state3 on RADV
>
> + VK_EXT_extended_dynamic_state3 on anv

gl33 -> gl45 on freedreno/a6xx (I was going to list the extensions,
but it is a lot, and all but a few were enabled by switching on
pipe-caps for things already supported)

BR,
-R

>
> > - VK_EXT_pipeline_robustness on v3dv
> > - Mali T620 on panfrost
> > - Shader disk cache on Panfrost
> > - support for R8G8B8, B8G8R8, R16G16B16 and 64-bit vertex buffer formats
> >on RADV
> > - initial GFX11/RDNA3 support on RADV
> > - various ray tracing optimizations on RADV
> > - extendedDynamicState2PatchControlPoints on RADV
> >(VK_EXT_extended_dynamic_state2 feature)
> > - Radeon Raytracing Analyzer integration (using RADV_RRA_* environment
> >variables)
> >
> > A couple of notes for packagers:
> > - When building the Intel Vulkan driver with ray-tracing (using
> >`-D intel-clc=enabled`, disabled by default), libclc is required
> >(both as build and runtime dependency).
> > - Rusticl, the OpenCL implementation (`-D gallium-rusticl=true`,
> >disabled by default), introduces a bunch of new dependencies.
> >Make sure you read docs/rusticl.rst (https://docs.mesa3d.org/rusticl)
> >if you're considering enabling it.
> >
> > For now, no driver is enabled by default in Rusticl. See here for how
> > to enable them:
> > https://docs.mesa3d.org/envvars#rusticl-environment-variables
> >
> > If you find any issues, please report them here:
> > https://gitlab.freedesktop.org/mesa/mesa/-/issues/new
> >
> > The next release candidate is expected in one week, on November 9th.
> >
> > Cheers,
> >Eric
> >
> > ---
> >
> > git tag: mesa-22.3.0-rc1
> >
> > https://mesa.freedesktop.org/archive/mesa-22.3.0-rc1.tar.xz
> > SHA256: 2f2e0fca149bd8dcc333ebeda14fc14ebd8a10c3560cf2958b5ebdaa455d0566  
> > mesa-22.3.0-rc1.tar.xz
> > SHA512: 
> > 5222759260f0288c28fab9ba419a7699aa85033ccf30fb5070ae558e342158ef0981974196fd10c738fa187b774807d4a2de03b98360efef5c03040484abd52c
> >   mesa-22.3.0-rc1.tar.xz
> > PGP:  https://mesa.freedesktop.org/archive/mesa-22.3.0-rc1.tar.xz.sig
> >

Re: Moving amber into separate repo?

[Rob Clark]

On Fri, Sep 23, 2022 at 3:33 AM Filip Gawin  wrote:
>
> Hi, recently I've seen case of user been using Amber when hardware was 
> supported by mainline mesa. This gave me a couple of thoughts.
>
> 1) Users don't correlate "Amber" with "Legacy" and probably it's gonna be 
> best to always also print "Legacy" together with "Mesa".
> 2) Not sure if problem of choosing best driver is on mesa's or distro 
> maintainer's side, but it became more complicated for maintainers.
>
> I'm thinking that moving Amber into separate repo may make this situation 
> more clear. (Disabling duplicated drivers or only allowing glsl_to_tgsi 
> codepath may futher help.)
>
> Some more reasoning from gitlab:
>
> web based tools provided by gitlab are quite useful, unfortunately they work 
> best with main branch.
> repo is growing large. Amber kinda requires long history, modern mesa not. 
> This may be good spot to split if cleanup is required.
> imho having amber's issues in this repo, won't create new contributors. Due 
> to lack of kernel driver (on commercial level) or documentation for these 
> gpus, so you need to be both mesa and kernel developer. (Any contribution is 
> gonna require deep knowledge about hardware, domain and time consuming 
> effort.)
> for normal users (not software developers) amber is kinda "hidden under the 
> carpet". Communities like vogons may be interested in having simpler access 
> to kinda documentation for these ancient gpus.
>

not sure we need a different repo, but I would recommend
disabling/removing drivers (gallium and vk) in the amber branch which
are maintained in the main branch

BR,
-R

>
> Thanks for all insights, Filip.

Re: revenge of CALLOC_STRUCT

[Rob Clark]

On Wed, Dec 22, 2021 at 2:36 PM Dave Airlie  wrote:
>
> 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?

u_memory.h already got promoted to src/util, so let's just use that

BR,
-R

Re: [Mesa-dev] Merge blocked

[Rob Clark]

Please don't merge or push directly, that will interfere with
marge-bot when it's trying to merge someone else's MR

BR,
-R

On Tue, Sep 21, 2021 at 7:56 AM Jose Fonseca  wrote:
>
> Hi Gert,
>
> > I can understand your frustration with the flaky tests,
>
> My frustration comes as much from the Gitlab config as from the flaky tests.
>
> But you have a point: if tests weren't flaky this certainly wouldn't be much 
> of a problem, and filing bugs is probably the best course of action to avoid 
> them.
>
> > but I'm sure you know that having a CI is place helps a lot to not break 
> > most of the code, so merging without having to go through the CI is not 
> > really an option, even if we are all sensible adults.
>
> I don't follow the logic.  Anybody with commit access can push from git 
> command line bypassing any pipeline checks.  We're already relying upon 
> folks' judgment to use it only when it makes sense (e.g, crossporing commits, 
> etc.)  I don't see why having a UI button to automate makes a difference.
>
> Reassigning to marge-bot is easy enough, but IIUC that causes all pipeline 
> stages (even those which were successful) to be repeated.  I feel that's 
> wasteful (not just money, but also energy.)  Allowing one to Rebase + Merge 
> on one click (like GitHub allows) would be more efficient IMHO.
>
> Anyway, for good or worse, I don't commit to Mesa as much as I used to, so 
> this doesn't affect me nearly as much as others.  Even though I believe 
> allowing to merge without pipeline object would be an improvement, if 
> everybody else is happy with the status quo, then don't mind me.
>
> Jose
>
> 
> From: Gert Wollny 
> Sent: Tuesday, September 21, 2021 15:32
> To: Jose Fonseca ; ML mesa-dev 
> 
> Subject: Re: [Mesa-dev] Merge blocked
>
> Hello Jose,
>
> On Tue, 2021-09-21 at 11:48 +, Jose Fonseca wrote:
> > Why doesn't Gilab allow one to merge manually?
> >
> > See 
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F12940data=04%7C01%7Cjfonseca%40vmware.com%7C93aedc8ac8244272385008d97d0c9cfa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637678315394314865%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=pIjQSUjrU7cCePEsmpcZ7qbdCFFhxZn0y3S7qSS8s7s%3Dreserved=0:
> >
> >  * Marge-bot failed to merge the PR due to 2 flaky tests, completely
> > unrelated to the commits in question.
>
> I can understand your frustration with the flaky tests, but I'm sure
> you know that having a CI is place helps a lot to not break most of the
> code, so merging without having to go through the CI is not really an
> option, even if we are all sensible adults.
>
> Maybe we all should just file bugs when we see a flaky test, so that
> those get flagged accordingly by the developers responsible for the
> related drivers.
>
> >
> >  * I manually retried the failed tests, and they all passed, but
> > still Gitlab refused to allow to merge: it said I needed to rebase.
> This is, because Marge merged some other MR between the time you
> rebased the last time. Since the pre-merge CI was added and before
> Marge was introduced, this actually happened quite regularly: Press the
> Merge-when-pipeline-succeeds button and fail, because some other merge
> request was already in the pipeline and got merged before your pipeline
> finished.
> However, nowadays you don't need to rebase yourself, once you assign
> the MR to Marge and she will do that for you when she starts to handle
> your merge request.
>
> >  * I rebased, but still Gitlab refused to merge: now it expects the
> > pipelines to be runagain!
> I'm really sorry for your frustration, but if you're sure that the
> merge failed only because if flaky tests, then simply reassigning the
> MR to Marge will do.
>
> > Is it really necessary to go to git command line to get a PR
> > merged!?  (I was forced to do so 2-3 times now, but it's a hassle.)
> No, it is not necessary, because Marge will do that for you, once you
> assign the MR to her.
>
> > Or run pipelines over and over until one eventually succeeds?
> This is only a problem because of the flaky tests, and yes, we should
> do something about this.
>
> > Sorry for the rant, but I didn't notice anybody else complain.  Am I
> > the only bothered here?  Or is there a better way here I don't know
> > of?
> As you sure have understood at this point, the answer is "Assign to
> Marge" ;)
>
> Best regards,
> Gert
>
>

Re: [Mesa-dev] outstanding patches for 21.2

[Rob Clark]

On Wed, Sep 15, 2021 at 10:08 AM Dylan Baker  wrote:
>
> Hi everyone, there's a few patch now outstanding for the 21.2 branch,
> and I'd like to get some help from the relavent develoeprs on either
> backporting them, or droping them. I've commented them as relavent
>
> 2021-08-10 FIXES  a79ac1bee1 freedreno: Use correct key for binning pass 
> shader

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

> 2021-09-01 FIXES  6373dd814a ir3/a6xx,freedreno: account for resinfo return 
> size dependency on IBO_0_FMT

Let's drop this one, it would require backporting !12258

BR,
-R

Re: [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules

[Rob Clark]

On Fri, May 21, 2021 at 2:10 AM Daniel Vetter  wrote:
>
> - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT,
>   but because it doesn't use the drm/scheduler it handles fences from
>   the wrong context with a synchronous dma_fence_wait. See
>   submit_fence_sync() leading to msm_gem_sync_object(). Investing into
>   a scheduler might be a good idea.

Yeah, drm/scheduler is (along with a lot of other things) on the TODO
list.  But this isn't quite as bad as it sounds because userspace uses
a u_queue thread to call the submit ioctl rather than blocking the
driver.  (It also offloads some other work from the driver thread,
like submit merging to reduce # of ioctls.  Coincidentally that
arrangement was a step towards preparing userspace for some
hypothetical non-ioctl uapi ;-))

OTOH it would be good to move blocking until the system can free
enough pages to repin bo's out of the ioctl path to better handle some
memory pressure corner cases without having to be interruptable over a
lot more of the submit path..  Running chrome+android on devices
without a lot of memory is fun..

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

Re: [Mesa-dev] Viability of Mesa 21.0.2 with Windows 10 ARM - Snapdragon/Adreno

[Rob Clark]

+Jesse since he knows something about windows

So, there are few different questions here:

1) 8cx/a680 .. the userspace difference compared to a6xx devices that
are already supported is pretty small.. but I still need to find some
time to do (linux) kernel side bringup

2) mesa on windows .. ie. egl/etc integration with the winsys.. not
sure, maybe this is a thing Jesse knows about?

3) freedreno on windows .. I know fairly little about windows.  In
$mesa/src/freedreno/drm there is a sort of "kernel driver"
abstraction, so I suppose if someone managed to figure out how the
interface to the windows kernel mode driver worked, it might be
possible.  I suspect this is not publicly documented anywhere.  (Or at
least the adreno specifics are not.)

There is some ongoing work for 8cx laptops running linux, but pretty
early stages at this point.  The slightly older 850 devices are better
supported.. see https://github.com/aarch64-laptops/debian-cdimage for
example

BR,
-R

On Sun, Apr 18, 2021 at 5:51 PM Will Gaines  wrote:
>
> Hello and greetings; please indulge me as I'll probably come across as an 
> idiot, but I can't seem to get a straight answer regarding what I've been 
> trying to do. I sincerely hope someone will be able to lay out clearly if I'm 
> on a fool's errand which is fine because I can stop wasting my time.
>
> Briefly, I picked up a Samsung Galaxy Book S with the Snapdragon 8cx/Adreno 
> 680 build running Windows 10 on ARM. Based on everything I've understood, 
> while the hardware isn't terrible, the architecture and MS struggling with 
> 64-bit x86 emulation is what could be holding it back from being a 
> serviceable machine for some gaming. I didn't really get on this until I 
> hopped on Windows Insider and went to the 21359 build in the Dev Channel. 
> I've gotten stable runs of games like Wasteland 3 on low settings but feel 
> like there's either a solution or someone has looked and found it a dead-end 
> to get better performance.
>
> Long story short, I think Mesa3D might work but I've combed through documents 
> and logs regarding compatibility with Windows 10 ARM and an Adreno GPU. The 
> latest release suggests it's possible, but before I put any more time into it 
> I wanted to know if anyone had experience along these lines: can the dev 
> build features support everything needed to set up and has there been any 
> roadblocks? Thanks for hearing me out, I appreciate it.
>
>
> Scott free
> ___
> 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] [RFC] Concrete proposal to split classic

[Rob Clark]

I'm considering freedreno a2xx, although that is not a separate build
option from meson PoV.. I'd welcome arguments one way or another from
any stakeholder

(we also have a bit of a CI gap for a4xx.. although other than the
usual "shuffle all the registers/bitfields around" that we see between
gens it has a lot in common with a3xx/a5xx which do have CI coverage,
so I'm a bit less concerned about unintentionally breaking it)

BR,
-R

On Mon, Mar 29, 2021 at 3:48 PM Marek Olšák  wrote:
>
> Alright that's r300 and swr that are going to find a new home in the lts 
> branch. Do any other gallium drivers want to join them?
>
> Marek
>
> On Mon., Mar. 29, 2021, 13:51 Zielinski, Jan,  wrote:
>>
>> On Thursday, March 25, 2021 8:47 Marek Olšák wrote:
>> > Same thinking could be applied to other gallium drivers for old hardware 
>> > that don't receive new development and are becoming more and more 
>> > irrelevant every year due to their age.
>>
>> Can we also keep Gallium for OpenSWR driver on -lts branch? We currently are 
>> focusing effort on other OSS projects, and want to maintain OpenSWR at its 
>> current feature level, but we are often seeing Mesa core changes causing 
>> problems in OpenSWR, that we can’t always address right away. So, we would 
>> like to point our users to a stable branch, that limits the amount of effort 
>> required for OpenSWR to support its existing users.
>>
>> Jan
>>
>> On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote:
>> > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark <mailto:robdcl...@gmail.com> 
>> > wrote:
>> > >
>> > > On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker <mailto:dy...@pnwbakers.com> 
>> > > wrote:
>> > > >
>> > > > Hi list,
>> > > >
>> > > > We've talked about it a number of times, but I think it's time time to
>> > > > discuss splitting the classic drivers off of the main development 
>> > > > branch
>> > > > again, although this time I have a concrete plan for how this would
>> > > > work.
>> > > >
>> > > > First, why? Basically, all of the classic drivers are in maintanence
>> > > > mode (even i965). Second, many of them rely on code that no one works
>> > > > on, and very few people still understand. There is no CI for most of
>> > > > them, and the Intel CI is not integrated with gitlab, so it's easy to
>> > > > unintentionally break them, and this breakage usually isn't noticed
>> > > > until just before or just after a release. 21.0 was held up (in small
>> > > > part, also me just getting behind) because of such breakages.
>> > > >
>> > > > I konw there is some interest in getting i915g in good enough shape 
>> > > > that
>> > > > it could replace i915c, at least for the common case. I also am aware
>> > > > that Dave, Ilia, and Eric (with some pointers from Ken) have been
>> > > > working on a gallium driver to replace i965. Neither of those things 
>> > > > are
>> > > > ready yet, but I've taken them into account.
>> > > >
>> > > > Here's the plan:
>> > > >
>> > > > 1) 21.1 release happens
>> > > > 2) we remove classic from master
>> > > > 3) 21.1 reaches EOL because of 21.2
>> > > > 4) we fork the 21.1 branch into a "classic-lts"¹ branch
>> > > > 5) we disable all vulkan and gallium drivers in said branch, at least 
>> > > > at
>> > > >the Meson level
>> > >
>> > > I'm +1 for the -lts branch.. the layering between mesa "classic" and
>> > > gallium is already starting to get poked thru in the name of
>> > > performance, and we've already discovered cases of classic drivers
>> > > being broken for multiple months with no one noticing.  I think a
>> > > slower moving -lts branch is the best approach to keeping things
>> > > working for folks with older hw.
>> > >
>> > > But possibly there is some value in not completely disabling gallium
>> > > completely in the -lts branch.  We do have some older gallium drivers
>> > > which do not have CI coverage and I think are not used frequently by
>> > > developers who are tracking the latest main/master branch.  I'm not
>> > > suggesting that we remove them from the main (non-lts) branch but it
>> > > might be useful to be abl

Re: [Mesa-dev] [RFC] Concrete proposal to split classic

[Rob Clark]

On Thu, Mar 25, 2021 at 2:12 PM Kenneth Graunke  wrote:
>
> On Thursday, March 25, 2021 10:15:51 AM PDT Rob Clark wrote:
> > Other than the minor detail that we don't have pci-id's to
> > differentiate between adreno generations, I might suggest a2xx users
> > to use -lts
> >
> > BR,
> > -R
>
> Could it be set up such that freedreno in mainline fails to load on
> a2xx (and you could delete such code), while freedreno in -lts fails
> to load on a3xx+?  Basically, don't have any overlapping HW support
> in both branches.
>
> --Ken

ahh, if glvnd moves on to try the next driver after the first one
fails, that would work perfectly.  Not sure if I'd remove the code
from mainline but might hide it behind a debug flag.  Haven't thought
it through too much yet, since I assumed it would require teaching
glvnd new things.  But it would be nice to worry less about breaking
things that aren't in CI and not easy to test.

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

Re: [Mesa-dev] [RFC] Concrete proposal to split classic

[Rob Clark]

Other than the minor detail that we don't have pci-id's to
differentiate between adreno generations, I might suggest a2xx users
to use -lts

BR,
-R

On Thu, Mar 25, 2021 at 9:14 AM Dylan Baker  wrote:
>
> By delete I mean "remove -Dgallium-drivers and -Dvulkan-drivers" from Meson. 
> Maybe it makes sense to keep gallium for r300? But how many r300 breakages 
> have we had in recent memory?
>
> On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote:
> > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark  wrote:
> > >
> > > On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker  wrote:
> > > >
> > > > Hi list,
> > > >
> > > > We've talked about it a number of times, but I think it's time time to
> > > > discuss splitting the classic drivers off of the main development branch
> > > > again, although this time I have a concrete plan for how this would
> > > > work.
> > > >
> > > > First, why? Basically, all of the classic drivers are in maintanence
> > > > mode (even i965). Second, many of them rely on code that no one works
> > > > on, and very few people still understand. There is no CI for most of
> > > > them, and the Intel CI is not integrated with gitlab, so it's easy to
> > > > unintentionally break them, and this breakage usually isn't noticed
> > > > until just before or just after a release. 21.0 was held up (in small
> > > > part, also me just getting behind) because of such breakages.
> > > >
> > > > I konw there is some interest in getting i915g in good enough shape that
> > > > it could replace i915c, at least for the common case. I also am aware
> > > > that Dave, Ilia, and Eric (with some pointers from Ken) have been
> > > > working on a gallium driver to replace i965. Neither of those things are
> > > > ready yet, but I've taken them into account.
> > > >
> > > > Here's the plan:
> > > >
> > > > 1) 21.1 release happens
> > > > 2) we remove classic from master
> > > > 3) 21.1 reaches EOL because of 21.2
> > > > 4) we fork the 21.1 branch into a "classic-lts"¹ branch
> > > > 5) we disable all vulkan and gallium drivers in said branch, at least at
> > > >the Meson level
> > >
> > > I'm +1 for the -lts branch.. the layering between mesa "classic" and
> > > gallium is already starting to get poked thru in the name of
> > > performance, and we've already discovered cases of classic drivers
> > > being broken for multiple months with no one noticing.  I think a
> > > slower moving -lts branch is the best approach to keeping things
> > > working for folks with older hw.
> > >
> > > But possibly there is some value in not completely disabling gallium
> > > completely in the -lts branch.  We do have some older gallium drivers
> > > which do not have CI coverage and I think are not used frequently by
> > > developers who are tracking the latest main/master branch.  I'm not
> > > suggesting that we remove them from the main (non-lts) branch but it
> > > might be useful to be able to recommend users of those drivers stick
> > > with the -lts version for better stability?
> >
> > I agree with this.  Generally, I don't think we should delete anything
> > from the -lts branch.  Doing so only risks more breakage.  We probably
> > want to change some meson build defaults to not build anything but old
> > drivers but that's it.
> >
> > --Jason
> >
> > > BR,
> > > -R
> > >
> > > > 6) We change the name and precidence of the glvnd loader file
> > > > 7) apply any build fixups (turn of intel generators for versions >= 7.5,
> > > >for example
> > > > 8) maintain that branch with build and critical bug fixes only
> > > >
> > > > This gives ditros and end users two options.
> > > > 1) then can build *only* the legacy branch in the a normal Mesa provides
> > > >libGL interfaces fashion
> > > > 2) They can use glvnd and install current mesa and the legacy branch in
> > > >parallel
> > > >
> > > > Because of glvnd, we can control which driver will get loaded first, and
> > > > thus if we decide i915g or the i965 replacement is ready and turn it on
> > > > by default it will be loaded by default. An end user who doesn't like
> > > > this can add a new glvnd loader file that makes the classic drivers
> > > &g

Re: [Mesa-dev] Rename "master" branch to "main"?

[Rob Clark]

On Wed, Mar 24, 2021 at 9:15 PM Jason Ekstrand  wrote:
>
> On March 24, 2021 22:25:10 Rob Clark  wrote:
>
>> On Wed, Mar 24, 2021 at 3:52 PM Jordan Justen  
>> wrote:
>>>
>>>
>>> On 2021-03-23 09:38:59, Eric Anholt wrote:
>>>>
>>>> On Tue, Mar 23, 2021 at 7:02 AM Jason Ekstrand  
>>>> wrote:
>>>>>
>>>>>
>>>>> Trying to pick this discussion back up.  Daniel Stone thinks it's a
>>>>> half hour of API bashing to retarget all the MRs so, if the fd.o
>>>>> admins have some heads up, it should be tractable.  Should we do this
>>>>> right after branching 21.1 along with the LTS branch?
>>>>
>>>>
>>>> +1
>>>
>>>
>>> Jason,
>>>
>>> I opened a related Mesa issue:
>>> https://gitlab.freedesktop.org/mesa/mesa/-/issues/4501
>>>
>>> I made this change in crucible, and used a script to update the 7 MR
>>> target branches:
>>> https://gitlab.freedesktop.org/mesa/crucible/-/issues/5
>>>
>>> As mentioned in the Mesa issue, I think we should use piglit as
>>> another test run before changing Mesa:
>>> https://gitlab.freedesktop.org/mesa/piglit/-/issues/50
>>>
>>> Piglit currently has 60 open merge requests.
>>
>>
>> I'm in favor of branch rename, but was in the camp of "hope gitlab
>> comes up with a way to make this easy for us".. but as far as fallback
>> plan, converting trees with fewer outstanding MRs first seems like a
>> pretty good idea so solid +1 for that
>
>
> If you read enough off the things, you'll see that Jordan wrote a python 
> script that re-targets all the open MRs so that's not a manual process. It's 
> not a GitLab-sanctioned solution but it's the next best thing. The one 
> downside is that all the MRs will get their last updated timestamp reset but 
> that seems like a pretty small price to pay.
>

yeah, I meant to convert a repo w/ more MRs than 7 but less than mesa
using the script to beta test that, wasn't suggesting to do it by hand

BR,
-R

> Jordan, is there any way you can make the script sort by last updated before 
> it re-targets the MRs so they at least stay in the same order? Updating them 
> in MR # order wouldn't be bad either, I guess.
>
> --Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Rename "master" branch to "main"?

[Rob Clark]

On Wed, Mar 24, 2021 at 3:52 PM Jordan Justen  wrote:
>
> On 2021-03-23 09:38:59, Eric Anholt wrote:
> > On Tue, Mar 23, 2021 at 7:02 AM Jason Ekstrand  wrote:
> > >
> > > Trying to pick this discussion back up.  Daniel Stone thinks it's a
> > > half hour of API bashing to retarget all the MRs so, if the fd.o
> > > admins have some heads up, it should be tractable.  Should we do this
> > > right after branching 21.1 along with the LTS branch?
> >
> > +1
>
> Jason,
>
> I opened a related Mesa issue:
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/4501
>
> I made this change in crucible, and used a script to update the 7 MR
> target branches:
> https://gitlab.freedesktop.org/mesa/crucible/-/issues/5
>
> As mentioned in the Mesa issue, I think we should use piglit as
> another test run before changing Mesa:
> https://gitlab.freedesktop.org/mesa/piglit/-/issues/50
>
> Piglit currently has 60 open merge requests.

I'm in favor of branch rename, but was in the camp of "hope gitlab
comes up with a way to make this easy for us".. but as far as fallback
plan, converting trees with fewer outstanding MRs first seems like a
pretty good idea so solid +1 for that

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

Re: [Mesa-dev] [RFC] Concrete proposal to split classic

[Rob Clark]

On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker  wrote:
>
> Hi list,
>
> We've talked about it a number of times, but I think it's time time to
> discuss splitting the classic drivers off of the main development branch
> again, although this time I have a concrete plan for how this would
> work.
>
> First, why? Basically, all of the classic drivers are in maintanence
> mode (even i965). Second, many of them rely on code that no one works
> on, and very few people still understand. There is no CI for most of
> them, and the Intel CI is not integrated with gitlab, so it's easy to
> unintentionally break them, and this breakage usually isn't noticed
> until just before or just after a release. 21.0 was held up (in small
> part, also me just getting behind) because of such breakages.
>
> I konw there is some interest in getting i915g in good enough shape that
> it could replace i915c, at least for the common case. I also am aware
> that Dave, Ilia, and Eric (with some pointers from Ken) have been
> working on a gallium driver to replace i965. Neither of those things are
> ready yet, but I've taken them into account.
>
> Here's the plan:
>
> 1) 21.1 release happens
> 2) we remove classic from master
> 3) 21.1 reaches EOL because of 21.2
> 4) we fork the 21.1 branch into a "classic-lts"¹ branch
> 5) we disable all vulkan and gallium drivers in said branch, at least at
>the Meson level

I'm +1 for the -lts branch.. the layering between mesa "classic" and
gallium is already starting to get poked thru in the name of
performance, and we've already discovered cases of classic drivers
being broken for multiple months with no one noticing.  I think a
slower moving -lts branch is the best approach to keeping things
working for folks with older hw.

But possibly there is some value in not completely disabling gallium
completely in the -lts branch.  We do have some older gallium drivers
which do not have CI coverage and I think are not used frequently by
developers who are tracking the latest main/master branch.  I'm not
suggesting that we remove them from the main (non-lts) branch but it
might be useful to be able to recommend users of those drivers stick
with the -lts version for better stability?

BR,
-R

> 6) We change the name and precidence of the glvnd loader file
> 7) apply any build fixups (turn of intel generators for versions >= 7.5,
>for example
> 8) maintain that branch with build and critical bug fixes only
>
> This gives ditros and end users two options.
> 1) then can build *only* the legacy branch in the a normal Mesa provides
>libGL interfaces fashion
> 2) They can use glvnd and install current mesa and the legacy branch in
>parallel
>
> Because of glvnd, we can control which driver will get loaded first, and
> thus if we decide i915g or the i965 replacement is ready and turn it on
> by default it will be loaded by default. An end user who doesn't like
> this can add a new glvnd loader file that makes the classic drivers
> higher precident and continue to use them.
>
> Why fork from 21.1 instead of master?
>
> First, it allows us to delete classic immediately, which will allow
> refactoring to happen earlier in the cycle, and for any fallout to be
> caught and hopefully fixed before the release. Second, it means that
> when a user is switched from 21.1 to the new classic-lts branch, there
> will be no regressions, and no one has to spend time figuring out what
> broke and fixing the lts branch.
>
> When you say "build and critical bug fixes", what do you mean?
>
> I mean update Meson if we rely on something that in the future is
> deprecated and removed, and would prevent building the branch or an
> relying on some compiler behavior that changes, gaping exploitable
> security holes, that kind of thing.
>
> footnotes
> ¹Or whatever color you like your 
> bikeshed___
> 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] Perfetto CPU/GPU tracing

[Rob Clark]

On Thu, Feb 18, 2021 at 8:00 AM Rob Clark  wrote:
>
> On Thu, Feb 18, 2021 at 5:35 AM Tamminen, Eero T
>  wrote:
> >
> > Hi,
> >
> > On Thu, 2021-02-18 at 12:17 +0100, Primiano Tucci wrote:
> > [discussion about Perfetto itself]
> > ...
> > > eero.t.tamminen@
> > > from in common Linux distro repos.
> > >
> > > That's right. I am aware of the problem. The plan is to address it
> > > with
> > > bit.ly/perfetto-debian as a starter.
> >
> > Glad to hear something is planned for making things easier for distros!
> >
> >
> > > > eero.t.tamminen@
> > > > Just set uprobe for suitable buffer swap function [1], and parse
> > > kernel ftrace events. (paraphrasing for context: "why do we need
> > > instrumentation points? we can't we just use uprobes instead?")
> > >
> > > The problem with uprobes is:
> > > 1. It's linux specific. Perhaps not a big problem for Mesa here, but the
> > > reason why we didn't go there with Perfetto, at least until now, is that
> > > we need to support all major OSes (Linux, CrOS, Android, Windows,
> > > macOS).
> >
> > The main point here is that uprobe works already without any
> > modifications to any libraries (I have script that has been used for FPS
> > tracking of daily 3D stack builds for many years).
> >
> > And other OSes already offer similar functionality.  E.g. DTrace should
> > be available both for Mac & Windows.
> >
>
> So we are talking about a couple different tracing use-cases which
> perfetto provides.. *Maybe* uprobe can work for the instrument the
> code use case that you are talking about, just assuming for the sake
> of argument that the security folks buy into it, etc.. I'm not sure if
> there isn't a race condition if the kernel has to temporarily remap
> text pages r/w or other potential issues I've not thought of?
>
> But that is ignoring important things like gpu traces and perf
> counters.  I kind of think it is informative to look at some of the
> related proto definitions, because they give a sense of what
> information the visualization UI tools can make use of, for example:
>
> https://cs.android.com/android/platform/superproject/+/master:external/perfetto/protos/perfetto/trace/gpu/gpu_render_stage_event.proto
>
> For that, we would need to, from a background thread in the driver
> (well aux/util/u_trace) collect up the logged gpu timestamps after the
> fact and fill in the relevant details for the trace event.  We are
> going to anyways need the perfetto SDK (in the short term, until we
> can switch to C shared lib when it is avail) for that.
>

jfyi, I captured an example perfetto trace from an android phone,
since we don't have all this wired up in mesa.. but it should be
enough to give an idea what is possible with the gpu counters and
render stage traces

https://people.freedesktop.org/~robclark/example.perfetto

It looks like the GPU render stages don't show up in ui.perfetto.dev
(yet?), but you can also open it directly in AGI[1][2] which does also
show the render stages.  The GPU counters show up in both.

[1] https://gpuinspector.dev/
[2] https://github.com/google/agi

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

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

On Thu, Feb 18, 2021 at 7:40 AM Primiano Tucci  wrote:
>
>
>
> On 18/02/2021 14:35, Tamminen, Eero T wrote:
> > Hi,
> >
> > On Thu, 2021-02-18 at 12:17 +0100, Primiano Tucci wrote:
> > [discussion about Perfetto itself]
> > ...
> >> eero.t.tamminen@
> >> from in common Linux distro repos.
> >>



> >
> > At least both Ubuntu and Fedora default kernels have had uprobes built
> > in for *many* years.
> >
> > Up to date Fedora 33 kernel:
> > $ grep UPROBE /boot/config-5.10.15-200.fc33.x86_64
> > CONFIG_ARCH_SUPPORTS_UPROBES=y
> > CONFIG_UPROBES=y
> > CONFIG_UPROBE_EVENTS=y
> >
> > Same on up to date Ubuntu 20.04:
> > $ grep UPROBE /boot/config-5.4.0-65-generic
> > CONFIG_ARCH_SUPPORTS_UPROBES=y
> > CONFIG_UPROBES=y
> > CONFIG_UPROBE_EVENTS=y
> >
>
> Somebody more knowledgeable about CrOS should chime in, but from a
> codesearch, I don't think they are enabled on CrOS:
>
> https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/third_party/kernel/v5.4/arch/x86/configs/chromiumos-jail-vm-x86_64_defconfig;l=254?q=CONFIG_UPROBES%20-%22%23if%22%20-%22obj-%22==chromiumos%2Fchromiumos%2Fcodesearch:src%2Fthird_party%2Fkernel%2Fv5.4%2F

These are *not* enabled in CrOS.. it is possible to build your own
kernel with them enabled (if your device is in dev mode, and rootfs
verification is disabled).. but that completely defeats the purpose of
having something where we can trace production builds and have tools
available for our users

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

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

On Thu, Feb 18, 2021 at 5:35 AM Tamminen, Eero T
 wrote:
>
> Hi,
>
> On Thu, 2021-02-18 at 12:17 +0100, Primiano Tucci wrote:
> [discussion about Perfetto itself]
> ...
> > eero.t.tamminen@
> > from in common Linux distro repos.
> >
> > That's right. I am aware of the problem. The plan is to address it
> > with
> > bit.ly/perfetto-debian as a starter.
>
> Glad to hear something is planned for making things easier for distros!
>
>
> > > eero.t.tamminen@
> > > Just set uprobe for suitable buffer swap function [1], and parse
> > kernel ftrace events. (paraphrasing for context: "why do we need
> > instrumentation points? we can't we just use uprobes instead?")
> >
> > The problem with uprobes is:
> > 1. It's linux specific. Perhaps not a big problem for Mesa here, but the
> > reason why we didn't go there with Perfetto, at least until now, is that
> > we need to support all major OSes (Linux, CrOS, Android, Windows,
> > macOS).
>
> The main point here is that uprobe works already without any
> modifications to any libraries (I have script that has been used for FPS
> tracking of daily 3D stack builds for many years).
>
> And other OSes already offer similar functionality.  E.g. DTrace should
> be available both for Mac & Windows.
>

So we are talking about a couple different tracing use-cases which
perfetto provides.. *Maybe* uprobe can work for the instrument the
code use case that you are talking about, just assuming for the sake
of argument that the security folks buy into it, etc.. I'm not sure if
there isn't a race condition if the kernel has to temporarily remap
text pages r/w or other potential issues I've not thought of?

But that is ignoring important things like gpu traces and perf
counters.  I kind of think it is informative to look at some of the
related proto definitions, because they give a sense of what
information the visualization UI tools can make use of, for example:

https://cs.android.com/android/platform/superproject/+/master:external/perfetto/protos/perfetto/trace/gpu/gpu_render_stage_event.proto

For that, we would need to, from a background thread in the driver
(well aux/util/u_trace) collect up the logged gpu timestamps after the
fact and fill in the relevant details for the trace event.  We are
going to anyways need the perfetto SDK (in the short term, until we
can switch to C shared lib when it is avail) for that.

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

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

So, I did an experiment to get a feel for how hard/easy updating
perfetto sdk would be.. I took gfx-pps (which already "vendors" the
perfetto sdk) and rebuilt it with perfetto.cc/h from each existing
perfetto release tag (v3.0 is the earliest I see, v12.1 is the
latest).  I did hack out the intel backend due to missing i915-perf
dependency (which I guess is a problem that would go away if this was
all just pulled into mesa).. but kept the panfrost backend.  I ran
into no issues rebuilding with each different perfetto SDK version.

So that gives some sense that at least the API is stable, and we
aren't signing up for huge pain when we need to update perfetto SDK.

That said, I'm ok with making perfetto support a build-time option
that is default disabled.  And I think it would be even ok to limit
use of perfetto to individual drivers (ie. no core mesa/gallium
perfetto dependency) to start.  And, well, CrOS has plenty of mesa
contributors so I think you can consider us signed up to maintain
this.

(I do think perfetto has something to offer linux distro users as
well, but we can take this one step at time.)

BR,
-R

On Fri, Feb 12, 2021 at 5:51 PM Dylan Baker  wrote:
>
> So, we're vendoring something that we know getting bug fixes for will be an 
> enormous pile of work? That sounds like a really bad idea.
>
> On Fri, Feb 12, 2021, at 17:51, Rob Clark wrote:
> > On Fri, Feb 12, 2021 at 5:35 PM Dylan Baker  wrote:
> > >
> > >
> > >
> > > On Fri, Feb 12, 2021, at 16:36, Rob Clark wrote:
> > > > On Thu, Feb 11, 2021 at 5:40 PM John Bates  wrote:
> > > > >
> > > >
> > > > 
> > > >
> > > > > Runtime Characteristics
> > > > >
> > > > > ~500KB additional binary size. Even with using only the basic 
> > > > > features of perfetto, it will increase the binary size of mesa by 
> > > > > about 500KB.
> > > >
> > > > IMHO, that size is negligible.. looking at freedreno, a mesa build
> > > > *only* enabling freedreno is already ~6MB.. distros typically use
> > > > "megadriver" (ie. all the drivers linked into a single .so with hard
> > > > links for the different  ${driver}_dri.so), which on my fedora laptop
> > > > is ~21M.  Maybe if anything is relevant it is how much of that
> > > > actually gets paged into RAM from disk, but I think 500K isn't a thing
> > > > to worry about too much.
> > > >
> > > > > Background thread. Perfetto uses a background thread for 
> > > > > communication with the system tracing daemon (traced) to advertise 
> > > > > trace data and get notification of trace start/stop.
> > > >
> > > > Mesa already tends to have plenty of threads.. some of that depends on
> > > > the driver, I think currently radeonsi is the threading king, but
> > > > there are several other drivers working on threaded_context and async
> > > > compile thread pool.
> > > >
> > > > It is worth mentioning that, AFAIU, perfetto can operate in
> > > > self-server mode, which seems like it would be useful for distros
> > > > which do not have the system daemon.  I'm not sure if we lose that
> > > > with percetto?
> > > >
> > > > > Runtime overhead when disabled is designed to be optimal with one 
> > > > > predicted branch, typically a few CPU cycles per event. While 
> > > > > enabled, the overhead can be around 1 us per event.
> > > > >
> > > > > Integration Challenges
> > > > >
> > > > > The perfetto SDK is C++ and designed around macros, lambdas, inline 
> > > > > templates, etc. There are ongoing discussions on providing an 
> > > > > official perfetto C API, but it is not yet clear when this will land 
> > > > > on the perfetto roadmap.
> > > > > The perfetto SDK is an amalgamated .h and .cc that adds up to 100K 
> > > > > lines of code.
> > > > > Anything that includes perfetto.h takes a long time to compile.
> > > > > The current Perfetto SDK design is incompatible with being a shared 
> > > > > library behind a C API.
> > > >
> > > > So, C++ on it's own isn't a showstopper, mesa has plenty of C++ code.
> > > > But maybe we should verify that MSVC is happy with it, otherwise we
> > > > need to take a bit more care in some parts of the codebase.
> > > >
> > > > As far as compile time, I wonder if we can regenerate the .cc/.h with
> 

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

On Mon, Feb 15, 2021 at 3:13 AM Tamminen, Eero T
 wrote:
>
> Hi,
>
> On Fri, 2021-02-12 at 18:20 -0800, Rob Clark wrote:
> > On Fri, Feb 12, 2021 at 5:56 PM Lionel Landwerlin
> >  wrote:
> ...
> > > In our implementation that precision (in particular when a drawcall
> > > ends) comes at a stalling cost unfortunately.
> >
> > yeah, stalling on our end too for per-draw counter snapshots.. but if
> > you are looking for which shaders to optimize that doesn't matter
> > *that* much.. they'll be some overhead, but it's not really going to
> > change which draws/shaders are expensive.. just mean that you lose out
> > on pipelining of the state changes
>
> I don't think it makes sense to try doing this all in one step.
>
> Unless one has resources of Google + commitment for maintaining it, I
> think doing those steps with separate, dedicated tools can be better fit
> for Open Source than trying to maintain a monster that tries to do
> everything of analyzing:
> - whether performance issue is on GPU side, CPU side, or code being too
> synchronous
> - where the bottlenecks are on GPU side
> - where the bottlenecks are on CPU side
> - what are the sync points

I mean, google has a team working on perfetto, so we kinda are getting
the tool here for free, all we need to do here is instrumentation for
the mesa part of the system..

Currently, if you look at
https://chromeos.dev/en/games/optimizing-games-profiling the
recommendation basically amounts to "optimize on android with
snapdragon profiler/etc".. which is really not a great look for mesa.
(And doesn't do anything for intel at all.)  Mesa is a great project,
but profiling tooling, especially something for people other than mesa
developers, is a glaring weakness.  Perfetto looks like a great
opportunity to fix that, not only for ourselves but also game
developers and others.

BR,
-R

> IMHO:
> - Overall picture should not have too many details, because otherwise
> one can start chasing irrelevancies [1]
> - Rest of analysis works better when one concentrate on one performance
> aspect (shown by the overall picture) at the time.  So that activity
> could have tool dedicated for that purpose
>
>
> - Eero
>
> [1] Unless one has HW assisted tool that really can tell *everything*
> like ARM ETM and Intel PT with *really good* post-processing &
> visualization tooling.  I don't think are usable outside of large
> companies though because of HW requirements and using them taking a lot
> of time / expertise (1 sec trace is gigs of data).
>
> PS. For checking on shader compiles, I've used two steps:
> * script to trace frame updates & shader compiles (with ftrace uprobe on
> appropriate function entry points) + monitor CPU usage & GPU usage (for
> GPU, freq or power usage is enough)
>   -> shows whether FPS & GPU utilization dip with compiles.  Frame
> updates & compiles are rare enough that ftrace overhead doesn't matter
>
> * enable Mesa shader debugging, because in next step one wants to know
> what shaders they are and how they're compiled
>
> ___
> 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] Perfetto CPU/GPU tracing

[Rob Clark]

On Sat, Feb 13, 2021 at 12:52 PM Lionel Landwerlin
 wrote:
>
> On 13/02/2021 18:52, Rob Clark wrote:
> > On Sat, Feb 13, 2021 at 12:04 AM Lionel Landwerlin
> >  wrote:
> >> On 13/02/2021 04:20, Rob Clark wrote:
> >>> On Fri, Feb 12, 2021 at 5:56 PM Lionel Landwerlin
> >>>  wrote:
> >>>> On 13/02/2021 03:38, Rob Clark wrote:
> >>>>> On Fri, Feb 12, 2021 at 5:08 PM Lionel Landwerlin
> >>>>>  wrote:
> >>>>>> We're kind of in the same boat for Intel.
> >>>>>>
> >>>>>> Access to GPU perf counters is exclusive to a single process if you 
> >>>>>> want
> >>>>>> to build a timeline of the work (because preemption etc...).
> >>>>> ugg, does that mean extensions like AMD_performance_monitor doesn't
> >>>>> actually work on intel?
> >>>> It work,s but only a single app can use it at a time.
> >>>>
> >>> I see.. on the freedreno side we haven't really gone down the
> >>> preemption route yet, but we have a way to hook in some safe/restore
> >>> cmdstream
> >>
> >> That's why I think, for Intel HW, something like gfx-pps is probably
> >> best to pull out all the data on a timeline for the entire system.
> >>
> >> Then the drivers could just provide timestamp on the timeline to
> >> annotate it.
> >>
> > Looking at gfx-pps, my question is why is this not part of the mesa
> > tree?  That way I could use it for freedreno (either as stand-alone
> > process or part of driver) without duplicating all the perfcntr
> > tables, and information about different variants of a given generation
> > needed to interpret the raw counters into something useful for a
> > human.
> >
> > Pulling gfx-pps into mesa seems like a sensible way forward.
> >
> > BR,
> > -R
>
> Yeah, I guess it depends on how your stack looks.
>
> If the counters cover more than 3d and you have video drivers out of the
> mesa tree, it might make sense to have it somewhere else.

Pulling intel video drivers into mesa and bringing some sanity to that
side of things would make more than a few people happy (but I digress
;-))

Until then, exporting a library from the mesa build might be an
option?  And possibly something like that would work for virgl host
side stuff as well?

> Anyway I didn't want to sound negative, having a daemon like gfx-pps
> thing in mesa to report system wide counters works for me :)

yeah, I think having it in the mesa tree is good for code-reuse (from
my experience, pulling external freedreno related tools into mesa
turned out to be a good thing)

At some point, whether the collection is in-process or not could just
be an implementation detail

BR,
-R

> Then we can look into how to have each intel driver add annotation on
> the timeline.
>
>
> -Lionel
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

On Sat, Feb 13, 2021 at 12:04 AM Lionel Landwerlin
 wrote:
>
> On 13/02/2021 04:20, Rob Clark wrote:
> > On Fri, Feb 12, 2021 at 5:56 PM Lionel Landwerlin
> >  wrote:
> >> On 13/02/2021 03:38, Rob Clark wrote:
> >>> On Fri, Feb 12, 2021 at 5:08 PM Lionel Landwerlin
> >>>  wrote:
> >>>> We're kind of in the same boat for Intel.
> >>>>
> >>>> Access to GPU perf counters is exclusive to a single process if you want
> >>>> to build a timeline of the work (because preemption etc...).
> >>> ugg, does that mean extensions like AMD_performance_monitor doesn't
> >>> actually work on intel?
> >>
> >> It work,s but only a single app can use it at a time.
> >>
> > I see.. on the freedreno side we haven't really gone down the
> > preemption route yet, but we have a way to hook in some safe/restore
> > cmdstream
>
>
> That's why I think, for Intel HW, something like gfx-pps is probably
> best to pull out all the data on a timeline for the entire system.
>
> Then the drivers could just provide timestamp on the timeline to
> annotate it.
>

Looking at gfx-pps, my question is why is this not part of the mesa
tree?  That way I could use it for freedreno (either as stand-alone
process or part of driver) without duplicating all the perfcntr
tables, and information about different variants of a given generation
needed to interpret the raw counters into something useful for a
human.

Pulling gfx-pps into mesa seems like a sensible way forward.

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

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

A lot of code, which like I said is mostly just generated ser/deser
and not very interesting.. and 90% of it we won't use (unless mesa
becomes a wifi driver, and more or less the rest of an OS).  And if
there is a need to update it, we update it.. it's two files.  But *if*
there are any API changes, we can deal with that in the same commit.
I'm not saying it is great.. just that it is least bad.

I completely understand the argument against vendoring.. and I also
completely understand the argument against tilting at windmills ;-)

BR,
-R

On Fri, Feb 12, 2021 at 6:15 PM Dylan Baker  wrote:
>
> I can't speak for anyone else, but a giant pile of vendored code that you're 
> expected to not update seems like a really bad idea to me.
>
> On Fri, Feb 12, 2021, at 18:09, Rob Clark wrote:
> > I'm not really sure that is a fair statement.. the work scales
> > according to the API change (which I'm not really sure if it changes
> > much other than adding things).. if the API doesn't change, it is not
> > really any effort to update two files in mesa git.
> >
> > As far as bug fixes.. it is a lot of code, but seems like the largest
> > part of it is just generated protobuf serialization/deserialization
> > code, rather than anything interesting.
> >
> > And again, I'm not a fan of their approach of "just vendor it".. but
> > it is how perfetto is intended to be used, and in this case it seems
> > like the best approach, since it is a situation where the protocol is
> > the point of abi stability.
> >
> > BR,
> > -R
> >
> > On Fri, Feb 12, 2021 at 5:51 PM Dylan Baker  wrote:
> > >
> > > So, we're vendoring something that we know getting bug fixes for will be 
> > > an enormous pile of work? That sounds like a really bad idea.
> > >
> > > On Fri, Feb 12, 2021, at 17:51, Rob Clark wrote:
> > > > On Fri, Feb 12, 2021 at 5:35 PM Dylan Baker  wrote:
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Feb 12, 2021, at 16:36, Rob Clark wrote:
> > > > > > On Thu, Feb 11, 2021 at 5:40 PM John Bates  
> > > > > > wrote:
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > > Runtime Characteristics
> > > > > > >
> > > > > > > ~500KB additional binary size. Even with using only the basic 
> > > > > > > features of perfetto, it will increase the binary size of mesa by 
> > > > > > > about 500KB.
> > > > > >
> > > > > > IMHO, that size is negligible.. looking at freedreno, a mesa build
> > > > > > *only* enabling freedreno is already ~6MB.. distros typically use
> > > > > > "megadriver" (ie. all the drivers linked into a single .so with hard
> > > > > > links for the different  ${driver}_dri.so), which on my fedora 
> > > > > > laptop
> > > > > > is ~21M.  Maybe if anything is relevant it is how much of that
> > > > > > actually gets paged into RAM from disk, but I think 500K isn't a 
> > > > > > thing
> > > > > > to worry about too much.
> > > > > >
> > > > > > > Background thread. Perfetto uses a background thread for 
> > > > > > > communication with the system tracing daemon (traced) to 
> > > > > > > advertise trace data and get notification of trace start/stop.
> > > > > >
> > > > > > Mesa already tends to have plenty of threads.. some of that depends 
> > > > > > on
> > > > > > the driver, I think currently radeonsi is the threading king, but
> > > > > > there are several other drivers working on threaded_context and 
> > > > > > async
> > > > > > compile thread pool.
> > > > > >
> > > > > > It is worth mentioning that, AFAIU, perfetto can operate in
> > > > > > self-server mode, which seems like it would be useful for distros
> > > > > > which do not have the system daemon.  I'm not sure if we lose that
> > > > > > with percetto?
> > > > > >
> > > > > > > Runtime overhead when disabled is designed to be optimal with one 
> > > > > > > predicted branch, typically a few CPU cycles per event. While 
> > > > > > > enabled, the overhead can be around 1 us per event.
> > > > > > >

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

On Fri, Feb 12, 2021 at 5:56 PM Lionel Landwerlin
 wrote:
>
> On 13/02/2021 03:38, Rob Clark wrote:
> > On Fri, Feb 12, 2021 at 5:08 PM Lionel Landwerlin
> >  wrote:
> >> We're kind of in the same boat for Intel.
> >>
> >> Access to GPU perf counters is exclusive to a single process if you want
> >> to build a timeline of the work (because preemption etc...).
> > ugg, does that mean extensions like AMD_performance_monitor doesn't
> > actually work on intel?
>
>
> It work,s but only a single app can use it at a time.
>

I see.. on the freedreno side we haven't really gone down the
preemption route yet, but we have a way to hook in some safe/restore
cmdstream

>
> >
> >> The best information we could add from mesa would a timestamp of when a
> >> particular drawcall started.
> >> But that's pretty much when timestamps queries are.
> >>
> >> Were you thinking of particular GPU generated data you don't get from
> >> gfx-pps?
> > >From the looks of it, currently I don't get *any* GPU generated data
> > from gfx-pps ;-)
>
>
> Maybe file a bug? :
> https://gitlab.freedesktop.org/Fahien/gfx-pps/-/blob/master/src/gpu/intel/intel_driver.cc
>
>
> >
> > We can ofc sample counters from a separate process as well... I have a
> > curses tool (fdperf) which does this.. but running outside of gpu
> > cmdstream plus counters losing context across suspend/resume makes it
> > less than perfect.
>
>
> Our counters are global so to give per application values, we need to
> post process a stream of HW counter snapshots.
>
>
> >And something that works the same way as
> > AMD_performance_monitor under the hook gives a more precise look at
> > which shaders (for ex) are consuming the most cycles.
>
>
> In our implementation that precision (in particular when a drawcall
> ends) comes at a stalling cost unfortunately.

yeah, stalling on our end too for per-draw counter snapshots.. but if
you are looking for which shaders to optimize that doesn't matter
*that* much.. they'll be some overhead, but it's not really going to
change which draws/shaders are expensive.. just mean that you lose out
on pipelining of the state changes

BR,
-R

>
> >For cases where
> > we can profile a trace, frameretrace and related tools is pretty
> > great.. but it would be nice to have similar visibility for actual
> > games (which for me, mostly means android games, since so far no
> > aarch64 steam store), but also give game developers good tools (or at
> > least the same tools that they get with other closed src drivers on
> > android).
>
>
> Sure, but frame analysis is different than live monitoring of the system.
>
> On Intel's HW you don't get the same level of details in both cases, and
> apart for a few timestamps, I think gfx-pps is as good as you gonna get
> for live stuff.
>
>
> -Lionel
>
>
> >
> > BR,
> > -R
> >
> >> Thanks,
> >>
> >> -Lionel
> >>
> >>
> >> On 13/02/2021 00:12, Alyssa Rosenzweig wrote:
> >>> My 2c for Mali/Panfrost --
> >>>
> >>> For us, capturing GPU perf counters is orthogonal to rendering. It's
> >>> expected (e.g. with Arm's tools) to do this from a separate process.
> >>> Neither Mesa nor the DDK should require custom instrumentation for the
> >>> low-level data. Fahien's gfx-pps handles this correctly for Panfrost +
> >>> Perfetto as it is. So for us I don't see the value in modifying Mesa for
> >>> tracing.
> >>>
> >>> On Fri, Feb 12, 2021 at 01:34:51PM -0800, John Bates wrote:
> >>>> (responding from correct address this time)
> >>>>
> >>>> On Fri, Feb 12, 2021 at 12:03 PM Mark Janes  
> >>>> wrote:
> >>>>
> >>>>> I've recently been using GPUVis to look at trace events.  On Intel
> >>>>> platforms, GPUVis incorporates ftrace events from the i915 driver,
> >>>>> performance metrics from igt-gpu-tools, and userspace ftrace markers
> >>>>> that I locally hack up in Mesa.
> >>>>>
> >>>> GPUVis is great. I would love to see that data combined with
> >>>> userspace events without any need for local hacks. Perfetto provides
> >>>> on-demand trace events with lower overhead compared to ftrace, so for
> >>>> example it is acceptable to have production trace instrumentation that 
> >>>> can
> >>>> be captured without dev builds. To d

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

I'm not really sure that is a fair statement.. the work scales
according to the API change (which I'm not really sure if it changes
much other than adding things).. if the API doesn't change, it is not
really any effort to update two files in mesa git.

As far as bug fixes.. it is a lot of code, but seems like the largest
part of it is just generated protobuf serialization/deserialization
code, rather than anything interesting.

And again, I'm not a fan of their approach of "just vendor it".. but
it is how perfetto is intended to be used, and in this case it seems
like the best approach, since it is a situation where the protocol is
the point of abi stability.

BR,
-R

On Fri, Feb 12, 2021 at 5:51 PM Dylan Baker  wrote:
>
> So, we're vendoring something that we know getting bug fixes for will be an 
> enormous pile of work? That sounds like a really bad idea.
>
> On Fri, Feb 12, 2021, at 17:51, Rob Clark wrote:
> > On Fri, Feb 12, 2021 at 5:35 PM Dylan Baker  wrote:
> > >
> > >
> > >
> > > On Fri, Feb 12, 2021, at 16:36, Rob Clark wrote:
> > > > On Thu, Feb 11, 2021 at 5:40 PM John Bates  wrote:
> > > > >
> > > >
> > > > 
> > > >
> > > > > Runtime Characteristics
> > > > >
> > > > > ~500KB additional binary size. Even with using only the basic 
> > > > > features of perfetto, it will increase the binary size of mesa by 
> > > > > about 500KB.
> > > >
> > > > IMHO, that size is negligible.. looking at freedreno, a mesa build
> > > > *only* enabling freedreno is already ~6MB.. distros typically use
> > > > "megadriver" (ie. all the drivers linked into a single .so with hard
> > > > links for the different  ${driver}_dri.so), which on my fedora laptop
> > > > is ~21M.  Maybe if anything is relevant it is how much of that
> > > > actually gets paged into RAM from disk, but I think 500K isn't a thing
> > > > to worry about too much.
> > > >
> > > > > Background thread. Perfetto uses a background thread for 
> > > > > communication with the system tracing daemon (traced) to advertise 
> > > > > trace data and get notification of trace start/stop.
> > > >
> > > > Mesa already tends to have plenty of threads.. some of that depends on
> > > > the driver, I think currently radeonsi is the threading king, but
> > > > there are several other drivers working on threaded_context and async
> > > > compile thread pool.
> > > >
> > > > It is worth mentioning that, AFAIU, perfetto can operate in
> > > > self-server mode, which seems like it would be useful for distros
> > > > which do not have the system daemon.  I'm not sure if we lose that
> > > > with percetto?
> > > >
> > > > > Runtime overhead when disabled is designed to be optimal with one 
> > > > > predicted branch, typically a few CPU cycles per event. While 
> > > > > enabled, the overhead can be around 1 us per event.
> > > > >
> > > > > Integration Challenges
> > > > >
> > > > > The perfetto SDK is C++ and designed around macros, lambdas, inline 
> > > > > templates, etc. There are ongoing discussions on providing an 
> > > > > official perfetto C API, but it is not yet clear when this will land 
> > > > > on the perfetto roadmap.
> > > > > The perfetto SDK is an amalgamated .h and .cc that adds up to 100K 
> > > > > lines of code.
> > > > > Anything that includes perfetto.h takes a long time to compile.
> > > > > The current Perfetto SDK design is incompatible with being a shared 
> > > > > library behind a C API.
> > > >
> > > > So, C++ on it's own isn't a showstopper, mesa has plenty of C++ code.
> > > > But maybe we should verify that MSVC is happy with it, otherwise we
> > > > need to take a bit more care in some parts of the codebase.
> > > >
> > > > As far as compile time, I wonder if we can regenerate the .cc/.h with
> > > > only the gpu trace parts?  But I wouldn't expect the .h to be
> > > > something widely included.  For example, for gpu timeline traces in
> > > > freedreno, I'm expecting it to look like a freedreno_perfetto.cc with
> > > > extern "C" {} around the callbacks that would hook into the
> > > > u_tracepoint tracepoints.  That one file would pull in the perfetto
> > > > .h,

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

On Fri, Feb 12, 2021 at 5:40 PM John Bates  wrote:
>
>
>
> On Fri, Feb 12, 2021 at 4:34 PM Rob Clark  wrote:
>>
>> On Thu, Feb 11, 2021 at 5:40 PM John Bates  wrote:
>> >
>>
>> 
>>
>> > Runtime Characteristics
>> >
>> > ~500KB additional binary size. Even with using only the basic features of 
>> > perfetto, it will increase the binary size of mesa by about 500KB.
>>
>> IMHO, that size is negligible.. looking at freedreno, a mesa build
>> *only* enabling freedreno is already ~6MB.. distros typically use
>> "megadriver" (ie. all the drivers linked into a single .so with hard
>> links for the different  ${driver}_dri.so), which on my fedora laptop
>> is ~21M.  Maybe if anything is relevant it is how much of that
>> actually gets paged into RAM from disk, but I think 500K isn't a thing
>> to worry about too much.
>>
>> > Background thread. Perfetto uses a background thread for communication 
>> > with the system tracing daemon (traced) to advertise trace data and get 
>> > notification of trace start/stop.
>>
>> Mesa already tends to have plenty of threads.. some of that depends on
>> the driver, I think currently radeonsi is the threading king, but
>> there are several other drivers working on threaded_context and async
>> compile thread pool.
>>
>> It is worth mentioning that, AFAIU, perfetto can operate in
>> self-server mode, which seems like it would be useful for distros
>> which do not have the system daemon.  I'm not sure if we lose that
>> with percetto?
>
>
> Easy to add, but want to avoid a runtime arg because it would add ~300KB to 
> binary size. Okay if we have an alternate init function though.

I think I could imagine wanting mesa build params to control whether
we want self-server or system-server mode.. ie. if some distros add
system-server support they wouldn't need self-server mode and visa
versa

>
>>
>>
>> > Runtime overhead when disabled is designed to be optimal with one 
>> > predicted branch, typically a few CPU cycles per event. While enabled, the 
>> > overhead can be around 1 us per event.
>> >
>> > Integration Challenges
>> >
>> > The perfetto SDK is C++ and designed around macros, lambdas, inline 
>> > templates, etc. There are ongoing discussions on providing an official 
>> > perfetto C API, but it is not yet clear when this will land on the 
>> > perfetto roadmap.
>> > The perfetto SDK is an amalgamated .h and .cc that adds up to 100K lines 
>> > of code.
>> > Anything that includes perfetto.h takes a long time to compile.
>> > The current Perfetto SDK design is incompatible with being a shared 
>> > library behind a C API.
>>
>> So, C++ on it's own isn't a showstopper, mesa has plenty of C++ code.
>> But maybe we should verify that MSVC is happy with it, otherwise we
>> need to take a bit more care in some parts of the codebase.
>>
>> As far as compile time, I wonder if we can regenerate the .cc/.h with
>> only the gpu trace parts?  But I wouldn't expect the .h to be
>> something widely included.  For example, for gpu timeline traces in
>> freedreno, I'm expecting it to look like a freedreno_perfetto.cc with
>> extern "C" {} around the callbacks that would hook into the
>> u_tracepoint tracepoints.  That one file would pull in the perfetto
>> .h, and we'd just not build that file if perfetto was disabled.
>
>
> That works for GPU, but I'd like to see some slow CPU functions in traces as 
> well to help reason about performance problems. This ends up peppering the 
> trace header in lots of places.

My point was that we could strip out a whole lot of stuff that is
completely unrelated to mesa.. not sure if it is worth bothering with,
I doubt we'd #include perfetto.h very widely

>> Overall having to add our own extern C wrappers in some places doesn't
>> seem like the *end* of the world.. a bit annoying, but we might end up
>> doing that regardless if other folks want the ability to hook in
>> something other than perfetto?
>
>
> It's more than extern C wrappers if we want to minimize overhead while 
> tracing enabled at compile time. Have a look at percetto.h/cc.

I'm not sure how many distros are not using LTO these days.. I assume
once you have LTO it doesn't really matter anymore?

>>
>>
>> 
>>
>> > Mesa Integration Alternatives
>>
>> I'm kind of leaning towards the "just slurp in the .cc/.h" approach..
>> that is mostly because I expect to initially just add some basic gpu
>> time

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

On Fri, Feb 12, 2021 at 5:35 PM Dylan Baker  wrote:
>
>
>
> On Fri, Feb 12, 2021, at 16:36, Rob Clark wrote:
> > On Thu, Feb 11, 2021 at 5:40 PM John Bates  wrote:
> > >
> >
> > 
> >
> > > Runtime Characteristics
> > >
> > > ~500KB additional binary size. Even with using only the basic features of 
> > > perfetto, it will increase the binary size of mesa by about 500KB.
> >
> > IMHO, that size is negligible.. looking at freedreno, a mesa build
> > *only* enabling freedreno is already ~6MB.. distros typically use
> > "megadriver" (ie. all the drivers linked into a single .so with hard
> > links for the different  ${driver}_dri.so), which on my fedora laptop
> > is ~21M.  Maybe if anything is relevant it is how much of that
> > actually gets paged into RAM from disk, but I think 500K isn't a thing
> > to worry about too much.
> >
> > > Background thread. Perfetto uses a background thread for communication 
> > > with the system tracing daemon (traced) to advertise trace data and get 
> > > notification of trace start/stop.
> >
> > Mesa already tends to have plenty of threads.. some of that depends on
> > the driver, I think currently radeonsi is the threading king, but
> > there are several other drivers working on threaded_context and async
> > compile thread pool.
> >
> > It is worth mentioning that, AFAIU, perfetto can operate in
> > self-server mode, which seems like it would be useful for distros
> > which do not have the system daemon.  I'm not sure if we lose that
> > with percetto?
> >
> > > Runtime overhead when disabled is designed to be optimal with one 
> > > predicted branch, typically a few CPU cycles per event. While enabled, 
> > > the overhead can be around 1 us per event.
> > >
> > > Integration Challenges
> > >
> > > The perfetto SDK is C++ and designed around macros, lambdas, inline 
> > > templates, etc. There are ongoing discussions on providing an official 
> > > perfetto C API, but it is not yet clear when this will land on the 
> > > perfetto roadmap.
> > > The perfetto SDK is an amalgamated .h and .cc that adds up to 100K lines 
> > > of code.
> > > Anything that includes perfetto.h takes a long time to compile.
> > > The current Perfetto SDK design is incompatible with being a shared 
> > > library behind a C API.
> >
> > So, C++ on it's own isn't a showstopper, mesa has plenty of C++ code.
> > But maybe we should verify that MSVC is happy with it, otherwise we
> > need to take a bit more care in some parts of the codebase.
> >
> > As far as compile time, I wonder if we can regenerate the .cc/.h with
> > only the gpu trace parts?  But I wouldn't expect the .h to be
> > something widely included.  For example, for gpu timeline traces in
> > freedreno, I'm expecting it to look like a freedreno_perfetto.cc with
> > extern "C" {} around the callbacks that would hook into the
> > u_tracepoint tracepoints.  That one file would pull in the perfetto
> > .h, and we'd just not build that file if perfetto was disabled.
> >
> > Overall having to add our own extern C wrappers in some places doesn't
> > seem like the *end* of the world.. a bit annoying, but we might end up
> > doing that regardless if other folks want the ability to hook in
> > something other than perfetto?
> >
> > 
> >
> > > Mesa Integration Alternatives
> >
> > I'm kind of leaning towards the "just slurp in the .cc/.h" approach..
> > that is mostly because I expect to initially just add some basic gpu
> > timeline tracepoints, but over time iterate on adding more.. it would
> > be nice to not have to depend on a newer version of an external
> > library at each step.  That is ofc only my $0.02..
> >
> > BR,
> > -R
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>
>
> My experience is that vendoring just ends up being a huge pain for everyone, 
> especially if the ui code stops working with our forked version, and we have 
> to rebase all of our changes on upstream.
>
> Could we add meson build files and use a wrap for this if the distro doesn't 
> ship the library? Id be willing to do/help with an initial port if that's 
> what we wanted to do. But since this really a dev dependency i don't see why 
> using a wrap would be a big deal.

I'm not a super huge fan of the perfetto approach of "just import the
library", but at the end of the day the point of ABI compatibility is
the protocol, not the API.. so it is actually safer to import the
library into mesa's git tree

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

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

On Fri, Feb 12, 2021 at 5:08 PM Lionel Landwerlin
 wrote:
>
> We're kind of in the same boat for Intel.
>
> Access to GPU perf counters is exclusive to a single process if you want
> to build a timeline of the work (because preemption etc...).

ugg, does that mean extensions like AMD_performance_monitor doesn't
actually work on intel?

> The best information we could add from mesa would a timestamp of when a
> particular drawcall started.
> But that's pretty much when timestamps queries are.
>
> Were you thinking of particular GPU generated data you don't get from
> gfx-pps?

From the looks of it, currently I don't get *any* GPU generated data
from gfx-pps ;-)

We can ofc sample counters from a separate process as well... I have a
curses tool (fdperf) which does this.. but running outside of gpu
cmdstream plus counters losing context across suspend/resume makes it
less than perfect.  And something that works the same way as
AMD_performance_monitor under the hook gives a more precise look at
which shaders (for ex) are consuming the most cycles.  For cases where
we can profile a trace, frameretrace and related tools is pretty
great.. but it would be nice to have similar visibility for actual
games (which for me, mostly means android games, since so far no
aarch64 steam store), but also give game developers good tools (or at
least the same tools that they get with other closed src drivers on
android).

BR,
-R

> Thanks,
>
> -Lionel
>
>
> On 13/02/2021 00:12, Alyssa Rosenzweig wrote:
> > My 2c for Mali/Panfrost --
> >
> > For us, capturing GPU perf counters is orthogonal to rendering. It's
> > expected (e.g. with Arm's tools) to do this from a separate process.
> > Neither Mesa nor the DDK should require custom instrumentation for the
> > low-level data. Fahien's gfx-pps handles this correctly for Panfrost +
> > Perfetto as it is. So for us I don't see the value in modifying Mesa for
> > tracing.
> >
> > On Fri, Feb 12, 2021 at 01:34:51PM -0800, John Bates wrote:
> >> (responding from correct address this time)
> >>
> >> On Fri, Feb 12, 2021 at 12:03 PM Mark Janes  wrote:
> >>
> >>> I've recently been using GPUVis to look at trace events.  On Intel
> >>> platforms, GPUVis incorporates ftrace events from the i915 driver,
> >>> performance metrics from igt-gpu-tools, and userspace ftrace markers
> >>> that I locally hack up in Mesa.
> >>>
> >> GPUVis is great. I would love to see that data combined with
> >> userspace events without any need for local hacks. Perfetto provides
> >> on-demand trace events with lower overhead compared to ftrace, so for
> >> example it is acceptable to have production trace instrumentation that can
> >> be captured without dev builds. To do that with ftrace it may require a way
> >> to enable and disable the ftrace file writes to avoid the overhead when
> >> tracing is not in use. This is what Android does with systrace/atrace, for
> >> example, it uses Binder to notify processes about trace sessions. Perfetto
> >> does that in a more portable way.
> >>
> >>
> >>> It is very easy to compile the GPUVis UI.  Userspace instrumentation
> >>> requires a single C/C++ header.  You don't have to access an external
> >>> web service to analyze trace data (a big no-no for devs working on
> >>> preproduction hardware).
> >>>
> >>> Is it possible to build and run the Perfetto UI locally?
> >>
> >> Yes, local UI builds are possible
> >> .
> >> Also confirmed with the perfetto team  that
> >> trace data is not uploaded unless you use the 'share' feature.
> >>
> >>
> >>>Can it display
> >>> arbitrary trace events that are written to
> >>> /sys/kernel/tracing/trace_marker ?
> >>
> >> Yes, I believe it does support that via linux.ftrace data source
> >> . We use that for
> >> example to overlay CPU sched data to show what process is on each core
> >> throughout the timeline. There are many ftrace event types
> >> 
> >> in
> >> the perfetto protos.
> >>
> >>
> >>> Can it be extended to show i915 and
> >>> i915-perf-recorder events?
> >>>
> >> It can be extended to consume custom data sources. One way this is done is
> >> via a bridge daemon, such as traced_probes which is responsible for
> >> capturing data from ftrace and /proc during a trace session and sending it
> >> to traced. traced is the main perfetto tracing daemon that notifies all
> >> trace data sources to start/stop tracing and communicates with user tracing
> >> requests via the 'perfetto' command.
> >>
> >>
> >>
> >>> John Bates  writes:
> >>>
>  I recently opened issue 4262
>   to begin the
>  discussion on integrating perfetto into mesa.
> 
>  *Background*
> 
>  

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

On Fri, Feb 12, 2021 at 4:51 PM Mark Janes  wrote:
>
> Rob Clark  writes:
>
> > On Fri, Feb 12, 2021 at 5:01 AM Tamminen, Eero T
> >  wrote:
> >>
> >> Hi,
> >>
> >> On Thu, 2021-02-11 at 17:39 -0800, John Bates wrote:
> >> > I recently opened issue 4262
> >> > <https://gitlab.freedesktop.org/mesa/mesa/-/issues/4262> to begin the
> >> > discussion on integrating perfetto into mesa.
> >> >
> >> > *Background*
> >> >
> >> > System-wide tracing is an invaluable tool for developers to find and
> >> > fix
> >> > performance problems. The perfetto project enables a combined view of
> >> > trace
> >> > data from kernel ftrace, GPU driver and various manually-instrumented
> >> > tracepoints throughout the application and system.
> >>
> >> Unlike some other Linux tracing solutions, Perfetto appears to be for
> >> Android / Chrome(OS?), and not available from in common Linux distro
> >> repos.
> >
> > I don't think there is anything about perfetto that would not be
> > usable in a generic linux distro.. and mesa support for perfetto would
> > perhaps be a compelling reason for distro's to add support
> >
> >> So, why Perfetto instead of one of the other solutions, e.g. from ones
> >> mentioned here:
> >> https://tracingsummit.org/ts/2018/
> >> ?
> >>
> >> And, if tracing API is added to Mesa, shouldn't it support also
> >> tracepoints for other tracing solutions?
> >
> > perfetto does have systrace collectors
> >
> > And a general comment on perfetto vs other things.. we end up needing
> > to support perfetto regardless (for android and CrOS).. we don't
> > *need* to enable it on generic linux, but I think we should (but maybe
> > using the mode that does not require a system server.. at least
> > initially.. that may limit it's ability to collect systrace and traces
> > from other parts of the system, but that wouldn't depend on distro's
> > enabling perfetto system server).
>
> Perfetto seems like an awful lot of infrastructure to capture trace
> events.  Why not follow the example of GPUVis, and write generic
> trace_markers to ftrace?  It limits impact to Mesa, while allowing any
> trace visualizer to use the trace points.

I'm not really seeing how that would cover anything more than CPU
based events.. which is kind of the smallest part of what I'm
interested in..

> >> I mean, code added to drivers themselves preferably should not have
> >> anything perfetto/percetto specific.  Tracing system specific code
> >> should be only in one place (even if it's just macros in common header).
> >>
> >>
> >> > This helps developers
> >> > quickly answer questions like:
> >> >
> >> >- How long are frames taking?
> >>
> >> That doesn't require any changes to Mesa.  Just set uprobe for suitable
> >> buffer swap function [1], and parse kernel ftrace events.  This way
> >> starting tracing doesn't require even restarting the tracked processes.
> >>
> >
> > But this doesn't tell you how long the GPU is spending doing what.  My
> > rough idea is to hook up an optional callback to u_tracepoint so we
> > can get generate perfetto traces on the GPU timeline (ie. with
> > timestamps captured from GPU), fwiw
>
> I implemented a feature called INTEL_MEASURE based off of a tool that
> Ken wrote.  It captures render/batch/frame timestamps in a BO, providing
> durations on the GPU timeline.  It works for Iris and Anv.
>
> The approach provides accurate gpu timing, with minimal stalling.  This
> data could be presented in Perfetto or GPUVis.

have a look at u_trace.. it is basically this but implemented in a way
that is (hopefully) useful to other drivers..

(there is some small gallium dependency currently, although at some
point when I'm spending more time on vk optimization I'll hoist it out
of gallium/aux/util, unless someone else gets there first)

BR,
-R

> > BR,
> > -R
> >
> >> [1] glXSwapBuffers, eglSwapBuffers, eglSwapBuffersWithDamageEXT,
> >> anv_QueuePresentKHR[2]..
> >>
> >> [2] Many apps resolve "vkQueuePresentKHR" Vulkan API loader wrapper
> >> function and call the backend function like "anv_QueuePresentKHR"
> >> directly, so it's  better to track latter instead.
> >>
> >>
> >> >- What caused a particular frame drop?
> >> >- Is it CPU bound or GPU bound?
> >>
> >&

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

On Thu, Feb 11, 2021 at 5:40 PM John Bates  wrote:
>



> Runtime Characteristics
>
> ~500KB additional binary size. Even with using only the basic features of 
> perfetto, it will increase the binary size of mesa by about 500KB.

IMHO, that size is negligible.. looking at freedreno, a mesa build
*only* enabling freedreno is already ~6MB.. distros typically use
"megadriver" (ie. all the drivers linked into a single .so with hard
links for the different  ${driver}_dri.so), which on my fedora laptop
is ~21M.  Maybe if anything is relevant it is how much of that
actually gets paged into RAM from disk, but I think 500K isn't a thing
to worry about too much.

> Background thread. Perfetto uses a background thread for communication with 
> the system tracing daemon (traced) to advertise trace data and get 
> notification of trace start/stop.

Mesa already tends to have plenty of threads.. some of that depends on
the driver, I think currently radeonsi is the threading king, but
there are several other drivers working on threaded_context and async
compile thread pool.

It is worth mentioning that, AFAIU, perfetto can operate in
self-server mode, which seems like it would be useful for distros
which do not have the system daemon.  I'm not sure if we lose that
with percetto?

> Runtime overhead when disabled is designed to be optimal with one predicted 
> branch, typically a few CPU cycles per event. While enabled, the overhead can 
> be around 1 us per event.
>
> Integration Challenges
>
> The perfetto SDK is C++ and designed around macros, lambdas, inline 
> templates, etc. There are ongoing discussions on providing an official 
> perfetto C API, but it is not yet clear when this will land on the perfetto 
> roadmap.
> The perfetto SDK is an amalgamated .h and .cc that adds up to 100K lines of 
> code.
> Anything that includes perfetto.h takes a long time to compile.
> The current Perfetto SDK design is incompatible with being a shared library 
> behind a C API.

So, C++ on it's own isn't a showstopper, mesa has plenty of C++ code.
But maybe we should verify that MSVC is happy with it, otherwise we
need to take a bit more care in some parts of the codebase.

As far as compile time, I wonder if we can regenerate the .cc/.h with
only the gpu trace parts?  But I wouldn't expect the .h to be
something widely included.  For example, for gpu timeline traces in
freedreno, I'm expecting it to look like a freedreno_perfetto.cc with
extern "C" {} around the callbacks that would hook into the
u_tracepoint tracepoints.  That one file would pull in the perfetto
.h, and we'd just not build that file if perfetto was disabled.

Overall having to add our own extern C wrappers in some places doesn't
seem like the *end* of the world.. a bit annoying, but we might end up
doing that regardless if other folks want the ability to hook in
something other than perfetto?



> Mesa Integration Alternatives

I'm kind of leaning towards the "just slurp in the .cc/.h" approach..
that is mostly because I expect to initially just add some basic gpu
timeline tracepoints, but over time iterate on adding more.. it would
be nice to not have to depend on a newer version of an external
library at each step.  That is ofc only my $0.02..

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

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

On Fri, Feb 12, 2021 at 5:01 AM Tamminen, Eero T
 wrote:
>
> Hi,
>
> On Thu, 2021-02-11 at 17:39 -0800, John Bates wrote:
> > I recently opened issue 4262
> >  to begin the
> > discussion on integrating perfetto into mesa.
> >
> > *Background*
> >
> > System-wide tracing is an invaluable tool for developers to find and
> > fix
> > performance problems. The perfetto project enables a combined view of
> > trace
> > data from kernel ftrace, GPU driver and various manually-instrumented
> > tracepoints throughout the application and system.
>
> Unlike some other Linux tracing solutions, Perfetto appears to be for
> Android / Chrome(OS?), and not available from in common Linux distro
> repos.

I don't think there is anything about perfetto that would not be
usable in a generic linux distro.. and mesa support for perfetto would
perhaps be a compelling reason for distro's to add support

> So, why Perfetto instead of one of the other solutions, e.g. from ones
> mentioned here:
> https://tracingsummit.org/ts/2018/
> ?
>
> And, if tracing API is added to Mesa, shouldn't it support also
> tracepoints for other tracing solutions?

perfetto does have systrace collectors

And a general comment on perfetto vs other things.. we end up needing
to support perfetto regardless (for android and CrOS).. we don't
*need* to enable it on generic linux, but I think we should (but maybe
using the mode that does not require a system server.. at least
initially.. that may limit it's ability to collect systrace and traces
from other parts of the system, but that wouldn't depend on distro's
enabling perfetto system server).

> I mean, code added to drivers themselves preferably should not have
> anything perfetto/percetto specific.  Tracing system specific code
> should be only in one place (even if it's just macros in common header).
>
>
> > This helps developers
> > quickly answer questions like:
> >
> >- How long are frames taking?
>
> That doesn't require any changes to Mesa.  Just set uprobe for suitable
> buffer swap function [1], and parse kernel ftrace events.  This way
> starting tracing doesn't require even restarting the tracked processes.
>

But this doesn't tell you how long the GPU is spending doing what.  My
rough idea is to hook up an optional callback to u_tracepoint so we
can get generate perfetto traces on the GPU timeline (ie. with
timestamps captured from GPU), fwiw

BR,
-R

> [1] glXSwapBuffers, eglSwapBuffers, eglSwapBuffersWithDamageEXT,
> anv_QueuePresentKHR[2]..
>
> [2] Many apps resolve "vkQueuePresentKHR" Vulkan API loader wrapper
> function and call the backend function like "anv_QueuePresentKHR"
> directly, so it's  better to track latter instead.
>
>
> >- What caused a particular frame drop?
> >- Is it CPU bound or GPU bound?
>
> That doesn't require adding tracepoints to Mesa, just checking CPU & GPU
> utilization (which is lower level thing).
>
>
> >- Did a CPU core frequency drop cause something to go slower than
> > usual?
>
> Note that nowadays actual CPU frequencies are often controlled by HW /
> firmware, so you don't necessarily get any ftrace event from freq
> change, you would need to poll MSR registers instead (which is
> privileged operation, and polling can easily miss changes).
>
>
> >- Is something else running that is stealing CPU or GPU time? Could
> > I
> >fix that with better thread/context priorities?
> >- Are all CPU cores being used effectively? Do I need
> > sched_setaffinity
> >to keep my thread on a big or little core?
>
> I don't think these to require adding tracepoints to Mesa either...
>
>
> >- What’s the latency between CPU frame submit and GPU start?
>
> I think this would require tracepoints in kernel GPU code more than in
> Mesa?
>
>
> - Eero
>
>
> > *What Does Mesa + Perfetto Provide?*
> >
> > Mesa is in a unique position to produce GPU trace data for several GPU
> > vendors without requiring the developer to build and install
> > additional
> > tools like gfx-pps .
> >
> > The key is making it easy for developers to use. Ideally, perfetto is
> > eventually available by default in mesa so that if your system has
> > perfetto
> > traced running, you just need to run perfetto (perhaps along with
> > setting
> > an environment variable) with the mesa categories to see:
> >
> >- GPU processing timeline events.
> >- GPU counters.
> >- CPU events for potentially slow functions in mesa like shader
> > compiles.
> >
> > Example of what this data might look like (with fake GPU events):
> > [image: percetto-gpu-example.png]
> >
> > *Runtime Characteristics*
> >
> >- ~500KB additional binary size. Even with using only the basic
> > features
> >of perfetto, it will increase the binary size of mesa by about
> > 500KB.
> >- Background thread. Perfetto uses a background thread for
> > communication
> >with 

Re: [Mesa-dev] Perfetto CPU/GPU tracing

[Rob Clark]

yes, but that is a limitation of mali which does not apply to a lot of
other drivers ;-)

But AFAIU typically you'd use perfetto with a sort of system server
collecting trace data from various different processes, so the fact
that that mali trace perf counters come from somewhere else doesn't
really matter

And this is about more than just perf cntrs, I plan to wire up the
u_tracepoint stuff to perfetto events (or rather provide a way to hook
up individual tracepoints) so that we can see on a timeline things
like how long the binning pass took, how long tile passes take (broken
down into restore/draw/resolve).  I think we mostly definitely want
perfetto support in mesa.  It can be optional, but I'm hoping linux
distros start enabling perfetto when they have a compelling reason to
(ie. mesa gpu perf analysis)

BR,
-R

On Fri, Feb 12, 2021 at 2:13 PM Alyssa Rosenzweig
 wrote:
>
> My 2c for Mali/Panfrost --
>
> For us, capturing GPU perf counters is orthogonal to rendering. It's
> expected (e.g. with Arm's tools) to do this from a separate process.
> Neither Mesa nor the DDK should require custom instrumentation for the
> low-level data. Fahien's gfx-pps handles this correctly for Panfrost +
> Perfetto as it is. So for us I don't see the value in modifying Mesa for
> tracing.
>
> On Fri, Feb 12, 2021 at 01:34:51PM -0800, John Bates wrote:
> > (responding from correct address this time)
> >
> > On Fri, Feb 12, 2021 at 12:03 PM Mark Janes  wrote:
> >
> > > I've recently been using GPUVis to look at trace events.  On Intel
> > > platforms, GPUVis incorporates ftrace events from the i915 driver,
> > > performance metrics from igt-gpu-tools, and userspace ftrace markers
> > > that I locally hack up in Mesa.
> > >
> >
> > GPUVis is great. I would love to see that data combined with
> > userspace events without any need for local hacks. Perfetto provides
> > on-demand trace events with lower overhead compared to ftrace, so for
> > example it is acceptable to have production trace instrumentation that can
> > be captured without dev builds. To do that with ftrace it may require a way
> > to enable and disable the ftrace file writes to avoid the overhead when
> > tracing is not in use. This is what Android does with systrace/atrace, for
> > example, it uses Binder to notify processes about trace sessions. Perfetto
> > does that in a more portable way.
> >
> >
> > >
> > > It is very easy to compile the GPUVis UI.  Userspace instrumentation
> > > requires a single C/C++ header.  You don't have to access an external
> > > web service to analyze trace data (a big no-no for devs working on
> > > preproduction hardware).
> > >
> > > Is it possible to build and run the Perfetto UI locally?
> >
> >
> > Yes, local UI builds are possible
> > .
> > Also confirmed with the perfetto team  that
> > trace data is not uploaded unless you use the 'share' feature.
> >
> >
> > >   Can it display
> > > arbitrary trace events that are written to
> > > /sys/kernel/tracing/trace_marker ?
> >
> >
> > Yes, I believe it does support that via linux.ftrace data source
> > . We use that for
> > example to overlay CPU sched data to show what process is on each core
> > throughout the timeline. There are many ftrace event types
> > 
> > in
> > the perfetto protos.
> >
> >
> > > Can it be extended to show i915 and
> > > i915-perf-recorder events?
> > >
> >
> > It can be extended to consume custom data sources. One way this is done is
> > via a bridge daemon, such as traced_probes which is responsible for
> > capturing data from ftrace and /proc during a trace session and sending it
> > to traced. traced is the main perfetto tracing daemon that notifies all
> > trace data sources to start/stop tracing and communicates with user tracing
> > requests via the 'perfetto' command.
> >
> >
> >
> > >
> > > John Bates  writes:
> > >
> > > > I recently opened issue 4262
> > > >  to begin the
> > > > discussion on integrating perfetto into mesa.
> > > >
> > > > *Background*
> > > >
> > > > System-wide tracing is an invaluable tool for developers to find and fix
> > > > performance problems. The perfetto project enables a combined view of
> > > trace
> > > > data from kernel ftrace, GPU driver and various manually-instrumented
> > > > tracepoints throughout the application and system. This helps developers
> > > > quickly answer questions like:
> > > >
> > > >- How long are frames taking?
> > > >- What caused a particular frame drop?
> > > >- Is it CPU bound or GPU bound?
> > > >- Did a CPU core frequency drop cause something to go slower than
> > > usual?
> > > >- Is something else running that is 

Re: [Mesa-dev] Rust drivers in Mesa

[Rob Clark]

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

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

Re: [Mesa-dev] mediump support: future work

[Rob Clark]

On Mon, May 4, 2020 at 5:09 PM Marek Olšák  wrote:
>
> 16-bit varyings only make sense if they are packed, i.e. we need to fit 2 
> 16-bit 4D varyings into 1 vec4 slot to save memory for IO. Without that, AMD 
> (and most others?) won't benefit from 16-bit IO much.
>

I guess for !flat varyings that mostly makes sense if you are manually
interpolating in the fs?  We can, but don't have to and it doesn't
seem like a benefit to do so.  Maybe it would be a win for flat
varyings, but unclear, we might win more from switching to the
instruction we use for interpolated varyings instead of the one that
bypasses interpolation.  At least that seems to be what blob does on
new gens.

> 16-bit uniforms would help everybody, because there is potential for uniform 
> packing, saving memory (and cache lines).
>

it does mean futzing w/ uniforms before uploading.. I'm not sure (for
us) that is a win vs just using the hw builtin automagic fp32->fp16
push-constant conversion.. the push constant upload is pipelined with
draws afaict for newer gens, and from shader standpoint, other than
the restrictions about which instructions can use const src and when,
they are basically free to load.. ie. loading cN.m as hcN.m is free.

so might also what to be a driver option?

> The other items are just for eliminating conversion instructions. We must 
> have more vectorized 16-bit vec2 instructions than "conversion instructions + 
> vec2 packing instructions" for mediump to pay off. We also don't get 
> decreased register usage if we are not vectorized, so mediump is a tough sell 
> at the moment.

we don't really have "vectorized fp16".. we have a sort of "vectorish"
mode where a scalar instruction can repeat, incrementing dst register
and optionally incrementing individual src registers (ie. we can do
.yyy or .yzw swizzles but not others).  That is orthogonal to fp16
(but there may be lower latency for fp16) and mostly seems to help
reducing the latency to load src registers (since hw can load a
non-incremented src register once for each of the scalar instructions
packed together).  Scalar 16b instructions might be a win, but it is a
bit more complicated to tease out the instruction cycles vs the
register load cost.

balancing register pressure vs "vectorish" instructions is a thing I'm
still working on.  But ignoring that fp16 is a win for us because of
register pressure.. ie. a full-reg conflicts with two half-regs.

For sure, a lot of the gain involves avoiding excessive conversions,
but in a lot of common cases we can fold conversion into alu
instruction in the backend..

BR,
-R

>
> Marek
>
> On Mon, May 4, 2020 at 7:03 PM Rob Clark  wrote:
>>
>> On Mon, May 4, 2020 at 11:44 AM Marek Olšák  wrote:
>> >
>> > Hi,
>> >
>> > This is the status of mediump support in Mesa. What I listed is what AMD 
>> > GPUs can do. "Yes" means what Mesa supports.
>> >
>> > Feature FP16 support Int16 support
>> > ALU Yes No
>> > Uniforms No No
>> > VS in No No
>> > VS out / FS in No No
>> > FS out No No
>> > TCS, TES, GS out / in No No
>> > Sampler coordinates (only coord, derivs, lod, bias; not offset and 
>> > compare) No ---
>> > Image coordinates --- No
>> > Return value from samplers (incl. sampler buffers) Yes
>> > No
>> > Return value from image loads (incl. image buffers) No No
>> > Data source for image stores (incl. image buffers) No No
>> > If 16-bit sampler/image instructions are surrounded by conversions, 
>> > promote them to 32 bits No No
>> >
>> > Please let me know if you don't see the table correctly.
>> >
>> > I'd like to know if I can enable some of them using the existing FP16 CAP. 
>> > The only drivers supporting FP16 are currently Freedreno and Panfrost.
>> >
>>
>> I think in general it should be ok.
>>
>> I think for ir3 we want 32b inputs/outputs for geom stages
>> (vs/hs/ds/gs).  For frag outs we use nir_lower_mediump_outputs.. maybe
>> this is a good approach to continue, to use a simple nir lowering pass
>> for cases where a shader stage can directly take 16b input/output.
>> For frag inputs we fold the narrowing conversion in to the varying
>> fetch instruction in backend.
>>
>> int16 would be pretty useful, for loop counters especially.. these can
>> have a long live-range and currently wastefully occupy a full 32b reg.
>>
>> Uniforms we haven't cared too much about, since we can (usually) read
>> a 32b uniform as a 16b and fold that directly into alu instructions..
>> we handle that in the backend.
>>
>> Pushing mediump support further would be great, and we can definitely
>> help if it ends up needing changes in freedreno backend.  The deqp
>> coverage in CI should give us pretty good confidence about whether or
>> not we are breaking things in the ir3 backend.
>>
>> BR,
>> -R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] mediump support: future work

[Rob Clark]

On Mon, May 4, 2020 at 11:44 AM Marek Olšák  wrote:
>
> Hi,
>
> This is the status of mediump support in Mesa. What I listed is what AMD GPUs 
> can do. "Yes" means what Mesa supports.
>
> Feature FP16 support Int16 support
> ALU Yes No
> Uniforms No No
> VS in No No
> VS out / FS in No No
> FS out No No
> TCS, TES, GS out / in No No
> Sampler coordinates (only coord, derivs, lod, bias; not offset and compare) 
> No ---
> Image coordinates --- No
> Return value from samplers (incl. sampler buffers) Yes
> No
> Return value from image loads (incl. image buffers) No No
> Data source for image stores (incl. image buffers) No No
> If 16-bit sampler/image instructions are surrounded by conversions, promote 
> them to 32 bits No No
>
> Please let me know if you don't see the table correctly.
>
> I'd like to know if I can enable some of them using the existing FP16 CAP. 
> The only drivers supporting FP16 are currently Freedreno and Panfrost.
>

I think in general it should be ok.

I think for ir3 we want 32b inputs/outputs for geom stages
(vs/hs/ds/gs).  For frag outs we use nir_lower_mediump_outputs.. maybe
this is a good approach to continue, to use a simple nir lowering pass
for cases where a shader stage can directly take 16b input/output.
For frag inputs we fold the narrowing conversion in to the varying
fetch instruction in backend.

int16 would be pretty useful, for loop counters especially.. these can
have a long live-range and currently wastefully occupy a full 32b reg.

Uniforms we haven't cared too much about, since we can (usually) read
a 32b uniform as a 16b and fold that directly into alu instructions..
we handle that in the backend.

Pushing mediump support further would be great, and we can definitely
help if it ends up needing changes in freedreno backend.  The deqp
coverage in CI should give us pretty good confidence about whether or
not we are breaking things in the ir3 backend.

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

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

[Rob Clark]

On Mon, Apr 6, 2020 at 10:04 AM Michel Dänzer  wrote:
>
> On 2020-04-06 6:34 p.m., Rob Clark wrote:
> >
> > The ideal thing would be to be able to click any jobs that we want to
> > run, say "arm64_a630_gles31", and for gitlab to realize that it needs
> > to automatically trigger dependencies of that job (meson-arm64, and
> > arm_build+arm_test).  But not sure if that is a thing gitlab can do.
>
> Not that I know of. The dependency handling is still pretty rudimentary
> in general.
>
>
> > Triggering just the first container jobs and having everything from
> > there run automatically would be ok if the current rules to filter out
> > unneeded jobs still apply, ie. a panfrost change isn't triggering
> > freedreno CI jobs and visa versa.  But tbh I don't understand enough
> > of what that MR is doing to understand if that is what it does.  (It
> > was suggested on IRC that this is probably what it does.)
>
> It is. Filtered jobs don't exist at all in the pipeline, so they can't
> be triggered by any means. :)
>

ahh, ok, I didn't realize that.. thx for the explaination

BR,
-R
___
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

[Rob Clark]

On Mon, Apr 6, 2020 at 8:43 AM Adam Jackson  wrote:
>
> On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote:
> > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer  wrote:
> > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > > For Mesa, we could run CI only when Marge pushes, so that it's a 
> > > > strictly
> > > > pre-merge CI.
> > >
> > > Thanks for the suggestion! I implemented something like this for Mesa:
> > >
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
> >
> > I wouldn't mind manually triggering pipelines, but unless there is
> > some trick I'm not realizing, it is super cumbersome.  Ie. you have to
> > click first the container jobs.. then wait.. then the build jobs..
> > then wait some more.. and then finally the actual runners.  That would
> > be a real step back in terms of usefulness of CI.. one might call it a
> > regression :-(
>
> I think that's mostly a complaint about the conditionals we've written
> so far, tbh. As I commented on the bug, when I clicked the container
> job (which the rules happen to have evaluated to being "manual"), every
> job (recursively) downstream of it got enqueued, which isn't what
> you're describing. So I think if you can describe the UX you'd like we
> can write rules to make that reality.

Ok, I was fearing that we'd have to manually trigger each stage of
dependencies in the pipeline.  Which wouldn't be so bad except that
gitlab makes you wait for the previous stage to complete before
triggering the next one.

The ideal thing would be to be able to click any jobs that we want to
run, say "arm64_a630_gles31", and for gitlab to realize that it needs
to automatically trigger dependencies of that job (meson-arm64, and
arm_build+arm_test).  But not sure if that is a thing gitlab can do.

Triggering just the first container jobs and having everything from
there run automatically would be ok if the current rules to filter out
unneeded jobs still apply, ie. a panfrost change isn't triggering
freedreno CI jobs and visa versa.  But tbh I don't understand enough
of what that MR is doing to understand if that is what it does.  (It
was suggested on IRC that this is probably what it does.)

BR,
-R
___
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

[Rob Clark]

On Sat, Apr 4, 2020 at 11:41 AM Rob Clark  wrote:
>
> On Sat, Apr 4, 2020 at 11:16 AM Rob Clark  wrote:
> >
> > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne  
> > wrote:
> > >
> > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> > > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer  wrote:
> > > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > > > > For Mesa, we could run CI only when Marge pushes, so that it's a 
> > > > > > strictly
> > > > > > pre-merge CI.
> > > > >
> > > > > Thanks for the suggestion! I implemented something like this for Mesa:
> > > > >
> > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
> > > > >
> > > >
> > > > I wouldn't mind manually triggering pipelines, but unless there is
> > > > some trick I'm not realizing, it is super cumbersome.  Ie. you have to
> > > > click first the container jobs.. then wait.. then the build jobs..
> > > > then wait some more.. and then finally the actual runners.  That would
> > > > be a real step back in terms of usefulness of CI.. one might call it a
> > > > regression :-(
> > >
> > > On GStreamer side we have moved some existing pipeline to manual mode.
> > > As we use needs: between jobs, we could simply set the first job to
> > > manual (in our case it's a single job called manifest in your case it
> > > would be the N container jobs). This way you can have a manual pipeline
> > > that is triggered in single (or fewer) clicks. Here's an example:
> > >
> > > https://gitlab.freedesktop.org/gstreamer/gstreamer/pipelines/128292
> > >
> > > That our post-merge pipelines, we only trigger then if we suspect a
> > > problem.
> > >
> >
> > I'm not sure that would work for mesa since the hierarchy of jobs
> > branches out pretty far.. ie. if I just clicked the arm64 build + test
> > container jobs, and everything else ran automatically after that, it
> > would end up running all the CI jobs for all the arm devices (or at
> > least all the 64b ones)
>
> update: pepp pointed out on #dri-devel that the path-based rules
> should still apply to prune out hw CI jobs for hw not affected by the
> MR.  If that is the case, and we only need to click the container jobs
> (without then doing the wait dance), then this doesn't sound as
> bad as I feared.


PS. I should add, that in these wfh days, I'm relying on CI to be able
to test changes on some generations of hw that I don't physically have
with me.  It's easy to take for granted, I did until I thought about
what I'd do without CI.  So big thanks to all the people who are
working on CI, it's more important these days than you might realize
:-)

BR,
-R
___
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

[Rob Clark]

On Sat, Apr 4, 2020 at 11:16 AM Rob Clark  wrote:
>
> On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne  wrote:
> >
> > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer  wrote:
> > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > > > For Mesa, we could run CI only when Marge pushes, so that it's a 
> > > > > strictly
> > > > > pre-merge CI.
> > > >
> > > > Thanks for the suggestion! I implemented something like this for Mesa:
> > > >
> > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
> > > >
> > >
> > > I wouldn't mind manually triggering pipelines, but unless there is
> > > some trick I'm not realizing, it is super cumbersome.  Ie. you have to
> > > click first the container jobs.. then wait.. then the build jobs..
> > > then wait some more.. and then finally the actual runners.  That would
> > > be a real step back in terms of usefulness of CI.. one might call it a
> > > regression :-(
> >
> > On GStreamer side we have moved some existing pipeline to manual mode.
> > As we use needs: between jobs, we could simply set the first job to
> > manual (in our case it's a single job called manifest in your case it
> > would be the N container jobs). This way you can have a manual pipeline
> > that is triggered in single (or fewer) clicks. Here's an example:
> >
> > https://gitlab.freedesktop.org/gstreamer/gstreamer/pipelines/128292
> >
> > That our post-merge pipelines, we only trigger then if we suspect a
> > problem.
> >
>
> I'm not sure that would work for mesa since the hierarchy of jobs
> branches out pretty far.. ie. if I just clicked the arm64 build + test
> container jobs, and everything else ran automatically after that, it
> would end up running all the CI jobs for all the arm devices (or at
> least all the 64b ones)

update: pepp pointed out on #dri-devel that the path-based rules
should still apply to prune out hw CI jobs for hw not affected by the
MR.  If that is the case, and we only need to click the container jobs
(without then doing the wait dance), then this doesn't sound as
bad as I feared.

BR,
-R
___
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

[Rob Clark]

On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne  wrote:
>
> Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer  wrote:
> > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > > For Mesa, we could run CI only when Marge pushes, so that it's a 
> > > > strictly
> > > > pre-merge CI.
> > >
> > > Thanks for the suggestion! I implemented something like this for Mesa:
> > >
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
> > >
> >
> > I wouldn't mind manually triggering pipelines, but unless there is
> > some trick I'm not realizing, it is super cumbersome.  Ie. you have to
> > click first the container jobs.. then wait.. then the build jobs..
> > then wait some more.. and then finally the actual runners.  That would
> > be a real step back in terms of usefulness of CI.. one might call it a
> > regression :-(
>
> On GStreamer side we have moved some existing pipeline to manual mode.
> As we use needs: between jobs, we could simply set the first job to
> manual (in our case it's a single job called manifest in your case it
> would be the N container jobs). This way you can have a manual pipeline
> that is triggered in single (or fewer) clicks. Here's an example:
>
> https://gitlab.freedesktop.org/gstreamer/gstreamer/pipelines/128292
>
> That our post-merge pipelines, we only trigger then if we suspect a
> problem.
>

I'm not sure that would work for mesa since the hierarchy of jobs
branches out pretty far.. ie. if I just clicked the arm64 build + test
container jobs, and everything else ran automatically after that, it
would end up running all the CI jobs for all the arm devices (or at
least all the 64b ones)

I'm not sure why gitlab works this way, a more sensible approach would
be to click on the last jobs you want to run and for that to
automatically propagate up to run the jobs needed to run clicked job.

BR,
-R
___
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

[Rob Clark]

On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer  wrote:
>
> On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > pre-merge CI.
>
> Thanks for the suggestion! I implemented something like this for Mesa:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
>

I wouldn't mind manually triggering pipelines, but unless there is
some trick I'm not realizing, it is super cumbersome.  Ie. you have to
click first the container jobs.. then wait.. then the build jobs..
then wait some more.. and then finally the actual runners.  That would
be a real step back in terms of usefulness of CI.. one might call it a
regression :-(

Is there a possible middle ground where pre-marge pipelines that touch
a particular driver trigger that driver's CI jobs, but MRs that don't
touch that driver but do touch shared code don't until triggered by
marge?  Ie. if I have a MR that only touches nir, it's probably ok to
not run freedreno jobs until marge triggers it.  But if I have a MR
that is touching freedreno, I'd really rather not have to wait until
marge triggers the freedreno CI jobs.

Btw, I was under the impression (from periodically skimming the logs
in #freedesktop, so I could well be missing or misunderstanding
something) that caching/etc had been improved and mesa's part of the
egress wasn't the bigger issue at this point?

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

Re: [Mesa-dev] [PATCH kmscube] meson.build: Do not set c_std

[Rob Clark]

On Mon, Mar 30, 2020 at 5:28 PM Fabio Estevam  wrote:
>
> Hi Rob,
>
> On Mon, Mar 30, 2020 at 6:29 PM Fabio Estevam  wrote:
> >
> > When building kmscube in Buildroot for ARM the following
> > errors are seen:
> >
> > ../common.c: In function 'get_time_ns':
> > ../common.c:376:18: error: storage size of 'tv' isn't known
> >   struct timespec tv;
> >   ^~
> > ../common.c:377:2: warning: implicit declaration of function 
> > 'clock_gettime'; did you mean 'localtime'? [-Wimplicit-function-declaration]
> >   clock_gettime(CLOCK_MONOTONIC, );
> >   ^
> >   localtime
> > ../common.c:377:16: error: 'CLOCK_MONOTONIC' undeclared (first use in this 
> > function)
> >   clock_gettime(CLOCK_MONOTONIC, );
> >
> > Fix it by using the default for each compiler on every platform instead.
> >
> > Inspired by this gst-plugins-good commit:
> >
> > https://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=19f6559582c73123a3ec1fcf5a6b8651fbc2e83f
> >
> > Signed-off-by: Fabio Estevam 
> > ---
> >  meson.build | 6 +-
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/meson.build b/meson.build
> > index b8131db..0f52dfe 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -26,13 +26,9 @@ project(
> >version : '0.0.1',
> >license : 'MIT',
> >meson_version : '>= 0.47',
> > -  default_options : ['c_std=c99', 'warning_level=2']
> > +  default_options : ['warning_level=2']
>
> c99 was set in commit 6cbd03ab9406 ("Makefile.am: Add -std=c99 to
> CFLAGS") to fix build failure on mips64el:
>
> cube-tex.c:230:2: note: use option -std=c99 or -std=gnu99 to compile your code
>
> If we change c_std=gnu99 then we could make both mips64el and ARM happy.
>
> Will send a v2 with c_std=gnu99.
>

thx.. I don't suppose I could talk you in to sending a gitlab merge request?

BR,
-R
___
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

[Rob Clark]

On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer  wrote:
>
> On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote:
> >
> > We could also do stuff like reducing the amount of tests we run on each
> > commit, and punt some testing to a per-weekend test-run or someting
> > like that. We don't *need* to know about every problem up front, just
> > the stuff that's about to be released, really. The other stuff is just
> > nice to have. If it's too expensive, I would say drop it.
>
> I don't agree that pre-merge testing is just nice to have. A problem
> which is only caught after it lands in mainline has a much bigger impact
> than one which is already caught earlier.
>

one thought.. since with mesa+margebot we effectively get at least
two(ish) CI runs per MR, ie. one when it is initially pushed, and one
when margebot rebases and tries to merge, could we leverage this to
have trimmed down pre-margebot CI which tries to just target affected
drivers, with margebot doing a full CI run (when it is potentially
batching together multiple MRs)?

Seems like a way to reduce our CI runs with a good safety net to
prevent things from slipping through the cracks.

(Not sure how much that would help reduce bandwidth costs, but I guess
it should help a bit.)

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

Re: [Mesa-dev] Drop scons for 20.1?

[Rob Clark]

On Wed, Feb 26, 2020 at 12:16 PM Jose Fonseca  wrote:
>
> > but it bothers me how we keep not making a decision on this. If we'd said, 
> > "let's keep it and support it", that would something.
>
> I'm surprised there's any doubt.
>
> SCons works great for us.   Meson gives no immediate benefit for us other 
> than headaches.  If we cared about nothing but ourselves, we'd keep SCons 
> indefinitely, until it became a pain.
>
> The only reason we don't stubbornly put the foot down is that we understand 
> that having one single build system would be beneficial the whole community, 
> and of course we appreciate all the work Dylan and others did to get Meson to 
> work on Windows, so we'd like to get there one day.
>
> That said, I don't understand why the rest of the Mesa community putting a 
> gun against our head to abandon SCons.
>
> Aren't we maintaining the SCons build?  Since when in Mesa community are some 
> entitled to start remove code that still works, is used, and maintained by 
> others
>

currently scons build is in CI, so for anyone making build system
changes that effects code that is part of the scons build, they have
to go and read enough stack-overflow to figure out how to make the
same changes in scons ;-)


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

Re: [Mesa-dev] Drop scons for 20.1?

[Rob Clark]

On Wed, Feb 26, 2020 at 2:07 AM Michel Dänzer  wrote:
>
> On 2020-02-26 4:56 a.m., Rob Clark wrote:
> > It looks like we have 4 scons build jobs in CI.. I'm not sure how much
> > that costs us, but I guess those cycles could be put to better use?
> > So even ignoring the developer-cycles issue (ie. someone making
> > changes that effects scons build, and has to setup a scons build env
> > to fix breakage of their MR) I guess there is at least an argument to
> > remove scons from CI.  Whether it is worth keeping a dead build system
> > after it is removed from CI is an issue that I'm ambivalent about.
>
> As long as it's supported, it needs to be tested in CI.
>

Well, I mean, removed from CI (but files left in place) would put it
at the same level of "support" as android build.  Ie. not tested in CI
and doesn't block merging changes, but people who use it are on the
hook for pushing fixes when it does break.


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

Re: [Mesa-dev] Drop scons for 20.1?

[Rob Clark]

It looks like we have 4 scons build jobs in CI.. I'm not sure how much
that costs us, but I guess those cycles could be put to better use?
So even ignoring the developer-cycles issue (ie. someone making
changes that effects scons build, and has to setup a scons build env
to fix breakage of their MR) I guess there is at least an argument to
remove scons from CI.  Whether it is worth keeping a dead build system
after it is removed from CI is an issue that I'm ambivalent about.

BR,
-R

On Tue, Feb 25, 2020 at 3:42 PM Kristian Høgsberg  wrote:
>
> It's been a while since Dylan did the work to make meson support
> Windows and there's been plenty of time to provide feedback or improve
> argue why we still need scons. I haven't seen any such discussion and
> I think we've waited long enough.
>
> Let's drop scons for the next release and move things forward?
>
> Kristian
> ___
> 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] Broken rendering of glxgears on S/390 architecture (64bit, BigEndian)

[Rob Clark]

On Tue, Feb 4, 2020 at 9:42 PM Eric Anholt  wrote:
>
> On Tue, Feb 4, 2020 at 7:54 PM Rob Clark  wrote:
> >
> > it seems like BE vs formats (vs llvm) is a constant nightmare, because
> > there are essentially no mesa dev's working on BE devices (ie. issues
> > are generally discovered long after the fact when mesa changes finally
> > propagate into into enterprise distros).. but with gitlab we have now
> > a sane scheme to plug in more decentralized CI runners if someone
> > wants to step up and figure out how get some BE test coverage into
> > CI.. just saying.. ;-)
>
> We don't even need runners:
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3643

oh, very nice!

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

Re: [Mesa-dev] Broken rendering of glxgears on S/390 architecture (64bit, BigEndian)

[Rob Clark]

it seems like BE vs formats (vs llvm) is a constant nightmare, because
there are essentially no mesa dev's working on BE devices (ie. issues
are generally discovered long after the fact when mesa changes finally
propagate into into enterprise distros).. but with gitlab we have now
a sane scheme to plug in more decentralized CI runners if someone
wants to step up and figure out how get some BE test coverage into
CI.. just saying.. ;-)

BR,
-R

On Tue, Feb 4, 2020 at 4:14 PM Stefan Dirsch  wrote:
>
> Hi
>
> Unfortunately rendering of glxgears on S/390 architecture (64bit, BigEndian)
> is broken on Mesa 19.3.3. I bisected the issue and the git commit id d17ff2f7,
> which came in between 19.2 and 19.3, caused the issue. After reverting this
> commit, glxgears rendering is working again. I openend issu#2472 for this.
>
>   https://gitlab.freedesktop.org/mesa/mesa/issues/2472
>
> Thanks,
> Stefan
>
> Public Key available
> --
> Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
> Tel: 0911-740 53 0Maxfeldstraße 5
> FAX: 0911-740 53 479  D-90409 Nürnberg
> http://www.suse.deGermany
> 
> (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
> 
> ___
> 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] Is it time to stop using the mailing list for patch review?

[Rob Clark]

On Wed, Dec 11, 2019 at 9:58 AM Brian Paul  wrote:
>
> On 12/11/2019 10:42 AM, Jason Ekstrand wrote:
> > On Wed, Dec 11, 2019 at 11:33 AM Michel Dänzer  > > wrote:
> >
> > On 2019-12-11 5:47 p.m., Brian Paul wrote:
> >  >
> >  > I've had little time for Mesa work the past 18 months.
> >
> > That makes me sad, I hope you'll have more time again in the future.
>
> Between family life and VMware work, there's little left over.  I'll be
> lurking if nothing else.
>
>
> >  > 1. I don't think the mesa-dev list should be shut down nor purged
> > from
> >  > the documentation.
> >
> > Yeah, I don't think anybody seriously suggested the list should be shut
> > down, just that GitLab is now preferred for patch submission & review.
> >
> >
> >  > Someone mentioned hardly reading the mailing list anymore.  I still
> >  > haven't gotten into the habit of monitoring the MRs page...
> >
> > Instead of monitoring a web page, I recommend setting up notifications
> > via the bell icon on https://gitlab.freedesktop.org/mesa/mesa
> > 
> > 
> > [0]. If
> > you select "Custom", you can select in detail which events you want to
> > get notification e-mails for. Check "New merge request" to get an e-mail
> > for each new MR created. Then you can either enable notifications for
> > other MR events here as well, or enable all notifications for MRs you're
> > interested in using the "Notifications" switch in the right hand panel
> > on each MR's page.
>
> Thanks for the tip!  That's the kind of thing that would be useful to
> document.
>
>
> > You can also subscribe to specific labels which is what I've done.  That
> > way I get e-mails about anything going on in NIR or our Vulkan driver
> > but don't have to see every nouveau MR.
>
> Are labels put on MRs automatically or does the person submitting have
> to do that manually?
>

unfortunately it is manual.. and it is slightly worse in that you need
to have developer permissions in gitlab to add labels..

(some bot that automatically added labels based on some path regex
rules would be super spiffy)

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

Re: [Mesa-dev] Running the CI pipeline on personal Mesa branches

[Rob Clark]

On Mon, Dec 9, 2019 at 2:27 AM Michel Dänzer  wrote:
>
> On 2019-12-07 12:56 a.m., Rob Clark wrote:
>
> > It would be nice if there was some way to setup some conservative
> > filters to exclude groups of tests, ie. if only paths changed were
> > under src/freedreno or src/gallium/drivers/freedreno, then no need to
> > run panfrost CI, and visa versa.  We probably shouldn't try to fine
> > tune that *too* much at this risk of skipping tests that should have
> > run, but seems like there should be same safe low hanging fruit to cut
> > down on CI runs in common cases.
>
> Lots of people suggest something like this, but most of them probably
> imagine it to be easier than it actually is. :)
>
> See https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569 .
>

yeah, it does seem like it is more complex than it sounds.. I'm glad
to see there is some work on that.  There are a lot more CI jobs that
I'd *like* to be able to run (maybe some can be scheduled jobs rather
than per-MR).. for example modern adreno can be both an IMR and a
tiler, so we really have two different render paths which could have
their own bugs.. I'd love to be able to test both forcing tiling and
sysmem render paths..  maybe don't have to happen on every MR, but
freeing up CI runner bandwidth to run additional tests seems useful.

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

Re: [Mesa-dev] Running the CI pipeline on personal Mesa branches

[Rob Clark]

On Fri, Dec 6, 2019 at 3:46 PM Bas Nieuwenhuizen
 wrote:
>
> On Fri, Dec 6, 2019 at 10:49 AM Michel Dänzer  wrote:
> >
> >
> > I just merged
> > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2794 , which
> > affects people who want to run the CI pipeline on personal Mesa branches:
> >
> > Pushing changes to a personal branch now always creates a pipeline, but
> > none of the jobs in it run by default. (There are no longer any special
> > branch names affecting this, because creating MRs from such special
> > branches resulted in duplicate CI job runs)
> >
> > The container stage jobs can be triggered manually from the GitLab UI
> > (and maybe also via the GitLab API, for people who'd like to automate
> > this? I haven't looked into that). The build/test stage jobs run
> > automatically once all their dependencies have passed.
> >
> > As an example, in order to run one of the "piglit-*" test jobs, one has
> > to manually trigger the "x86_build" and "x86_test" jobs.
> >
> > The pipelines created for merge requests still run all jobs by default
> > as before.
> >
> >
> > The main motivation for these changes is to avoid wasting CI runner
> > resources. In that same spirit, please also cancel any unneeded
> > build/test jobs. This can be done already before those jobs start
> > running, e.g. while the container stage jobs run.
>
> No complaint about not running the pipelines by default in personal
> repositories, but expecting people to cancel automatically spawned CI
> jobs as normal part of their workflow seems incredibly fiddly and
> fragile to me. Are we *that* constrained?
>

It would be nice if there was some way to setup some conservative
filters to exclude groups of tests, ie. if only paths changed were
under src/freedreno or src/gallium/drivers/freedreno, then no need to
run panfrost CI, and visa versa.  We probably shouldn't try to fine
tune that *too* much at this risk of skipping tests that should have
run, but seems like there should be same safe low hanging fruit to cut
down on CI runs in common cases.

I guess maybe that only helps if the bottleneck are the hw CI runners,
which might not be the case.. I'm not sure.

BR,
-R
___
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?

[Rob Clark]

On Wed, Dec 4, 2019 at 11:58 PM Kenneth Graunke  wrote:
>
> On Tuesday, December 3, 2019 4:39:15 PM PST 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.
> >
> > Opinions?
> >
> > Thanks,
> > Marek
>
> FWIW, I am not in favor of either plan for the time being.
>
> - I agree with Eric that we're finally starting to clean up and
>   de-duplicate things, and pay off technical debt we've put off for
>   a long time.  I think forking everything in-tree would just be a
>   giant mess.
>
> - I agree with Dave that this seems to be a giant hassle for our
>   downstreams with little benefit for them in the short term.
>
> - Shuffling r100/r200/i915/nouveau_vieux off to a legacy fork seems
>   like a fine plan.  They're ancient hardware that can't (or barely
>   can) do GL 2.x.  Nothing much has happened with them in years,
>   and I'm not sure all of them even really have maintainers.
>
>   The main blocker here I think would be ironing out all the glvnd
>   issues and making sure that is working solidly for everyone.
>   (FWIW, glvnd is not even enabled by default in our build system!)
>
> - Shuffling i965 off to legacy is really premature I think.  Iris
>   isn't even shipping in distros yet (hopefully soon!), and even
>   then, we have a _ton_ of Haswell users.  Check the Phoronix
>   comments if you want to see how pissed off people are about even
>   bringing up this topic.  (Or better yet, don't...basic human
>   decency toward others seems to be lacking.  Hooray, internet...)
>
> - Writing a Gallium driver for Intel Gen4-7.5 would be interesting.
>
>   I've been thinking about this some, and it might be possible to
>   retain some of the niceties of the iris memory model even on older
>   hardware, by relying on a modern kernel and possibly making some
>   (hopefully minor) improvements.  Even if we didn't, going back to
>   the i965 model wouldn't be the worst thing.  The new driver would
>   almost certainly be faster than i965, if not as good as iris.
>
>   ajax and I were planning to call it crocus, if I wrote one.  I don't
>   think it would take nearly as long.  But it's still a bunch of time
>   that I don't think I can justify spending.  The new hardware can do
>   so much more, and is so much faster, and much lower power.  I think
>   it would be better for me to spend my time on Gen11+.
>
> - Vulkan has really taken off, and OpenGL feels increasingly like a
>   dead end.  DXVK has brought more games than we had with native ports.
>   Feral is even reworking some native OpenGL ports to use Vulkan.  New
>   graphics features are happening in the Vulkan space.
>
>   So, I kind of wonder whether it's worth our time to go through and
>   massively clean up and rearchitecture the OpenGL drivers at this
>   point.  By the time we're finished, will anyone care?

maybe years in the future, when zink is the only remaining gallium
driver, we have v2 of this discussion (ie. forking the other gallium
drivers into an LTS branch) :-P

BR,
-R

>
> - Are there concrete things that are prohibitively expensive with
>   classic around?  Otherwise, Eric's suggestion of "so go do that!"
>   sounds like a good idea.  We've started finally merging a bunch
>   of code and I think this is a positive direction.
>
> I'd say let's shelve this for now and think about it again later.
> I suspect in a year or so the calculus will look fairly different.
>
> --Ken
> ___
> 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] Remove classic drivers or fork src/mesa for gallium?

[Rob Clark]

On Wed, Dec 4, 2019 at 9:48 AM Eric Anholt  wrote:
>
> On Tue, Dec 3, 2019 at 4:39 PM 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.
>
> (resending reply-all)
>
> I object to both of these.  They increase work for Mesa folks like me
> who do tree-wide work.
>
> I feel like we're finally (formats, util/ helpers, etc.) paying down
> the technical debt that we built with gallium copying so much of
> src/mesa/main, and saying "let's go duplicate more code so we can do
> some unspecified optimization work" gets me really upset.

tbf option #1 would be a copy of the code.. but a copy that we'd
(hopefully) ignore from the perspective of tree-wide cleanup/refactor.
If we started refactoring the legacy fork, that would strongly defeat
the purpose of having it!

Given that we don't have most of the classic drivers (other than i965)
in CI, and presumably not many folks who are tracking master test the
old classic drivers, moving them off to a fork seems to me to
significantly reduce the risk of refactorings (whether it be for perf
or for cleanup).

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

Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically

[Rob Clark]

hmm, initially the UCP lowering did work post var lowering (since it
had work after tgsi_to_nir).. the same might not be true of the
drawpix/wpos_ytransform/etc lowering that is used internally in
mesa/st for variants.

I assume something like this is the issue?

BR,
-R

On Fri, Oct 18, 2019 at 3:24 PM Marek Olšák  wrote:
>
> Oh BTW, drivers that want to implement pipe_screen::finalize_nir to improve 
> cached shader compilation can't use any of those lowering passes, because 
> then things blow up. The only _optional_ lowering you can do in st/mesa is 
> clamp_color and force_persample_in_shader, which covers iris at least 
> (radeonsi doesn't need any). If you need more, you either need to invest a 
> significant amount of time to make driver-specific NIR work with the lowering 
> passes, or give up on good shader cache efficiency.
>
> Marek
>
> On Fri, Oct 18, 2019 at 4:17 PM Marek Olšák  wrote:
>>
>> Note that none of the lowering passes work if I enable them on radeonsi. So 
>> if you think about enabling them for your driver, I guess you have some work 
>> to do in the driver as well.
>>
>> On the other hand, having multiple shader variants in st/mesa is a 
>> performance disadvantage. The lowering should be done at the machine-level 
>> assembly code, so that you don't have to completely recompile from a 
>> higher-level IR.
>>
>> Marek
>>
>> On Fri, Oct 18, 2019 at 4:08 PM Marek Olšák  wrote:
>>>
>>> On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin  wrote:

 On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund
  wrote:
 >
 > On Fri, 2019-10-18 at 08:57 -0400, Ilia Mirkin wrote:
 > > On Fri, Oct 18, 2019 at 8:51 AM Erik Faye-Lund
 > >  wrote:
 > > > On Thu, 2019-10-17 at 22:24 -0400, Ilia Mirkin wrote:
 > > > > In the meanwhile (unless you plan on taking up Jason's
 > > > > suggestion),
 > > > > might I recommend some assert's for the unhandled cases so that
 > > > > there
 > > > > are no surprises?
 > > >
 > > > Good idea. I sent a MR for it here:
 > > >
 > > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2380
 > >
 > > Not sure that approach works, esp with SSO.
 >
 > If so, wouldn't that already be a problem with the existing
 > lower_depth_clamp-stuff, then? I mean, I just lifted the logic from
 > there...

 Yeah, that looks bogus. I'm moderately sure that checking
 "st->vp/gp/tep" at LinkShader time is wrong. Marek can probably
 confirm.
>>>
>>>
>>> Don't read any context states at link time. It's wrong.
>>>
>>> Marek
>
> ___
> 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] libdrm versioning - switch to 19.0.0?

[Rob Clark]

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


>
>>
>> year.month.n (19.10.0)
>> year.month.day (19.10.10)
>>
>> Marek
>> ___
>> 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Copying common u_format from gallium/auxiliary to broadcom/util

[Rob Clark]

The plan is to extract some of this from gallium to share formats and
related utils.. I need this too in order to share layout helper
between gallium (freedreno) and vulkan (turnip) drivers

BR,
-R

On Thu, Oct 3, 2019 at 11:30 PM  wrote:
>
>
> Currently broadcom/compiler does not link on its own. It references undefined 
> symbols to:
> - `util_format_description`
> - `util_format_is_unorm`
> - `util_format_is_float`
>
> For gallium/v3d, these get provided by gallium/auxiliary. Seems to be an odd 
> dependency to me.
> I would now like to copy at least these 3 symbols to broadcom/util with a 
> `v3d_` prefix. This way broadcom/compiler has no implicit dependency on 
> gallium anymore.
> Any opinions or better ideas?
>
> ___
> 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] Propose: Add transform buffer in egl/drivers/dir2/platform_android.c

[Rob Clark]

On Wed, Sep 11, 2019 at 9:14 PM Cici Ruan  wrote:
>
> Hi Mesa developers,
>
> I would like to add a feature in egl/drivers/dir2/platform_android.c to 
> respect he transform hint and rotation in Android buffer and transform buffer 
> to pre-rotated buffer, so display hardware can do a simple linear read from 
> the buffer to scan it out.
>
> It's my first time to do something in Mesa repository here. According to the 
> document, I need propose first. If anyone has a different opinion, please let 
> me know. Or I will go ahead to work on it.
>

I think it is ok to go ahead and propose a patch.  I've added Fritz
who has been doing some work on y-flip extension, which I guess has
some overlap.  Although I'm not sure quite how it would work to
support arbitrary transformations (without an extra blit), since I
think this would have some effect on gl_FragCoord and some other
things like that.

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

Re: [Mesa-dev] Enabling freedreno CI in Mesa MRs

[Rob Clark]

On Fri, Sep 6, 2019 at 3:09 PM Eric Anholt  wrote:
>
> Rob Clark  writes:
>
> > On Wed, Sep 4, 2019 at 1:42 PM Eric Anholt  wrote:
> >>
> >> If you haven't seen this MR:
> >>
> >> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1632
> >>
> >> I feel ready to enable CI of freedreno on Mesa MRs.  There are some docs
> >> here:
> >>
> >> https://gitlab.freedesktop.org/mesa/mesa/blob/e81a2d3b40240651f506a2a5afeb989792b3dc0e/.gitlab-ci/README.md
> >>
> >> Once we merge this, this will greatly increase Mesa's pre-merge CI
> >> coverage on MRs by getting us up to GLES3.1 going through the CTS.  Once
> >> krh is ready to put up an in-progress MR of tess, we can override the
> >> GLES3.1 run to force-enable 3.2 with the remaining tess issues as
> >> expected fails, and get a whole lot more API coverage.
> >>
> >> As far as stability of this CI, I've been through I think an order of
> >> magnitude more runs of the CI than are visible from that MR, and I'm
> >> pretty sure we've got a stable set of tests now -- I'm currently working
> >> on fixing the flappy tests so we can drop the a630-specific skip list.
> >> The lab has also been up for long enough that I'm convinced the HW is
> >> stable enough to subject you all to it.
> >
> > I won't claim to be an unbiased observer, but I'm pretty excited about
> > this.  This has been in the works for a while, and I think it is to
> > the point where we aren't going to get much more useful testing of our
> > gitlab runners with it living off on a branch, so at some point you
> > just have to throw the switch.
> >
> > I'd propose, that unless there are any objections, we land this Monday
> > morning (PST) on master, to ensure a relatively short turn-around just
> > in case something went badly.
> >
> > (I can be online(ish) over the weekend if we want to throw the switch
> > sooner.. but I might be AFK here and there to get groceries and things
> > like that.  So response time might be a bit longer than on a week
> > day.)
>
> I'm going to be gone on my yearly bike trip until Tuesday, so I propose
> delaying until then so I can be more responsive :)

Works for me

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

Re: [Mesa-dev] Enabling freedreno CI in Mesa MRs

[Rob Clark]

On Wed, Sep 4, 2019 at 1:42 PM Eric Anholt  wrote:
>
> If you haven't seen this MR:
>
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1632
>
> I feel ready to enable CI of freedreno on Mesa MRs.  There are some docs
> here:
>
> https://gitlab.freedesktop.org/mesa/mesa/blob/e81a2d3b40240651f506a2a5afeb989792b3dc0e/.gitlab-ci/README.md
>
> Once we merge this, this will greatly increase Mesa's pre-merge CI
> coverage on MRs by getting us up to GLES3.1 going through the CTS.  Once
> krh is ready to put up an in-progress MR of tess, we can override the
> GLES3.1 run to force-enable 3.2 with the remaining tess issues as
> expected fails, and get a whole lot more API coverage.
>
> As far as stability of this CI, I've been through I think an order of
> magnitude more runs of the CI than are visible from that MR, and I'm
> pretty sure we've got a stable set of tests now -- I'm currently working
> on fixing the flappy tests so we can drop the a630-specific skip list.
> The lab has also been up for long enough that I'm convinced the HW is
> stable enough to subject you all to it.

I won't claim to be an unbiased observer, but I'm pretty excited about
this.  This has been in the works for a while, and I think it is to
the point where we aren't going to get much more useful testing of our
gitlab runners with it living off on a branch, so at some point you
just have to throw the switch.

I'd propose, that unless there are any objections, we land this Monday
morning (PST) on master, to ensure a relatively short turn-around just
in case something went badly.

(I can be online(ish) over the weekend if we want to throw the switch
sooner.. but I might be AFK here and there to get groceries and things
like that.  So response time might be a bit longer than on a week
day.)

Objections anyone?  Or counter-proposals?

BR,
-R

> Once this is merged, please @anholt me on your MRs if you find spurious
> failures in freedreno so I can go either disable those tests or fix
> them.
>
> For some info on how I set up my DUTs, see
> https://gitlab.freedesktop.org/anholt/mesa/wikis/db410c-setup for
> starting from a pretty normal debian buster rootfs.  I'd love to work
> with anyone on replicating this style of CI for your own hardware lab if
> you're interested, or hooking pre-merge gitlab CI up to your existing CI
> lab if you can make it public-access (panfrost?  Intel's CI?)
> ___
> 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] Moving libglvnd to FreeDesktop Gitlab

[Rob Clark]

On Sat, Aug 31, 2019 at 12:34 PM Matt Turner  wrote:
>
> Getting patches into libglvnd has proven quite difficult (see [0] for
> example). There was some talk of moving it to FreeDesktop Gitlab on
> IRC recently. Can we move forward with that? Are there objections to
> doing so?
>
> [0] https://github.com/NVIDIA/libglvnd/pull/86

for whatever it's worth, I think we should

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

Re: [Mesa-dev] Switching to Gitlab Issues instead of Bugzilla?

[Rob Clark]

On Thu, Aug 29, 2019 at 12:02 PM Kenneth Graunke  wrote:
>
> Hi all,
>
> As a lot of you have probably noticed, Bugzilla seems to be getting a
> lot of spam these days - several of us have been disabling a bunch of
> accounts per day, sweeping new reports under the rug, hiding comments,
> etc.  This bug spam causes emails to be sent (more spam!) and then us
> to have to look at ancient bugs that suddenly have updates.
>
> I think it's probably time to consider switching away from Bugzilla.
> We are one of the few projects remaining - Mesa, DRM, and a few DDX
> drivers are still there, but almost all other projects are gone:
>
> https://bugs.freedesktop.org/enter_bug.cgi
>
> Originally, I was in favor of retaining Bugzilla just to not change too
> many processes all at once.  But we've been using Gitlab a while now,
> and several of us have been using Gitlab issues in our personal repos;
> it's actually pretty nice.
>
> Some niceities:
>
> - Bug reporters don't necessarily need to sign up for an account
>   anymore.  They can sign in with their Gitlab.com, Github, Google,
>   or Twitter accounts.  Or make one as before.  This may be nicer for
>   reporters that don't want to open yet another account just to report
>   an issue to us.
>
> - Anti-spam support is actually maintained.  Bugzilla makes it near
>   impossible to actually delete garbage, Gitlab makes it easier.  It
>   has a better account creation hurdle than Bugzilla's ancient captcha,
>   and Akismet plug-ins for handling spam.
>
> - The search interface is more modern and easier to use IMO.
>
> - Permissions & accounts are easier - it's the same unified system.
>
> - Easy linking between issues and MRs - mention one in the other, and
>   both get updated with cross-links so you don't miss any discussion.
>
> - Milestone tracking
>
>   - This could be handy for release trackers - both features people
> want to land, and bugs blocking the release.
>
>   - We could also use it for big efforts like direct state access,
> getting feature parity with fglrx, or whatnot.
>
> - Khronos switched a while ago as well, so a number of us are already
>   familiar with using it there.
>
> Some cons:
>
> - Moving bug reports between the kernel and Mesa would be harder.
>   We would have to open a bug in the other system.  (Then again,
>   moving bugs between Mesa and X or Wayland would be easier...)

If that was a concern, we could setup a kernel gitlab project that has
an empty git repository (at least until we are ready to move drm git
tree).

> What do people think?  If folks are in favor, Daniel can migrate
> everything for us, like he did with the other projects.  If not,
> I'd like to hear what people's concerns are.
>

yes, please, let's move!

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

Re: [Mesa-dev] [PATCH] util/slab: add slab_free_fast()

[Rob Clark]

Yes, although not in front of me.. overall for gl_driver2 it was
something along the lines of 2-3%.  Looking at perf-report, slab_free
(+ slab_free_fast) went from ~20% to nearly nothing(ish) iirc..

BR,
-R

On Wed, Aug 7, 2019 at 4:58 PM Jason Ekstrand  wrote:
>
> Do you have any actual numbers for this?
>
> On August 7, 2019 17:02:22 Rob Clark  wrote:
>
> > From: Rob Clark 
> >
> > I noticed slab_free() showing up at the top of perf results in
> > gl_driver2, due to "streaming" GPU state objects, which are allocated
> > and destroyed within a single draw call.
> >
> > In this case, it is guaranteed that we free on the same child pool,
> > from the same (only) thread accessing the child pool.  So add a faster,
> > but more restricted version of slab_free() to cut the overhead.
> >
> > Signed-off-by: Rob Clark 
> > ---
> > src/util/slab.c | 20 
> > src/util/slab.h |  1 +
> > 2 files changed, 21 insertions(+)
> >
> > diff --git a/src/util/slab.c b/src/util/slab.c
> > index 62634034fdc..21076a80238 100644
> > --- a/src/util/slab.c
> > +++ b/src/util/slab.c
> > @@ -276,6 +276,26 @@ void slab_free(struct slab_child_pool *pool, void *ptr)
> >}
> > }
> >
> > +/**
> > + * Similar to slab_free(), except that freeing an object in a different 
> > pool
> > + * from the one it was allocated from is *not* allowed.
> > + */
> > +void slab_free_fast(struct slab_child_pool *pool, void *ptr)
> > +{
> > +   struct slab_element_header *elt = ((struct slab_element_header*)ptr - 
> > 1);
> > +
> > +   CHECK_MAGIC(elt, SLAB_MAGIC_ALLOCATED);
> > +   SET_MAGIC(elt, SLAB_MAGIC_FREE);
> > +
> > +   assert(p_atomic_read(>owner) == (intptr_t)pool);
> > +
> > +   /* This is the simple case: The caller guarantees that we can safely
> > +* access the free list.
> > +*/
> > +   elt->next = pool->free;
> > +   pool->free = elt;
> > +}
> > +
> > /**
> >  * Allocate an object from the slab. Single-threaded (no mutex).
> >  */
> > diff --git a/src/util/slab.h b/src/util/slab.h
> > index 5a25adaf7f4..9748cd95858 100644
> > --- a/src/util/slab.h
> > +++ b/src/util/slab.h
> > @@ -78,6 +78,7 @@ void slab_create_child(struct slab_child_pool *pool,
> > void slab_destroy_child(struct slab_child_pool *pool);
> > void *slab_alloc(struct slab_child_pool *pool);
> > void slab_free(struct slab_child_pool *pool, void *ptr);
> > +void slab_free_fast(struct slab_child_pool *pool, void *ptr);
> >
> > struct slab_mempool {
> >struct slab_parent_pool parent;
> > --
> > 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

Re: [Mesa-dev] [PATCH] util/slab: add slab_free_fast()

[Rob Clark]

should be easy enough to re-create..  I will note that the perf
results differ a *lot* if I pin things to small (in-order) calls, so
I'm guestimating that what perf is showing me w/ slab_free() is where
reality catches up to mis-predicted branches.

BR,
-R


On Wed, Aug 7, 2019 at 9:44 PM Jason Ekstrand  wrote:
>
> It'd be nice to throw some numbers in the donut message before you push.
> "Real" ones of it's convenient but what you have below is probably fine if
> you've already thrown the data away.
>
> On August 7, 2019 19:13:21 Rob Clark  wrote:
>
> > Yes, although not in front of me.. overall for gl_driver2 it was
> > something along the lines of 2-3%.  Looking at perf-report, slab_free
> > (+ slab_free_fast) went from ~20% to nearly nothing(ish) iirc..
> >
> > BR,
> > -R
> >
> > On Wed, Aug 7, 2019 at 4:58 PM Jason Ekstrand  wrote:
> >>
> >> Do you have any actual numbers for this?
> >>
> >> On August 7, 2019 17:02:22 Rob Clark  wrote:
> >>
> >> > From: Rob Clark 
> >> >
> >> > I noticed slab_free() showing up at the top of perf results in
> >> > gl_driver2, due to "streaming" GPU state objects, which are allocated
> >> > and destroyed within a single draw call.
> >> >
> >> > In this case, it is guaranteed that we free on the same child pool,
> >> > from the same (only) thread accessing the child pool.  So add a faster,
> >> > but more restricted version of slab_free() to cut the overhead.
> >> >
> >> > Signed-off-by: Rob Clark 
> >> > ---
> >> > src/util/slab.c | 20 
> >> > src/util/slab.h |  1 +
> >> > 2 files changed, 21 insertions(+)
> >> >
> >> > diff --git a/src/util/slab.c b/src/util/slab.c
> >> > index 62634034fdc..21076a80238 100644
> >> > --- a/src/util/slab.c
> >> > +++ b/src/util/slab.c
> >> > @@ -276,6 +276,26 @@ void slab_free(struct slab_child_pool *pool, void 
> >> > *ptr)
> >> >}
> >> > }
> >> >
> >> > +/**
> >> > + * Similar to slab_free(), except that freeing an object in a different 
> >> > pool
> >> > + * from the one it was allocated from is *not* allowed.
> >> > + */
> >> > +void slab_free_fast(struct slab_child_pool *pool, void *ptr)
> >> > +{
> >> > +   struct slab_element_header *elt = ((struct slab_element_header*)ptr 
> >> > - 1);
> >> > +
> >> > +   CHECK_MAGIC(elt, SLAB_MAGIC_ALLOCATED);
> >> > +   SET_MAGIC(elt, SLAB_MAGIC_FREE);
> >> > +
> >> > +   assert(p_atomic_read(>owner) == (intptr_t)pool);
> >> > +
> >> > +   /* This is the simple case: The caller guarantees that we can safely
> >> > +* access the free list.
> >> > +*/
> >> > +   elt->next = pool->free;
> >> > +   pool->free = elt;
> >> > +}
> >> > +
> >> > /**
> >> >  * Allocate an object from the slab. Single-threaded (no mutex).
> >> >  */
> >> > diff --git a/src/util/slab.h b/src/util/slab.h
> >> > index 5a25adaf7f4..9748cd95858 100644
> >> > --- a/src/util/slab.h
> >> > +++ b/src/util/slab.h
> >> > @@ -78,6 +78,7 @@ void slab_create_child(struct slab_child_pool *pool,
> >> > void slab_destroy_child(struct slab_child_pool *pool);
> >> > void *slab_alloc(struct slab_child_pool *pool);
> >> > void slab_free(struct slab_child_pool *pool, void *ptr);
> >> > +void slab_free_fast(struct slab_child_pool *pool, void *ptr);
> >> >
> >> > struct slab_mempool {
> >> >struct slab_parent_pool parent;
> >> > --
> >> > 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] util/slab: add slab_free_fast()

[Rob Clark]

From: Rob Clark 

I noticed slab_free() showing up at the top of perf results in
gl_driver2, due to "streaming" GPU state objects, which are allocated
and destroyed within a single draw call.

In this case, it is guaranteed that we free on the same child pool,
from the same (only) thread accessing the child pool.  So add a faster,
but more restricted version of slab_free() to cut the overhead.

Signed-off-by: Rob Clark 
---
 src/util/slab.c | 20 
 src/util/slab.h |  1 +
 2 files changed, 21 insertions(+)

diff --git a/src/util/slab.c b/src/util/slab.c
index 62634034fdc..21076a80238 100644
--- a/src/util/slab.c
+++ b/src/util/slab.c
@@ -276,6 +276,26 @@ void slab_free(struct slab_child_pool *pool, void *ptr)
}
 }
 
+/**
+ * Similar to slab_free(), except that freeing an object in a different pool
+ * from the one it was allocated from is *not* allowed.
+ */
+void slab_free_fast(struct slab_child_pool *pool, void *ptr)
+{
+   struct slab_element_header *elt = ((struct slab_element_header*)ptr - 1);
+
+   CHECK_MAGIC(elt, SLAB_MAGIC_ALLOCATED);
+   SET_MAGIC(elt, SLAB_MAGIC_FREE);
+
+   assert(p_atomic_read(>owner) == (intptr_t)pool);
+
+   /* This is the simple case: The caller guarantees that we can safely
+* access the free list.
+*/
+   elt->next = pool->free;
+   pool->free = elt;
+}
+
 /**
  * Allocate an object from the slab. Single-threaded (no mutex).
  */
diff --git a/src/util/slab.h b/src/util/slab.h
index 5a25adaf7f4..9748cd95858 100644
--- a/src/util/slab.h
+++ b/src/util/slab.h
@@ -78,6 +78,7 @@ void slab_create_child(struct slab_child_pool *pool,
 void slab_destroy_child(struct slab_child_pool *pool);
 void *slab_alloc(struct slab_child_pool *pool);
 void slab_free(struct slab_child_pool *pool, void *ptr);
+void slab_free_fast(struct slab_child_pool *pool, void *ptr);
 
 struct slab_mempool {
struct slab_parent_pool parent;
-- 
2.21.0

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

Re: [Mesa-dev] R: [PATCH 1/2] meson: require libdrm for gallium svga or virgl

[Rob Clark]

Hmm, I don't *think* the freedreno gallium driver itself should depend
on libdrm.  I guess I haven't tried to build without.  What is the
error?

BR,
-R

On Thu, Jul 18, 2019 at 9:43 AM Francesco Ansanelli  wrote:
>
> Dear Alyssa,
>
> Sorry the bothering..
>
> Your patch also added the check for freedreno, but it is not mentioned in the 
> commit message.
> Is it actually what you wanted?
>
> Cheers,
> Francesco
> ___
> 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] [AppVeyor] mesa master #11902 failed

[Rob Clark]

On Thu, Jul 18, 2019 at 4:34 PM Roland Scheidegger  wrote:
>
> Am 16.07.19 um 20:55 schrieb AppVeyor:
> >
> >   Build mesa 11902 failed
> > Commit 856e84083e by Rob Clark <mailto:robdcl...@chromium.org> on
> > 7/15/2019 4:05 PM:
> > mesa/st: add sampler uniforms\n\nAdd sampler uniforms for the UV
> > plane(s), so driver can count the\nuniforms and get the correct sampler
> > count.\n\nFixes lowered YUV on a6xx which actually wants to know # of
> > samplers.\n\nSigned-off-by: Rob Clark
> > \nReviewed-by: Kristian H. Kristensen
> > \nReviewed-by: Eric Anholt 
> >
>
> Apparently this commit broke windows builds...
>

Hmm, really no asprintf() on windows?

Is there some place we can add an asprintf() in mesa for windows builds?

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

Re: [Mesa-dev] [PATCH 2/2] mesa: Add ir3/ir3_nir_imul.c generation to Android.mk

[Rob Clark]

On Wed, Jul 3, 2019 at 4:10 PM John Stultz  wrote:
>
> With current master we're seeing build failures with AOSP:
>   error: undefined symbol: ir3_nir_lower_imul
>
> This is due to the ir3_nir_imul.c file not being generated
> in the Android.mk files.
>
> This patch simply adds it to the Android build, after which
> thigns build and boot ok on db410c.
>
> Cc: Rob Clark 
> Cc: Emil Velikov 
> Cc: Amit Pundir 
> Cc: Sumit Semwal 
> Cc: Alistair Strachan 
> Cc: Greg Hartman 
> Cc: Tapani Pälli 
> Signed-off-by: John Stultz 


Reviewed-by: Rob Clark 

> ---
>  src/freedreno/Makefile.sources   | 3 ++-
>  src/gallium/drivers/freedreno/Android.gen.mk | 7 +++
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/src/freedreno/Makefile.sources b/src/freedreno/Makefile.sources
> index d8aaf2caecc..75ec361663b 100644
> --- a/src/freedreno/Makefile.sources
> +++ b/src/freedreno/Makefile.sources
> @@ -48,7 +48,8 @@ ir3_SOURCES := \
> ir3/ir3_sun.c
>
>  ir3_GENERATED_FILES := \
> -   ir3/ir3_nir_trig.c
> +   ir3/ir3_nir_trig.c \
> +   ir3/ir3_nir_imul.c
>
>  registers_FILES := \
> registers/a2xx.xml.h \
> diff --git a/src/gallium/drivers/freedreno/Android.gen.mk 
> b/src/gallium/drivers/freedreno/Android.gen.mk
> index d29ba159d5c..1d3ee5ff856 100644
> --- a/src/gallium/drivers/freedreno/Android.gen.mk
> +++ b/src/gallium/drivers/freedreno/Android.gen.mk
> @@ -28,11 +28,18 @@ ir3_nir_trig_deps := \
> $(MESA_TOP)/src/freedreno/ir3/ir3_nir_trig.py \
> $(MESA_TOP)/src/compiler/nir/nir_algebraic.py
>
> +ir3_nir_imul_deps := \
> +   $(MESA_TOP)/src/freedreno/ir3/ir3_nir_imul.py
> +
>  intermediates := $(call local-generated-sources-dir)
>
>  $(intermediates)/ir3/ir3_nir_trig.c: $(ir3_nir_trig_deps)
> @mkdir -p $(dir $@)
> $(hide) $(MESA_PYTHON2) $< -p $(MESA_TOP)/src/compiler/nir > $@
>
> +$(intermediates)/ir3/ir3_nir_imul.c: $(ir3_nir_imul_deps)
> +   @mkdir -p $(dir $@)
> +   $(hide) $(MESA_PYTHON2) $< -p $(MESA_TOP)/src/compiler/nir > $@
> +
>  LOCAL_GENERATED_SOURCES += $(addprefix $(intermediates)/, \
> $(ir3_GENERATED_FILES))
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] What does WIP really mean in an MR?

[Rob Clark]

I had interpreted it as literally the "block the gitlab merge button"
option, ie. "I want to get feedback but it is not ready to merge and
I'll drop the WIP tag when I think it is"..

(comments inline)

On Fri, Jun 28, 2019 at 5:12 PM Ian Romanick  wrote:
>
> After a conversation yesterday with a couple of the other Intel devs,
> I've come to the conclusion that *everyone* interprets WIP to mean
> something different.  I heard no less than four interpretations.
>
> * This series is good.  It hasn't been reviewed, so don't click "merge."

isn't that the point of a MR.. doesn't seem like a reason for "WIP"

> * This series has some sketchy bits.  It probably isn't ready for review
> unless you've been tagged for design feedback.

I guess I'd also use WIP for "I want some early feedback, but it isn't
ready yet".. but in this case I'd also poke people who I wanted to
look at it

> * This series has been reviewed.  Incorporation of detailed feedback is
> in progress, but it's going to take some time.

I suppose also a case for "WIP"..

> * This series is good, but there are some questionable patches at the end.

I guess in this case, I'd reform things into multiple MR's, one with
the parts ready to go, and one w/ the remaining WIP bits

BR,
-R

> Due to this lack of common understanding, we discovered at least one MR
> that was ready to go but had been ignored for months. :(  This makes me
> wonder if other MRs have similarly languished for no good reason.
>
> Can we formulate some guidelines for how people should apply WIP to
> their MRs and how people should interpret WIP when they see it on an MR?
> ___
> 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] renderdoc-traces: like shader-db for runtime

[Rob Clark]

On Mon, Jun 24, 2019 at 11:48 AM Eric Anholt  wrote:
>
> Rob Clark  writes:
>
> > On Thu, Jun 20, 2019 at 12:26 PM Eric Anholt  wrote:
> >
> > (tbh I've not really played w/ renderdoc yet.. I should probably do so..)
> >
> >>   - Mozilla folks tell me that firefox's WebRender display lists can be
> >> captured in browser and then replayed from the WR repo under
> >> apitrace or rendredoc.
> >>
> >>   - I tried capturing Mozilla's new Pathfinder (think SVG renderer), but
> >> it wouldn't play the demo under renderdoc.
> >>
> >>   Do you have some apps that should be represented here?
> >>
> >> - Add microbenchmarks?  Looks like it would be pretty easy to grab
> >>   piglit drawoverhead results, not using renderdoc.  Capturing from
> >>   arbitrary apps expands the scope of the repo in a way I'm not sure I'm
> >>   excited about (Do we do different configs in those apps?  Then we need
> >>   config infrastructure.  Ugh).
> >>
> >> - I should probably add an estimate of "does this overall improve or
> >>   hurt perf?"  Yay doing more stats.
> >>
> >> - I'd love to drop scipy.  I only need it for stats.t.ppf, but it
> >>   prevents me from running run.py directly on my targets.
> >
> > thoughts about adding amd_perfcntr/etc support?  I guess some of the
> > perfcntrs we have perhaps want some post-processing to turn into
> > usuable numbers, and plenty of them we don't know much about what they
> > are other than the name.  But some of them are easy enough to
> > understand (like # of fs ALU cycles, etc), and being able to compare
> > that before/after shader optimizations seems useful.
>
> I'm not coming up with a good usecase for that, myself -- shader-db
> gives me a reasonable proxy for ALU cycles, and we've got wall time for
> a frame from this new tool, so perf counters would let me
> measure... maybe something like cycles spent in shader including stalls
> (think an optimization like GCM where shader-db analysis is unsuitable)
> but avoiding the rest of the noise introduced from CPU side costs and
> scheduling of jobs onto the GPU?

I suspect it would be useful in cases where we shift one bottleneck to another..

anyways, I think it is something that could be done generically (ie.
cmdline arg to ask for various counters by name).. that isn't to say
that this isn't already pretty useful as-is, but I guess adding
perfcntrs is probably something I'd do sooner or later..

BR,
-R

> Running my current perf analysis overnight feels a lot easier than
> trying to add configuration to capture specific GPU perf counters to the
> tool.  :)
>
> > Also, it would be nice to have a way to extract "slow frames" somehow
> > (maybe out of scope for this tool, but related?).. ie. when framerate
> > suddenly drops, those are the frames we probably want to look at more
> > closely..
>
> Renderdoc lets you capture a series of frames, so I guess you could do
> that and pick out your slow one?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

[Rob Clark]

On Thu, Jun 20, 2019 at 12:26 PM Eric Anholt  wrote:
>
> Hey folks, I wanted to show you this follow-on to shader-db I've been
> working on:
>
> https://gitlab.freedesktop.org/anholt/renderdoc-traces
>
> For x86 development I've got a collection of ad-hoc scripts to capture
> FPS numbers from various moderately interesting open source apps so I
> could compare-perf them.  I was only looking at specific apps when they
> seemed relevant, so it would be easy to miss regressions.
>
> Starting work on freedreno, one of the first questions I ran into was
> "does this change to the command stream make the driver faster?".  I
> don't have my old set of apps on my debian ARM systems, and even less so
> for Chrome OS.  Ultimately, users will be judging us based on web
> browser and android app performance, not whatever I've got laying around
> on my debian system.  And, I'd love to fix that "I ignore apps unless I
> think of them" thing.
>
> So, I've used renderdoc to capture some traces from Android apps.  With
> an unlocked phone, it's pretty easy.  Tossing those in a repo (not
> shared here), I can then run driver changes past them to see what
> happens.  See
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1134 for some
> results.
>
> Where is this repo going from here?
>
> - I add a runner for doing frame-to-frame consistency tests.  We could
>   catch UB in a lot of circumstances by replaying a few times and making
>   sure that results are consistent.  Comparing frames between drivers
>   might also be interesting, though for that you would need human
>   validation since pixel values and pixels lit will change on many
>   shader optimization changes.
>
> - Need to collect more workloads for the public repo:
>
>   - I've tried to capture webgl on Chrome and Firefox on Linux with no
> luck. WebGL on ff is supposed to work under apitrace, maybe I could
> do that and then replay on top of renderdoc to capture.

perhaps worth a try capturing these on android?

I have managed to apitrace chromium-browser in the past.. it ends up a
bit weird because there are multiple contexts, but apitrace has
managed to replay them.  Maybe the multiple ctx thing is confusing
renderdoc?

(tbh I've not really played w/ renderdoc yet.. I should probably do so..)

>   - Mozilla folks tell me that firefox's WebRender display lists can be
> captured in browser and then replayed from the WR repo under
> apitrace or rendredoc.
>
>   - I tried capturing Mozilla's new Pathfinder (think SVG renderer), but
> it wouldn't play the demo under renderdoc.
>
>   Do you have some apps that should be represented here?
>
> - Add microbenchmarks?  Looks like it would be pretty easy to grab
>   piglit drawoverhead results, not using renderdoc.  Capturing from
>   arbitrary apps expands the scope of the repo in a way I'm not sure I'm
>   excited about (Do we do different configs in those apps?  Then we need
>   config infrastructure.  Ugh).
>
> - I should probably add an estimate of "does this overall improve or
>   hurt perf?"  Yay doing more stats.
>
> - I'd love to drop scipy.  I only need it for stats.t.ppf, but it
>   prevents me from running run.py directly on my targets.

thoughts about adding amd_perfcntr/etc support?  I guess some of the
perfcntrs we have perhaps want some post-processing to turn into
usuable numbers, and plenty of them we don't know much about what they
are other than the name.  But some of them are easy enough to
understand (like # of fs ALU cycles, etc), and being able to compare
that before/after shader optimizations seems useful.

Also, it would be nice to have a way to extract "slow frames" somehow
(maybe out of scope for this tool, but related?).. ie. when framerate
suddenly drops, those are the frames we probably want to look at more
closely..

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

Re: [Mesa-dev] Proposal for the future of www.mesa3d.org

[Rob Clark]

On Fri, Jun 21, 2019 at 7:01 AM Erik Faye-Lund
 wrote:
>
> A while back, Laura and Jean was working on a Sphinx-conversion of the
> mesa-documentation. Sadly this work stranded due to it also trying to
> move to using GitLab Pages for hosting www.mesa3d.org, and because the
> documentation and the websit eis the same thing, this lead to problems
> with hosting the release-archive (www.mesa3d.org/archive/).
>
> Since then, I've taken a look at trying to revive this work. So far,
> I've taken most of the changed Laura did to the website post-RST
> conversion, and performed them before instead. I've also automated more
> of the conversion process, so we can easier get an up-to-date
> conversion. The result can be viewed here:
>
> https://kusma.pages.freedesktop.org/mesa/
> https://gitlab.freedesktop.org/kusma/mesa/tree/docs-sphinx-v2
>
> Please note that there's some differences:
> - I don't do any "mesa-specific styling". This can be done on top if
> needed, simply by cherry-picking Laura's commits for this. But I'm not
> sure we need it, more about this further down.
> - Some of the commit history might be incorrectly attributed to me
> instead of Laura. I intend to fix this up before upstreaming anything
> here.
> - The conversion isn't entirely up-to-date, but it's *fairly* recent.
>
> So yeah, the big elephant in the room is what to do with
> www.mesa3d.org/archive. This is where I have an alternative suggestion:
>
> How about we split the documentation and the website into two sites,
> www.mesa3d.org and docs.mesa3d.org, and maintain the website in a
> separate repository? We would of course have to set up some redirects
> to make old URLs point to the latest version (at least for a transition
> period).
>
> This has some additional benefits:
> - We don't need to push things to master to update things like news,
> that aren't really related to the code.
> - We can separate information that is technical documentation from
> information that are is "project marketing".
> - ...And because we don't need for the docs to appeal as "project
> marketing", we can keep the neutral readthedocs theme as-is, as it's a
> bit more easy on the eye IMO.
> - It makes the article index a bit more logical, as there's a few
> articles that doesn't really make sense to read after you already have
> the source tree. Why would you wonder who the webmaster is
> (docs/webmaster.html) or where to download mesa (docs/download.html)
> when reading the source?
> - We can host docs.mesa3d.org using GitLab pages (or point it to
> something like readthedocs.org) without having to change the hosting
> for www.mesa3d.org.
>
> In addition to this, I've also had a look at modernizing www.mesa.org
> as well, and I've made a proposal for a new, responisive website:
>
> https://kusma.pages.freedesktop.org/
> https://gitlab.freedesktop.org/kusma/kusma.pages.freedesktop.org/

I don't have too much intelligent to add, but:

* I'm glad someone is picking this up again
* split of docs.mesa3d.org seems fine if it simplifies things logistically
* new front page looks nice and I'm glad it kept this spinning gears
easter egg :-)

BR,
-R

>
> Quite a few things to notice:
> - Many links here forward to docs.mesa3d.org, which doesn't exist yet.
> - The redirects are done using meta-refresh tags instead of HTTP
> redirects, so they will only be redirected by an actual user-agent, not
> by curl or wget.
> - The site is using logos of Khronos APIs which might not be OK without
> approval. The legality of this needs to be researched.
> - Most of the content here is "usable placeholder" text, but by no
> means final. For instance, the descriptions of the APIs and drivers
> probably needs work. Especially the driver-decription should probably
> be written by the driver-teams rather than me.
> - Some drivers are missing. I just didn't bother writing more
> placeholder.
> - What content goes in which site is by no means decided on.
> - Some content isn't yet in either site; in particular, non-html files,
> like for instance the contents of www.mesa3d.org/specs. And since
> GitLab pages doesn't do directory listings, that folder (regardless of
> where it'd be reciding) would need an index added.
> - The site is made using Jekyll, but any static-site generator would
> do, really.
>
> The redirect-issue is due to the prototype currently being hosted in
> GitLab pages, and is a GitLab pages limitation. See
> https://gitlab.com/gitlab-org/gitlab-pages/issues/24 for more details.
> I doubt this would be a problem for documentation, but the same
> approach won't work for www.mesa3d.org/archive. Without solving that
> problem, we can't really go live with this while hosting it on GitLab
> pages.
>
> But we could go forward *without* hosting www.mesa3d.org in GitLab
> pages in the short term. I don't know how we currently deploy the
> website, I guess that's done manually by someone at some points? If so,
> we'd just update the manual recipie, I guess.
>
> I think the 

[Mesa-dev] [PATCH] gallium: add z24s8_as_r8g8b8a8 format

[Rob Clark]

From: Rob Clark 

This maps to a special format that recent generations of adreno have,
for blitting z24s8.  Conceptually it is similar to doing Z and/or S
blits by pretending it is r8g8b8a8 (with appropriate writemask).  But
it differs when bandwidth compression is used, as z24 is a different
type from r8g8b8.

Signed-off-by: Rob Clark 
---
This is part of:

  https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1088

but sending to list to give better visibility.

 src/gallium/auxiliary/util/u_format.csv | 7 +++
 src/gallium/drivers/svga/svga_format.c  | 1 +
 src/gallium/include/pipe/p_format.h | 2 ++
 3 files changed, 10 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_format.csv 
b/src/gallium/auxiliary/util/u_format.csv
index 51a08bd6530..039b5fa9141 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/auxiliary/util/u_format.csv
@@ -144,6 +144,13 @@ PIPE_FORMAT_X8Z24_UNORM , plain, 1, 1, x8  , 
un24, , , y___,
 PIPE_FORMAT_Z32_FLOAT_S8X24_UINT, plain, 1, 1, f32 , up8 ,  x24, , 
xy__, zs,f32 , x24 ,  up8, , xz__
 PIPE_FORMAT_X32_S8X24_UINT  , plain, 1, 1, x32 , up8 ,  x24, , 
_y__, zs,x32 , x24 ,  up8, , _z__
 
+# Depth-stencil formats equivalent to blitting PIPE_FORMAT_Z24_UNORM_S8_UINT
+# as PIPE_FORMAT_R8G8B8A8_*, in that it is an equivalent size to the z/s
+# format.  This is mainly for hw that has some sort of bandwidth compressed
+# format where the compression for z24s8 is not equivalent to r8g8b8a8,
+# and therefore some special handling is required for blits.
+PIPE_FORMAT_Z24_UNORM_S8_UINT_AS_R8G8B8A8 , plain, 1, 1, un8 , un8 , un8 , un8 
, xyzw, rgb
+
 # YUV formats
 # http://www.fourcc.org/yuv.php#UYVY
 PIPE_FORMAT_UYVY , subsampled, 2, 1, x32 , , , , 
xyz1, yuv
diff --git a/src/gallium/drivers/svga/svga_format.c 
b/src/gallium/drivers/svga/svga_format.c
index 830ff0a1e6b..84134018c17 100644
--- a/src/gallium/drivers/svga/svga_format.c
+++ b/src/gallium/drivers/svga/svga_format.c
@@ -378,6 +378,7 @@ static const struct vgpu10_format_entry 
format_conversion_table[] =
{ PIPE_FORMAT_ATC_RGB,   SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   SVGA3D_FORMAT_INVALID,   0 },
{ PIPE_FORMAT_ATC_RGBA_EXPLICIT, SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   SVGA3D_FORMAT_INVALID,   0 },
{ PIPE_FORMAT_ATC_RGBA_INTERPOLATED, SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   SVGA3D_FORMAT_INVALID,   0 },
+   { PIPE_FORMAT_Z24_UNORM_S8_UINT_AS_R8G8B8A8, SVGA3D_FORMAT_INVALID, 
SVGA3D_FORMAT_INVALID,SVGA3D_FORMAT_INVALID,   0 },
 };
 
 
diff --git a/src/gallium/include/pipe/p_format.h 
b/src/gallium/include/pipe/p_format.h
index a4401658f5f..42908e9a720 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -407,6 +407,8 @@ enum pipe_format {
PIPE_FORMAT_ATC_RGBA_EXPLICIT   = 318,
PIPE_FORMAT_ATC_RGBA_INTERPOLATED   = 319,
 
+   PIPE_FORMAT_Z24_UNORM_S8_UINT_AS_R8G8B8A8 = 320,
+
PIPE_FORMAT_COUNT
 };
 
-- 
2.20.1

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

Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX

[Rob Clark]

On Mon, Jun 10, 2019 at 6:52 PM Brian Masney  wrote:
>
> Hi Rob,
>
> On Mon, Jun 10, 2019 at 05:10:45PM -0700, Rob Clark wrote:
> > On Mon, Jun 10, 2019 at 3:54 PM Brian Masney  wrote:
> > >
> > > On Mon, Jun 10, 2019 at 06:58:30AM -0700, Rob Clark wrote:
> > > > On Mon, Jun 10, 2019 at 6:53 AM Rob Clark  wrote:
> > > > >
> > > > > On Sat, Jun 8, 2019 at 6:08 PM Brian Masney  
> > > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm trying to get the GPU working using the Freedreno driver (A330) 
> > > > > > on
> > > > > > the Nexus 5 phone. I'm using kernel 5.2rc3 with some out of tree 
> > > > > > patches
> > > > > > related to the GPU [1] and mesa 19.1.0-rc5 on postmarketOS. When I 
> > > > > > run
> > > > > > glxgears, I see the gears show up for a fraction of a second and 
> > > > > > then
> > > > > > it terminates due to the following error:
> > > > > >
> > > > > > -
> > > > > > shader: MESA_SHADER_FRAGMENT
> > > > > > inputs: 1
> > > > > > outputs: 1
> > > > > > uniforms: 0
> > > > > > shared: 0
> > > > > > decl_var uniform INTERP_MODE_NONE sampler2D sampler (0, 0, 0)
> > > > > > decl_var shader_in INTERP_MODE_SMOOTH vec4 in_0 (VARYING_SLOT_VAR0, 
> > > > > > 0, 0)
> > > > > > decl_var shader_out INTERP_MODE_FLAT vec4 out_0 (FRAG_RESULT_DATA0, 
> > > > > > 0, 0)
> > > > > > decl_function main (0 params)
> > > > > >
> > > > > > impl main {
> > > > > > block block_0:
> > > > > > /* preds: */
> > > > > > vec1 32 ssa_0 = load_const (0x /* 0.00 */)
> > > > > > vec2 32 ssa_1 = intrinsic load_barycentric_pixel () (1) /* 
> > > > > > interp_mode=1 */
> > > > > > vec4 32 ssa_2 = intrinsic load_interpolated_input (ssa_1, 
> > > > > > ssa_0) (0, 0) /* base=0 */ /* component=0 */  /* in_0 */
> > > > > > vec1 32 ssa_3 = deref_var  (uniform sampler2D)
> > > > > > vec2 32 ssa_4 = vec2 ssa_2.x, ssa_2.y
> > > > > > vec4 32 ssa_5 = tex ssa_3 (texture_deref), ssa_3 
> > > > > > (sampler_deref), ssa_4 (coord)
> > > > > > Unhandled NIR tex src type: 11
> > > > >
> > > > > This should be getting lowered somewhere..  and I don't *think* it
> > > > > should be a3xx specific.
> > > >
> > > > It should be getting lowered in gl_nir_lower_samplers().. which should
> > > > be called from mesa/st before the driver even sees this shader.
> > > >
> > > > Could you build mesa from git w/ latest 19.1, I guess this must have
> > > > been fixed by now, since other drivers that use nir would hit the same
> > > > issue.
> > >
> > > This error doesn't happen on X11 using the mesa master branch. Instead,
> > > I get the following error on that branch:
> > >
> > > ../src/gallium/drivers/freedreno/freedreno_batch.c:424:fd_batch_add_dep: 
> > > Assertion `!batch_depends_on(dep, batch)' failed.
> > >
> > > Full disclosure though: I rebuilt the mesa package using the
> > > postmarketOS packaging yesterday and it includes a few extra patches for
> > > musl libc.
> > >
> > > https://gitlab.com/postmarketOS/pmaports/tree/master/temp/mesa
> >
> >
> > I don't see anything obvious in those patches that would be related..
> > but I suspect this type of error is going to be timing related.
> > (Which could ofc be due to musl or something else)
> >
> > but a bit surprised debug_assert() is enabled in debug builds.. it
> > would probably be a "harmless" situation if asserts were not enabled.
> >
> > (note that I do most of my testing with debug builds with asserts
> > enabled.. this is the type of thing that I want to see and fix.. but
> > probably shouldn't matter to end users)
>
> I recompiled the master branch of mesa in pmOS with '-Db_ndebug=true'
> and X11 is now working properly on the Nexus 5. glxgears averages about
> 59.5 FPS. I'll add a bug report with pmOS to have them add that flag to
> their mesa build. Fedora added that flag to their builds:
> https://bugzilla.redhat.com/show_bug.cgi?id=1692426
>
> 19.1.0-rc5 still doesn't work for me due to the original error.
>

fwiw, vblank_mode=0 will make glxgears about a bazzilion times faster
(otoh glxgears really is a horrible benchmark.. but either way w/out
vblank_mode=0 it will be limited to screen refresh rate)

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

Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX

[Rob Clark]

On Mon, Jun 10, 2019 at 3:54 PM Brian Masney  wrote:
>
> On Mon, Jun 10, 2019 at 06:58:30AM -0700, Rob Clark wrote:
> > On Mon, Jun 10, 2019 at 6:53 AM Rob Clark  wrote:
> > >
> > > On Sat, Jun 8, 2019 at 6:08 PM Brian Masney  wrote:
> > > >
> > > > Hi,
> > > >
> > > > I'm trying to get the GPU working using the Freedreno driver (A330) on
> > > > the Nexus 5 phone. I'm using kernel 5.2rc3 with some out of tree patches
> > > > related to the GPU [1] and mesa 19.1.0-rc5 on postmarketOS. When I run
> > > > glxgears, I see the gears show up for a fraction of a second and then
> > > > it terminates due to the following error:
> > > >
> > > > -
> > > > shader: MESA_SHADER_FRAGMENT
> > > > inputs: 1
> > > > outputs: 1
> > > > uniforms: 0
> > > > shared: 0
> > > > decl_var uniform INTERP_MODE_NONE sampler2D sampler (0, 0, 0)
> > > > decl_var shader_in INTERP_MODE_SMOOTH vec4 in_0 (VARYING_SLOT_VAR0, 0, 
> > > > 0)
> > > > decl_var shader_out INTERP_MODE_FLAT vec4 out_0 (FRAG_RESULT_DATA0, 0, 
> > > > 0)
> > > > decl_function main (0 params)
> > > >
> > > > impl main {
> > > > block block_0:
> > > > /* preds: */
> > > > vec1 32 ssa_0 = load_const (0x /* 0.00 */)
> > > > vec2 32 ssa_1 = intrinsic load_barycentric_pixel () (1) /* 
> > > > interp_mode=1 */
> > > > vec4 32 ssa_2 = intrinsic load_interpolated_input (ssa_1, 
> > > > ssa_0) (0, 0) /* base=0 */ /* component=0 */  /* in_0 */
> > > > vec1 32 ssa_3 = deref_var  (uniform sampler2D)
> > > > vec2 32 ssa_4 = vec2 ssa_2.x, ssa_2.y
> > > > vec4 32 ssa_5 = tex ssa_3 (texture_deref), ssa_3 
> > > > (sampler_deref), ssa_4 (coord)
> > > > Unhandled NIR tex src type: 11
> > >
> > > This should be getting lowered somewhere..  and I don't *think* it
> > > should be a3xx specific.
> >
> > It should be getting lowered in gl_nir_lower_samplers().. which should
> > be called from mesa/st before the driver even sees this shader.
> >
> > Could you build mesa from git w/ latest 19.1, I guess this must have
> > been fixed by now, since other drivers that use nir would hit the same
> > issue.
>
> This error doesn't happen on X11 using the mesa master branch. Instead,
> I get the following error on that branch:
>
> ../src/gallium/drivers/freedreno/freedreno_batch.c:424:fd_batch_add_dep: 
> Assertion `!batch_depends_on(dep, batch)' failed.
>
> Full disclosure though: I rebuilt the mesa package using the
> postmarketOS packaging yesterday and it includes a few extra patches for
> musl libc.
>
> https://gitlab.com/postmarketOS/pmaports/tree/master/temp/mesa


I don't see anything obvious in those patches that would be related..
but I suspect this type of error is going to be timing related.
(Which could ofc be due to musl or something else)

but a bit surprised debug_assert() is enabled in debug builds.. it
would probably be a "harmless" situation if asserts were not enabled.

(note that I do most of my testing with debug builds with asserts
enabled.. this is the type of thing that I want to see and fix.. but
probably shouldn't matter to end users)

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

Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX

[Rob Clark]

On Sun, Jun 9, 2019 at 7:43 AM Jonathan Marek  wrote:
>
> On 6/9/19 8:41 AM, Brian Masney wrote:
> > On Sat, Jun 08, 2019 at 10:58:11PM -0400, Jonathan Marek wrote:
> >> Hi,
> >>
> >> It's possible 19.1 has another issue, I only tested the master branch with
> >> my fix. I would suggest trying 19.0 or the master branch.
> >
> > The mesa master branch and 19.0.6 both give the following error when
> > glxgears starts up:
> >
> > ../src/gallium/drivers/freedreno/freedreno_batch.c:424:fd_batch_add_dep: 
> > Assertion `!batch_depends_on(dep, batch)' failed.
> >
>
> No one is testing freedreno+X11 AFAIK. This would affect all adrenos
> too, not just a3xx. I can look into it at some point, if no one else does.

This one could be timing related, I suppose.. that would be my best
guess about why I haven't seen it..

BR,
-R

>
> To test if the GPU works at all you should use kmscube. If that works
> then you can try wayland/weston, or if you really need X11 IIRC 18.1 was
> working with X11.
>
> >> FYI, I haven't pushed it anywhere but I recently rebased my Nexus 5 patches
> >> from last year (and been looking at getting call audio working).
> >
> > Fantastic!
> >
> > Brian
> >
> >
> >
> >> On 6/8/19 9:08 PM, Brian Masney wrote:
> >>> Hi,
> >>>
> >>> I'm trying to get the GPU working using the Freedreno driver (A330) on
> >>> the Nexus 5 phone. I'm using kernel 5.2rc3 with some out of tree patches
> >>> related to the GPU [1] and mesa 19.1.0-rc5 on postmarketOS. When I run
> >>> glxgears, I see the gears show up for a fraction of a second and then
> >>> it terminates due to the following error:
> >>>
> >>> -
> >>> shader: MESA_SHADER_FRAGMENT
> >>> inputs: 1
> >>> outputs: 1
> >>> uniforms: 0
> >>> shared: 0
> >>> decl_var uniform INTERP_MODE_NONE sampler2D sampler (0, 0, 0)
> >>> decl_var shader_in INTERP_MODE_SMOOTH vec4 in_0 (VARYING_SLOT_VAR0, 0, 0)
> >>> decl_var shader_out INTERP_MODE_FLAT vec4 out_0 (FRAG_RESULT_DATA0, 0, 0)
> >>> decl_function main (0 params)
> >>>
> >>> impl main {
> >>>   block block_0:
> >>>   /* preds: */
> >>>   vec1 32 ssa_0 = load_const (0x /* 0.00 */)
> >>>   vec2 32 ssa_1 = intrinsic load_barycentric_pixel () (1) /* 
> >>> interp_mode=1 */
> >>>   vec4 32 ssa_2 = intrinsic load_interpolated_input (ssa_1, 
> >>> ssa_0) (0, 0) /* base=0 */ /* component=0 */  /* in_0 */
> >>>   vec1 32 ssa_3 = deref_var  (uniform sampler2D)
> >>>   vec2 32 ssa_4 = vec2 ssa_2.x, ssa_2.y
> >>>   vec4 32 ssa_5 = tex ssa_3 (texture_deref), ssa_3 
> >>> (sampler_deref), ssa_4 (coord)
> >>> Unhandled NIR tex src type: 11
> >>>
> >>>
> >>>   intrinsic store_output (ssa_5, ssa_0) (0, 15, 0) /* base=0 */ 
> >>> /* wrmask=xyzw */ /* component=0 */   /* out_0 */
> >>>   /* succs: block_1 */
> >>>   block block_1:
> >>> }
> >>>
> >>> Assertion failed: !"" (../src/freedreno/ir3/ir3_context.c: 
> >>> ir3_context_error: 407)
> >>> -
> >>>
> >>> I verified that the mesa 19.1.0-rc5 release contains this recent a3xx
> >>> fix from Jonathan:
> >>> https://gitlab.freedesktop.org/mesa/mesa/commit/1db86d8b62860380c34af77ae62b019ed2376443
> >>>
> >>> Any suggestions?
> >>>
> >>> [1] https://github.com/masneyb/linux/commits/v5.2-rc3-nexus5-gpu-wip
> >>>   The GPU specific patches start at Rob's patch 'qcom-scm: add support
> >>>   to restore secure config' on that list. I submitted the patches
> >>>   below that a few weeks ago to the upstream kernel and I expect
> >>>   they'll be merged. Once I have a working GPU, I plan to start
> >>>   working on the interconnect support in the kernel for msm8974 so
> >>>   that the clock hacks can be dropped.
> >>>
> >>> Brian
> >>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX

[Rob Clark]

On Mon, Jun 10, 2019 at 6:53 AM Rob Clark  wrote:
>
> On Sat, Jun 8, 2019 at 6:08 PM Brian Masney  wrote:
> >
> > Hi,
> >
> > I'm trying to get the GPU working using the Freedreno driver (A330) on
> > the Nexus 5 phone. I'm using kernel 5.2rc3 with some out of tree patches
> > related to the GPU [1] and mesa 19.1.0-rc5 on postmarketOS. When I run
> > glxgears, I see the gears show up for a fraction of a second and then
> > it terminates due to the following error:
> >
> > -
> > shader: MESA_SHADER_FRAGMENT
> > inputs: 1
> > outputs: 1
> > uniforms: 0
> > shared: 0
> > decl_var uniform INTERP_MODE_NONE sampler2D sampler (0, 0, 0)
> > decl_var shader_in INTERP_MODE_SMOOTH vec4 in_0 (VARYING_SLOT_VAR0, 0, 0)
> > decl_var shader_out INTERP_MODE_FLAT vec4 out_0 (FRAG_RESULT_DATA0, 0, 0)
> > decl_function main (0 params)
> >
> > impl main {
> > block block_0:
> > /* preds: */
> > vec1 32 ssa_0 = load_const (0x /* 0.00 */)
> > vec2 32 ssa_1 = intrinsic load_barycentric_pixel () (1) /* 
> > interp_mode=1 */
> > vec4 32 ssa_2 = intrinsic load_interpolated_input (ssa_1, ssa_0) 
> > (0, 0) /* base=0 */ /* component=0 */  /* in_0 */
> > vec1 32 ssa_3 = deref_var  (uniform sampler2D)
> > vec2 32 ssa_4 = vec2 ssa_2.x, ssa_2.y
> > vec4 32 ssa_5 = tex ssa_3 (texture_deref), ssa_3 (sampler_deref), 
> > ssa_4 (coord)
> > Unhandled NIR tex src type: 11
>
> This should be getting lowered somewhere..  and I don't *think* it
> should be a3xx specific.

It should be getting lowered in gl_nir_lower_samplers().. which should
be called from mesa/st before the driver even sees this shader.

Could you build mesa from git w/ latest 19.1, I guess this must have
been fixed by now, since other drivers that use nir would hit the same
issue.

BR,
-R

>
> btw, I am testing on x11 fairly regularly.. but mostly w/ a5xx and
> a6xx these days, and with mesa master.
>
> BR,
> -R
>
> >
> >
> > intrinsic store_output (ssa_5, ssa_0) (0, 15, 0) /* base=0 */ /* 
> > wrmask=xyzw */ /* component=0 */   /* out_0 */
> > /* succs: block_1 */
> > block block_1:
> > }
> >
> > Assertion failed: !"" (../src/freedreno/ir3/ir3_context.c: 
> > ir3_context_error: 407)
> > -
> >
> > I verified that the mesa 19.1.0-rc5 release contains this recent a3xx
> > fix from Jonathan:
> > https://gitlab.freedesktop.org/mesa/mesa/commit/1db86d8b62860380c34af77ae62b019ed2376443
> >
> > Any suggestions?
> >
> > [1] https://github.com/masneyb/linux/commits/v5.2-rc3-nexus5-gpu-wip
> > The GPU specific patches start at Rob's patch 'qcom-scm: add support
> > to restore secure config' on that list. I submitted the patches
> > below that a few weeks ago to the upstream kernel and I expect
> > they'll be merged. Once I have a working GPU, I plan to start
> > working on the interconnect support in the kernel for msm8974 so
> > that the clock hacks can be dropped.
> >
> > Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX

[Rob Clark]

On Sat, Jun 8, 2019 at 6:08 PM Brian Masney  wrote:
>
> Hi,
>
> I'm trying to get the GPU working using the Freedreno driver (A330) on
> the Nexus 5 phone. I'm using kernel 5.2rc3 with some out of tree patches
> related to the GPU [1] and mesa 19.1.0-rc5 on postmarketOS. When I run
> glxgears, I see the gears show up for a fraction of a second and then
> it terminates due to the following error:
>
> -
> shader: MESA_SHADER_FRAGMENT
> inputs: 1
> outputs: 1
> uniforms: 0
> shared: 0
> decl_var uniform INTERP_MODE_NONE sampler2D sampler (0, 0, 0)
> decl_var shader_in INTERP_MODE_SMOOTH vec4 in_0 (VARYING_SLOT_VAR0, 0, 0)
> decl_var shader_out INTERP_MODE_FLAT vec4 out_0 (FRAG_RESULT_DATA0, 0, 0)
> decl_function main (0 params)
>
> impl main {
> block block_0:
> /* preds: */
> vec1 32 ssa_0 = load_const (0x /* 0.00 */)
> vec2 32 ssa_1 = intrinsic load_barycentric_pixel () (1) /* 
> interp_mode=1 */
> vec4 32 ssa_2 = intrinsic load_interpolated_input (ssa_1, ssa_0) (0, 
> 0) /* base=0 */ /* component=0 */  /* in_0 */
> vec1 32 ssa_3 = deref_var  (uniform sampler2D)
> vec2 32 ssa_4 = vec2 ssa_2.x, ssa_2.y
> vec4 32 ssa_5 = tex ssa_3 (texture_deref), ssa_3 (sampler_deref), 
> ssa_4 (coord)
> Unhandled NIR tex src type: 11

This should be getting lowered somewhere..  and I don't *think* it
should be a3xx specific.

btw, I am testing on x11 fairly regularly.. but mostly w/ a5xx and
a6xx these days, and with mesa master.

BR,
-R

>
>
> intrinsic store_output (ssa_5, ssa_0) (0, 15, 0) /* base=0 */ /* 
> wrmask=xyzw */ /* component=0 */   /* out_0 */
> /* succs: block_1 */
> block block_1:
> }
>
> Assertion failed: !"" (../src/freedreno/ir3/ir3_context.c: ir3_context_error: 
> 407)
> -
>
> I verified that the mesa 19.1.0-rc5 release contains this recent a3xx
> fix from Jonathan:
> https://gitlab.freedesktop.org/mesa/mesa/commit/1db86d8b62860380c34af77ae62b019ed2376443
>
> Any suggestions?
>
> [1] https://github.com/masneyb/linux/commits/v5.2-rc3-nexus5-gpu-wip
> The GPU specific patches start at Rob's patch 'qcom-scm: add support
> to restore secure config' on that list. I submitted the patches
> below that a few weeks ago to the upstream kernel and I expect
> they'll be merged. Once I have a working GPU, I plan to start
> working on the interconnect support in the kernel for msm8974 so
> that the clock hacks can be dropped.
>
> Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] freedreno: Fix GCC build error.

[Rob Clark]

On Tue, Jun 4, 2019 at 12:59 AM Juan A. Suarez Romero
 wrote:
>
> On Thu, 2019-05-30 at 21:48 +, Vinson Lee wrote:
> > ../src/freedreno/vulkan/tu_device.c:900:4: error: initializer element is 
> > not constant
> > .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
> > ^
> >
>
> Shouldn't this be nominated to stable?
>

yes, I think so

BR,
-R

>
> J.A.
>
> > Suggested-by: Kristian Høgsberg 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110698
> > Signed-off-by: Vinson Lee 
> > ---
> >  src/freedreno/vulkan/tu_device.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/freedreno/vulkan/tu_device.c 
> > b/src/freedreno/vulkan/tu_device.c
> > index 2e930d9841fe..fdb9e1e0a1e2 100644
> > --- a/src/freedreno/vulkan/tu_device.c
> > +++ b/src/freedreno/vulkan/tu_device.c
> > @@ -897,7 +897,7 @@ static const VkQueueFamilyProperties 
> > tu_queue_family_properties = {
> >VK_QUEUE_GRAPHICS_BIT | VK_QUEUE_COMPUTE_BIT | VK_QUEUE_TRANSFER_BIT,
> > .queueCount = 1,
> > .timestampValidBits = 64,
> > -   .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
> > +   .minImageTransferGranularity = { 1, 1, 1 },
> >  };
> >
> >  void
>
> ___
> 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] freedreno: Fix GCC build error.

[Rob Clark]

On Thu, May 30, 2019 at 2:48 PM Vinson Lee  wrote:
>
> ../src/freedreno/vulkan/tu_device.c:900:4: error: initializer element is not 
> constant
> .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
> ^
>
> Suggested-by: Kristian Høgsberg 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110698
> Signed-off-by: Vinson Lee 

Reviewed-by: Rob Clark 

> ---
>  src/freedreno/vulkan/tu_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/freedreno/vulkan/tu_device.c 
> b/src/freedreno/vulkan/tu_device.c
> index 2e930d9841fe..fdb9e1e0a1e2 100644
> --- a/src/freedreno/vulkan/tu_device.c
> +++ b/src/freedreno/vulkan/tu_device.c
> @@ -897,7 +897,7 @@ static const VkQueueFamilyProperties 
> tu_queue_family_properties = {
>VK_QUEUE_GRAPHICS_BIT | VK_QUEUE_COMPUTE_BIT | VK_QUEUE_TRANSFER_BIT,
> .queueCount = 1,
> .timestampValidBits = 64,
> -   .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
> +   .minImageTransferGranularity = { 1, 1, 1 },
>  };
>
>  void
> --
> 1.8.3.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] list: add some iterator debug

[Rob Clark]

On Mon, May 27, 2019 at 5:06 AM Rob Clark  wrote:
>
> On Mon, May 27, 2019 at 4:39 AM Erik Faye-Lund
>  wrote:
> >
> > On Mon, 2019-05-27 at 13:37 +0200, Erik Faye-Lund wrote:
> > > On Mon, 2019-05-27 at 04:23 -0700, Rob Clark wrote:
> > > > On Mon, May 27, 2019 at 2:50 AM Erik Faye-Lund
> > > >  wrote:
> > > > > On Sat, 2019-05-25 at 15:44 -0700, Rob Clark wrote:
> > > > > > This ends up embedded in a for loop expression, ie. the C part
> > > > > > in
> > > > > > an
> > > > > > for (A;B;C)
> > > > > >
> > > > > > iirc, that means it needs to be a C expr rather than
> > > > > > statement..
> > > > > > or
> > > > > > something roughly like that, I'm too lazy to dig out my C
> > > > > > grammar
> > > > > >
> > > > >
> > > > > Can't you just call a static helper function to do the
> > > > > validation?
> > > > > Function calls are valid expressions...
> > > >
> > > > I do like the fact that with the current patch I get the correct
> > > > line
> > > > # in the assert msg.. but perhaps #ifdef MSVC we can make it a
> > > > static
> > > > inline instead?  I'm not sure how many people do active feature dev
> > > > of
> > > > mesa on windows (as opposed to doing dev on linux and then
> > > > compiling/shipping non-debug builds on windows), so maybe just
> > > > disabling the list debug on MSVC is fine.
> > > >
> > > > BR,
> > > > -R
> >
> > I guess I should also have mentioned that I *do* sometimes do feature
> > development for Mesa on Windows, so I'd really like to get to benefit
> > from debug-helpers.
> >
>
> ok, that  was the answer I was looking for, whether it actually
> benefits anyone to re-invent assert
>

I've pushed a MR[1] with a slightly different solution, but I think
this should work for MSVC

---
#ifdef DEBUG
#  define list_assert(cond, msg)  assert(cond && msg)
#else
#  define list_assert(cond, msg)  (void)(0 && (cond))
#endif
---

[1] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/962
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] list: add some iterator debug

[Rob Clark]

On Mon, May 27, 2019 at 4:39 AM Erik Faye-Lund
 wrote:
>
> On Mon, 2019-05-27 at 13:37 +0200, Erik Faye-Lund wrote:
> > On Mon, 2019-05-27 at 04:23 -0700, Rob Clark wrote:
> > > On Mon, May 27, 2019 at 2:50 AM Erik Faye-Lund
> > >  wrote:
> > > > On Sat, 2019-05-25 at 15:44 -0700, Rob Clark wrote:
> > > > > This ends up embedded in a for loop expression, ie. the C part
> > > > > in
> > > > > an
> > > > > for (A;B;C)
> > > > >
> > > > > iirc, that means it needs to be a C expr rather than
> > > > > statement..
> > > > > or
> > > > > something roughly like that, I'm too lazy to dig out my C
> > > > > grammar
> > > > >
> > > >
> > > > Can't you just call a static helper function to do the
> > > > validation?
> > > > Function calls are valid expressions...
> > >
> > > I do like the fact that with the current patch I get the correct
> > > line
> > > # in the assert msg.. but perhaps #ifdef MSVC we can make it a
> > > static
> > > inline instead?  I'm not sure how many people do active feature dev
> > > of
> > > mesa on windows (as opposed to doing dev on linux and then
> > > compiling/shipping non-debug builds on windows), so maybe just
> > > disabling the list debug on MSVC is fine.
> > >
> > > BR,
> > > -R
>
> I guess I should also have mentioned that I *do* sometimes do feature
> development for Mesa on Windows, so I'd really like to get to benefit
> from debug-helpers.
>

ok, that  was the answer I was looking for, whether it actually
benefits anyone to re-invent assert

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

Re: [Mesa-dev] [PATCH] list: add some iterator debug

[Rob Clark]

On Mon, May 27, 2019 at 2:50 AM Erik Faye-Lund
 wrote:
>
> On Sat, 2019-05-25 at 15:44 -0700, Rob Clark wrote:
> > This ends up embedded in a for loop expression, ie. the C part in an
> > for (A;B;C)
> >
> > iirc, that means it needs to be a C expr rather than statement.. or
> > something roughly like that, I'm too lazy to dig out my C grammar
> >
>
> Can't you just call a static helper function to do the validation?
> Function calls are valid expressions...


I do like the fact that with the current patch I get the correct line
# in the assert msg.. but perhaps #ifdef MSVC we can make it a static
inline instead?  I'm not sure how many people do active feature dev of
mesa on windows (as opposed to doing dev on linux and then
compiling/shipping non-debug builds on windows), so maybe just
disabling the list debug on MSVC is fine.

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

Re: [Mesa-dev] [PATCH] list: add some iterator debug

[Rob Clark]

This ends up embedded in a for loop expression, ie. the C part in an for (A;B;C)

iirc, that means it needs to be a C expr rather than statement.. or
something roughly like that, I'm too lazy to dig out my C grammar

BR,
-R


On Sat, May 25, 2019 at 3:39 PM Ilia Mirkin  wrote:
>
> Why not just do it in a way that works for everyone? Both the do/while
> method and the ifdef-based method that I suggested work everywhere. Or
> is there another reason you prefer to use those statement expressions?
>
> On Sat, May 25, 2019 at 6:21 PM Rob Clark  wrote:
> >
> > Is there a convenient #ifdef I can use to guard the list_assert()
> > macro..  I don't really mind if MSVC can't have this, but would rather
> > not let it prevent the rest of us from having nice things
> >
> > BR,
> > -R
> >
> > On Sat, May 25, 2019 at 1:23 PM Jason Ekstrand  wrote:
> > >
> > > Yeah, that's a GNU extension. It also works in clang but not MSVC which is
> > > used to build NIR.
> > >
> > > On May 25, 2019 13:30:29 Rob Clark  wrote:
> > >
> > > > On Sat, May 25, 2019 at 11:13 AM Ilia Mirkin  
> > > > wrote:
> > > >>
> > > >> On Sat, May 25, 2019 at 2:03 PM Rob Clark  wrote:
> > > >> >
> > > >> > From: Rob Clark 
> > > >> >
> > > >> > Debugging use of unsafe iterators when you should have used the _safe
> > > >> > version sucks.  Add some DEBUG build support to catch and assert if
> > > >> > someone does that.
> > > >> >
> > > >> > I didn't update the UPPERCASE verions of the iterators.  They should
> > > >> > probably be deprecated/removed.
> > > >> >
> > > >> > Signed-off-by: Rob Clark 
> > > >> > ---
> > > >> >  src/util/list.h | 23 ++-
> > > >> >  1 file changed, 18 insertions(+), 5 deletions(-)
> > > >> >
> > > >> > diff --git a/src/util/list.h b/src/util/list.h
> > > >> > index 09d1b4cae64..6d89a42b226 100644
> > > >> > --- a/src/util/list.h
> > > >> > +++ b/src/util/list.h
> > > >> > @@ -43,6 +43,13 @@
> > > >> >  #include 
> > > >> >  #include "c99_compat.h"
> > > >> >
> > > >> > +#ifdef DEBUG
> > > >> > +#  define LIST_DEBUG 1
> > > >> > +#else
> > > >> > +#  define LIST_DEBUG 0
> > > >> > +#endif
> > > >> > +
> > > >> > +#define list_assert(cond, msg)  ({ if (LIST_DEBUG) assert((cond) && 
> > > >> > msg); })
> > > >>
> > > >> Not sure if it's worth worrying about, but this style of macro
> > > >> definition can be dangerous. One might use it as
> > > >>
> > > >> if (x) list_assert()
> > > >> else blah;
> > > >>
> > > >> With the macro defined as-is, the "else blah" will get attached to the
> > > >> if in the macro. I believe the common style is to do do {}while(0) to
> > > >> avoid such issues (or to use an inline function). Alternatively, just
> > > >> define it differently for LIST_DEBUG vs not.
> > > >>
> > > >
> > > > I think the ({ ... }) should save the day..
> > > >
> > > > (hmm, is that c99 or a gnu thing?  I've it isn't avail on some
> > > > compilers I guess we should disable list_assert() for those?)
> > > >
> > > > BR,
> > > > -R
> > > > ___
> > > > 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] list: add some iterator debug

[Rob Clark]

Is there a convenient #ifdef I can use to guard the list_assert()
macro..  I don't really mind if MSVC can't have this, but would rather
not let it prevent the rest of us from having nice things

BR,
-R

On Sat, May 25, 2019 at 1:23 PM Jason Ekstrand  wrote:
>
> Yeah, that's a GNU extension. It also works in clang but not MSVC which is
> used to build NIR.
>
> On May 25, 2019 13:30:29 Rob Clark  wrote:
>
> > On Sat, May 25, 2019 at 11:13 AM Ilia Mirkin  wrote:
> >>
> >> On Sat, May 25, 2019 at 2:03 PM Rob Clark  wrote:
> >> >
> >> > From: Rob Clark 
> >> >
> >> > Debugging use of unsafe iterators when you should have used the _safe
> >> > version sucks.  Add some DEBUG build support to catch and assert if
> >> > someone does that.
> >> >
> >> > I didn't update the UPPERCASE verions of the iterators.  They should
> >> > probably be deprecated/removed.
> >> >
> >> > Signed-off-by: Rob Clark 
> >> > ---
> >> >  src/util/list.h | 23 ++-
> >> >  1 file changed, 18 insertions(+), 5 deletions(-)
> >> >
> >> > diff --git a/src/util/list.h b/src/util/list.h
> >> > index 09d1b4cae64..6d89a42b226 100644
> >> > --- a/src/util/list.h
> >> > +++ b/src/util/list.h
> >> > @@ -43,6 +43,13 @@
> >> >  #include 
> >> >  #include "c99_compat.h"
> >> >
> >> > +#ifdef DEBUG
> >> > +#  define LIST_DEBUG 1
> >> > +#else
> >> > +#  define LIST_DEBUG 0
> >> > +#endif
> >> > +
> >> > +#define list_assert(cond, msg)  ({ if (LIST_DEBUG) assert((cond) && 
> >> > msg); })
> >>
> >> Not sure if it's worth worrying about, but this style of macro
> >> definition can be dangerous. One might use it as
> >>
> >> if (x) list_assert()
> >> else blah;
> >>
> >> With the macro defined as-is, the "else blah" will get attached to the
> >> if in the macro. I believe the common style is to do do {}while(0) to
> >> avoid such issues (or to use an inline function). Alternatively, just
> >> define it differently for LIST_DEBUG vs not.
> >>
> >
> > I think the ({ ... }) should save the day..
> >
> > (hmm, is that c99 or a gnu thing?  I've it isn't avail on some
> > compilers I guess we should disable list_assert() for those?)
> >
> > BR,
> > -R
> > ___
> > 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] list: add some iterator debug

[Rob Clark]

On Sat, May 25, 2019 at 11:13 AM Ilia Mirkin  wrote:
>
> On Sat, May 25, 2019 at 2:03 PM Rob Clark  wrote:
> >
> > From: Rob Clark 
> >
> > Debugging use of unsafe iterators when you should have used the _safe
> > version sucks.  Add some DEBUG build support to catch and assert if
> > someone does that.
> >
> > I didn't update the UPPERCASE verions of the iterators.  They should
> > probably be deprecated/removed.
> >
> > Signed-off-by: Rob Clark 
> > ---
> >  src/util/list.h | 23 ++-
> >  1 file changed, 18 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/util/list.h b/src/util/list.h
> > index 09d1b4cae64..6d89a42b226 100644
> > --- a/src/util/list.h
> > +++ b/src/util/list.h
> > @@ -43,6 +43,13 @@
> >  #include 
> >  #include "c99_compat.h"
> >
> > +#ifdef DEBUG
> > +#  define LIST_DEBUG 1
> > +#else
> > +#  define LIST_DEBUG 0
> > +#endif
> > +
> > +#define list_assert(cond, msg)  ({ if (LIST_DEBUG) assert((cond) && msg); 
> > })
>
> Not sure if it's worth worrying about, but this style of macro
> definition can be dangerous. One might use it as
>
> if (x) list_assert()
> else blah;
>
> With the macro defined as-is, the "else blah" will get attached to the
> if in the macro. I believe the common style is to do do {}while(0) to
> avoid such issues (or to use an inline function). Alternatively, just
> define it differently for LIST_DEBUG vs not.
>

I think the ({ ... }) should save the day..

(hmm, is that c99 or a gnu thing?  I've it isn't avail on some
compilers I guess we should disable list_assert() for those?)

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

[Mesa-dev] [PATCH] list: add some iterator debug

[Rob Clark]

From: Rob Clark 

Debugging use of unsafe iterators when you should have used the _safe
version sucks.  Add some DEBUG build support to catch and assert if
someone does that.

I didn't update the UPPERCASE verions of the iterators.  They should
probably be deprecated/removed.

Signed-off-by: Rob Clark 
---
 src/util/list.h | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/src/util/list.h b/src/util/list.h
index 09d1b4cae64..6d89a42b226 100644
--- a/src/util/list.h
+++ b/src/util/list.h
@@ -43,6 +43,13 @@
 #include 
 #include "c99_compat.h"
 
+#ifdef DEBUG
+#  define LIST_DEBUG 1
+#else
+#  define LIST_DEBUG 0
+#endif
+
+#define list_assert(cond, msg)  ({ if (LIST_DEBUG) assert((cond) && msg); })
 
 struct list_head
 {
@@ -212,21 +219,27 @@ static inline void list_validate(const struct list_head 
*list)
pos = container_of(pos->member.prev, pos, member))
 
 #define list_for_each_entry(type, pos, head, member)\
-   for (type *pos = LIST_ENTRY(type, (head)->next, member); \
+   for (type *pos = LIST_ENTRY(type, (head)->next, member), \
+*__next = LIST_ENTRY(type, pos->member.next, member);  \
>member != (head); \
-   pos = LIST_ENTRY(type, pos->member.next, member))
+   pos = LIST_ENTRY(type, pos->member.next, member),   \
+   list_assert(pos == __next, "use _safe iterator"),   \
+   __next = LIST_ENTRY(type, __next->member.next, member))
 
 #define list_for_each_entry_safe(type, pos, head, member)   \
for (type *pos = LIST_ENTRY(type, (head)->next, member), \
 *__next = LIST_ENTRY(type, pos->member.next, member);  \
>member != (head); \
pos = __next,   \
-__next = LIST_ENTRY(type, __next->member.next, member))
+   __next = LIST_ENTRY(type, __next->member.next, member))
 
 #define list_for_each_entry_rev(type, pos, head, member)\
-   for (type *pos = LIST_ENTRY(type, (head)->prev, member); \
+   for (type *pos = LIST_ENTRY(type, (head)->prev, member), \
+*__prev = LIST_ENTRY(type, pos->member.prev, member);  \
>member != (head); \
-   pos = LIST_ENTRY(type, pos->member.prev, member))
+   pos = LIST_ENTRY(type, pos->member.prev, member),   \
+   list_assert(pos == __prev, "use _safe iterator"),   \
+   __prev = LIST_ENTRY(type, __prev->member.prev, member))
 
 #define list_for_each_entry_safe_rev(type, pos, head, member)   \
for (type *pos = LIST_ENTRY(type, (head)->prev, member), \
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] st/mesa: fix 2 crashes in st_tgsi_lower_yuv

[Rob Clark]

On Fri, May 10, 2019 at 1:29 PM Marek Olšák  wrote:
>
> From: Marek Olšák 
>
> src/mesa/state_tracker/st_tgsi_lower_yuv.c:68: void reg_dst(struct
>  tgsi_full_dst_register *, const struct tgsi_full_dst_register *, unsigned
>  int): assertion "dst->Register.WriteMask" failed
>
> The second crash was due to insufficient allocated size for TGSI
> instructions.

I might have split this into two patches, but either way you can add my:

Reviewed-by: Rob Clark 

>
> Cc: 19.0 19.1 
> ---
>  src/mesa/state_tracker/st_tgsi_lower_yuv.c | 48 +-
>  1 file changed, 28 insertions(+), 20 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_tgsi_lower_yuv.c 
> b/src/mesa/state_tracker/st_tgsi_lower_yuv.c
> index 6acd173adc9..73437ddda70 100644
> --- a/src/mesa/state_tracker/st_tgsi_lower_yuv.c
> +++ b/src/mesa/state_tracker/st_tgsi_lower_yuv.c
> @@ -262,45 +262,53 @@ yuv_to_rgb(struct tgsi_transform_context *tctx,
> inst.Instruction.Saturate = 0;
> inst.Instruction.NumDstRegs = 1;
> inst.Instruction.NumSrcRegs = 2;
> reg_dst([0], >tmp[A].dst, TGSI_WRITEMASK_XYZ);
> reg_src([0], >tmp[A].src, SWIZ(X, Y, Z, _));
> reg_src([1], >imm[3], SWIZ(X, Y, Z, _));
> inst.Src[1].Register.Negate = 1;
> tctx->emit_instruction(tctx, );
>
> /* DP3 dst.x, tmpA, imm[0] */
> -   inst = dp3_instruction();
> -   reg_dst([0], dst, TGSI_WRITEMASK_X);
> -   reg_src([0], >tmp[A].src, SWIZ(X, Y, Z, W));
> -   reg_src([1], >imm[0], SWIZ(X, Y, Z, W));
> -   tctx->emit_instruction(tctx, );
> +   if (dst->Register.WriteMask & TGSI_WRITEMASK_X) {
> +  inst = dp3_instruction();
> +  reg_dst([0], dst, TGSI_WRITEMASK_X);
> +  reg_src([0], >tmp[A].src, SWIZ(X, Y, Z, W));
> +  reg_src([1], >imm[0], SWIZ(X, Y, Z, W));
> +  tctx->emit_instruction(tctx, );
> +   }
>
> /* DP3 dst.y, tmpA, imm[1] */
> -   inst = dp3_instruction();
> -   reg_dst([0], dst, TGSI_WRITEMASK_Y);
> -   reg_src([0], >tmp[A].src, SWIZ(X, Y, Z, W));
> -   reg_src([1], >imm[1], SWIZ(X, Y, Z, W));
> -   tctx->emit_instruction(tctx, );
> +   if (dst->Register.WriteMask & TGSI_WRITEMASK_Y) {
> +  inst = dp3_instruction();
> +  reg_dst([0], dst, TGSI_WRITEMASK_Y);
> +  reg_src([0], >tmp[A].src, SWIZ(X, Y, Z, W));
> +  reg_src([1], >imm[1], SWIZ(X, Y, Z, W));
> +  tctx->emit_instruction(tctx, );
> +   }
>
> /* DP3 dst.z, tmpA, imm[2] */
> -   inst = dp3_instruction();
> -   reg_dst([0], dst, TGSI_WRITEMASK_Z);
> -   reg_src([0], >tmp[A].src, SWIZ(X, Y, Z, W));
> -   reg_src([1], >imm[2], SWIZ(X, Y, Z, W));
> -   tctx->emit_instruction(tctx, );
> +   if (dst->Register.WriteMask & TGSI_WRITEMASK_Z) {
> +  inst = dp3_instruction();
> +  reg_dst([0], dst, TGSI_WRITEMASK_Z);
> +  reg_src([0], >tmp[A].src, SWIZ(X, Y, Z, W));
> +  reg_src([1], >imm[2], SWIZ(X, Y, Z, W));
> +  tctx->emit_instruction(tctx, );
> +   }
>
> /* MOV dst.w, imm[0].x */
> -   inst = mov_instruction();
> -   reg_dst([0], dst, TGSI_WRITEMASK_W);
> -   reg_src([0], >imm[3], SWIZ(_, _, _, W));
> -   tctx->emit_instruction(tctx, );
> +   if (dst->Register.WriteMask & TGSI_WRITEMASK_W) {
> +  inst = mov_instruction();
> +  reg_dst([0], dst, TGSI_WRITEMASK_W);
> +  reg_src([0], >imm[3], SWIZ(_, _, _, W));
> +  tctx->emit_instruction(tctx, );
> +   }
>  }
>
>  static void
>  lower_nv12(struct tgsi_transform_context *tctx,
> struct tgsi_full_instruction *originst)
>  {
> struct tgsi_yuv_transform *ctx = tgsi_yuv_transform(tctx);
> struct tgsi_full_instruction inst;
> struct tgsi_full_src_register *coord = >Src[0];
> unsigned samp = originst->Src[1].Register.Index;
> @@ -427,21 +435,21 @@ st_tgsi_lower_yuv(const struct tgsi_token *tokens, 
> unsigned free_slots,
> memset(, 0, sizeof(ctx));
> ctx.base.transform_instruction = transform_instr;
> ctx.free_slots = free_slots;
> ctx.lower_nv12 = lower_nv12;
> ctx.lower_iyuv = lower_iyuv;
> tgsi_scan_shader(tokens, );
>
> /* TODO better job of figuring out how many extra tokens we need..
>  * this is a pain about tgsi_transform :-/
>  */
> -   newlen = tgsi_num_tokens(tokens) + 120;
> +   newlen = tgsi_num_tokens(tokens) + 300;
> newtoks = tgsi_alloc_tokens(newlen);
> if (!newtoks)
>return NULL;
>
> tgsi_transform_shader(tokens, newtoks, newlen, );
>
>  //   tgsi_dump(newtoks, 0);
>  //   debug_printf("\n");
>
> return newtoks;
> --
> 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] [RFC PATCH 03/17] eir: add live ranges pass

[Rob Clark]

On Fri, May 10, 2019 at 12:28 PM Rob Clark  wrote:
>
> On Fri, May 10, 2019 at 7:43 AM Connor Abbott  wrote:
> >
> > On Fri, May 10, 2019 at 11:47 AM Connor Abbott  wrote:
> > >
> > >
> > > This way of representing liveness, and then using a coloring register
> > > allocator, is a common anti-pattern in Mesa, that was initially copied
> > > from i965 which dates back to before we knew any better. I really
> > > don't want to see it spread to yet another driver :(.
> > >
> > > Representing live ranges like this is imprecise. If I have a program like 
> > > this:
> > >
> > > foo = ...
> > > if (...) {
> > >bar = ...
> > >... = bar; /* last use of "bar" */
> > > }
> > > ... = foo;
> >
> > Whoops, that should actually read:
> >
> > foo = ...
> > if (...) {
> >bar = ...
> >... = bar; /* last use of "bar" */
> > } else {
> >... = foo;
> > }
>
> hmm, my mind is a bit rusty on the live-range analysis, but foo and
> bar do interfere in the if() side of the if/else..
>
> I thought the case we didn't handle properly was more like a loop:
>
> foo = ...
> for (..) {
>bar = foo;
>... stuff .. foo not live here..
>foo = ...
> }
> ... = foo
>
> where we end up considering foo live during the entire body of the
> loop even though it isn't really.  I guess it is the same case as:
>
> foo = ...
> if () {
>bar = foo;
>...
>foo = ...
> }
> ... = foo;
>

hmm, maybe I mis-read your example (damn gmail hiding quotes).. I
guess last use of bar is in the else block, so we are saying the same
(or similar) thing?

BR,
-R

> BR,
> -R
>
> >
> > >
> > > Then it will say that foo and bar interfere, even when they don't.
> > >
> > > Now, this approximation does make things a bit simpler. But, it turns
> > > out that if you're willing to make it, then the interference graph is
> > > trivially colorable via a simple linear-time algorithm. This is the
> > > basis of "linear-scan" register allocators, including the one in LLVM.
> > > If you want to go down this route, you can, but this hybrid is just
> > > useless as it gives you the worst of both worlds.
> > >
> > > If you want to properly build up the interference graph, it's actually
> > > not that hard. After doing the inter-basic-block liveness analysis,
> > > for each block, you initialize a bitset to the live-out bitset. Then
> > > you walk the block backwards, updating it at each instruction exactly
> > > as in liveness analysis, so that it always represents the live
> > > registers before each instruction. Then you add interferences between
> > > all of the live registers and the register(s) defined at the
> > > instruction.
> > >
> > > One last pitfall I'll mention is that in the real world, you'll also
> > > need to use reachability. If you have something like
> > >
> > > if (...)
> > >foo = ... /* only definition of "foo" */
> > >
> > > ... = foo;
> > >
> > > where foo is only partially defined, then the liveness of foo will
> > > "leak" through the if. To fix this you need to consider what's called
> > > "reachability," i.e. something is only live if, in addition to
> > > potentially being used sometime later, it is reachable (potentially
> > > defined sometime earlier). Reachability analysis is exactly like
> > > liveness analysis, but everything is backwards. i965 does this
> > > properly nowadays, and the change had a huge effect on spilling/RA.
> > >
> > ___
> > 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] [RFC PATCH 03/17] eir: add live ranges pass

[Rob Clark]

On Fri, May 10, 2019 at 7:43 AM Connor Abbott  wrote:
>
> On Fri, May 10, 2019 at 11:47 AM Connor Abbott  wrote:
> >
> >
> > This way of representing liveness, and then using a coloring register
> > allocator, is a common anti-pattern in Mesa, that was initially copied
> > from i965 which dates back to before we knew any better. I really
> > don't want to see it spread to yet another driver :(.
> >
> > Representing live ranges like this is imprecise. If I have a program like 
> > this:
> >
> > foo = ...
> > if (...) {
> >bar = ...
> >... = bar; /* last use of "bar" */
> > }
> > ... = foo;
>
> Whoops, that should actually read:
>
> foo = ...
> if (...) {
>bar = ...
>... = bar; /* last use of "bar" */
> } else {
>... = foo;
> }

hmm, my mind is a bit rusty on the live-range analysis, but foo and
bar do interfere in the if() side of the if/else..

I thought the case we didn't handle properly was more like a loop:

foo = ...
for (..) {
   bar = foo;
   ... stuff .. foo not live here..
   foo = ...
}
... = foo

where we end up considering foo live during the entire body of the
loop even though it isn't really.  I guess it is the same case as:

foo = ...
if () {
   bar = foo;
   ...
   foo = ...
}
... = foo;

BR,
-R

>
> >
> > Then it will say that foo and bar interfere, even when they don't.
> >
> > Now, this approximation does make things a bit simpler. But, it turns
> > out that if you're willing to make it, then the interference graph is
> > trivially colorable via a simple linear-time algorithm. This is the
> > basis of "linear-scan" register allocators, including the one in LLVM.
> > If you want to go down this route, you can, but this hybrid is just
> > useless as it gives you the worst of both worlds.
> >
> > If you want to properly build up the interference graph, it's actually
> > not that hard. After doing the inter-basic-block liveness analysis,
> > for each block, you initialize a bitset to the live-out bitset. Then
> > you walk the block backwards, updating it at each instruction exactly
> > as in liveness analysis, so that it always represents the live
> > registers before each instruction. Then you add interferences between
> > all of the live registers and the register(s) defined at the
> > instruction.
> >
> > One last pitfall I'll mention is that in the real world, you'll also
> > need to use reachability. If you have something like
> >
> > if (...)
> >foo = ... /* only definition of "foo" */
> >
> > ... = foo;
> >
> > where foo is only partially defined, then the liveness of foo will
> > "leak" through the if. To fix this you need to consider what's called
> > "reachability," i.e. something is only live if, in addition to
> > potentially being used sometime later, it is reachable (potentially
> > defined sometime earlier). Reachability analysis is exactly like
> > liveness analysis, but everything is backwards. i965 does this
> > properly nowadays, and the change had a huge effect on spilling/RA.
> >
> ___
> 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] st/dri: decrease input lag by syncing sooner in SwapBuffers

[Rob Clark]

On Sat, Apr 27, 2019 at 9:52 AM Axel Davy  wrote:
>
> On 27/04/2019 18:13, Rob Clark wrote:
> > On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák  wrote:
> >> From: Marek Olšák 
> >>
> >> It's done by:
> >> - decrease the number of frames in flight by 1
> >> - flush before throttling in SwapBuffers
> >>(instead of wait-then-flush, do flush-then-wait)
> >>
> >> The improvement is apparent with Unigine Heaven.
> >>
> >> Previously:
> >>  draw frame 2
> >>  wait frame 0
> >>  flush frame 2
> >>  present frame 2
> >>
> >>  The input lag is 2 frames.
> >>
> >> Now:
> >>  draw frame 2
> >>  flush frame 2
> >>  wait frame 1
> >>  present frame 2
> >>
> >>  The input lag is 1 frame. Flushing is done before waiting, because
> >>  otherwise the device would be idle after waiting.
> >>
> >> Nine is affected because it also uses the pipe cap.
> >> ---
> >>   src/gallium/auxiliary/util/u_screen.c |  2 +-
> >>   src/gallium/state_trackers/dri/dri_drawable.c | 20 +--
> >>   2 files changed, 11 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/src/gallium/auxiliary/util/u_screen.c 
> >> b/src/gallium/auxiliary/util/u_screen.c
> >> index 27f51e0898e..410f17421e6 100644
> >> --- a/src/gallium/auxiliary/util/u_screen.c
> >> +++ b/src/gallium/auxiliary/util/u_screen.c
> >> @@ -349,21 +349,21 @@ u_pipe_screen_get_param_defaults(struct pipe_screen 
> >> *pscreen,
> >>  case PIPE_CAP_MAX_VARYINGS:
> >> return 8;
> >>
> >>  case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK:
> >> return 0;
> >>
> >>  case PIPE_CAP_COMPUTE_SHADER_DERIVATIVES:
> >> return 0;
> >>
> >>  case PIPE_CAP_MAX_FRAMES_IN_FLIGHT:
> >> -  return 2;
> >> +  return 1;
> > would it be safer to leave the current default and let drivers opt-in
> > to the lower # individually?  I guess triple buffering would still be
> > better for some of the smaller gpu's?
> >
> > disclaimer: I haven't tested this myself or looked very closely at the
> > dri code.. so could be misunderstanding something..
> >
> > BR,
> > -R
>
>
> I think I can shed some light on the issue to justify (or not) the change.
>
> If we don't do throttling and the CPU renders frames at a faster rate
> than what the GPU can render,
> the GPU can become quite late and cause huge frame lag.
>
> The throttling involves forcing a (CPU) wait when a frame is presented
> if the 'x' previous images have not finished rendering.
>
> The lower 'x', the lower the frame lag.
>
> However if 'x' is too low (waiting current frame is rendered for
> example), the GPU can be idle until the CPU is flushing new commands.
>
> Now there is a choice to be made for the value of 'x'. 1 or 2 are
> reasonable values.
>
> if 'x' is 1, we wait the previous frame was rendered when we present the
> current frame. For '2' we wait the frame before.
>
>
> Thus for smaller gpu's, a value of 1 is better than 2 as it is more
> affected by the frame lag (as frames take longer to render).
>

I get the latency aspect.. but my comment was more about latency vs
framerate (or maybe more cynically, about games vs benchmarks :-P)

BR,
-R

>
> However if a game is rendering at a very unstable framerate (some frames
> needing more work than others), using a value of 2 is safer
> to maximize performance. (As using a value of 1 would lead to wait if we
> get a frame that takes particularly long, as using 2 smooths that a bit)
>
>
> I remember years ago I had extremely unstable fps when using catalyst on
> Portal for example. But I believe it is more a driver issue than a game
> issue.
>
> If we assume games don't have unstable framerate, (which seems
> reasonable assumption), using 1 as default makes sense.
>
>
> If one wants to test experimentally for regression, the ideal test case
> if when the GPU renders at about the same framerate as the CPU feeds it.
>
>
>
> Axel
>
>
>
> >
> >>  case PIPE_CAP_DMABUF:
> >>   #ifdef PIPE_OS_LINUX
> >> return 1;
> >>   #else
> >> return 0;
> >>   #endif
> >>
> >>  default:
> >> unreachable("bad PIPE_CAP_*");
> >> diff --git a/src/gallium/state_trackers/dri/dri_drawable.c 
> >> b/src/gallium

Re: [Mesa-dev] [PATCH] st/dri: decrease input lag by syncing sooner in SwapBuffers

[Rob Clark]

On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák  wrote:
>
> From: Marek Olšák 
>
> It's done by:
> - decrease the number of frames in flight by 1
> - flush before throttling in SwapBuffers
>   (instead of wait-then-flush, do flush-then-wait)
>
> The improvement is apparent with Unigine Heaven.
>
> Previously:
> draw frame 2
> wait frame 0
> flush frame 2
> present frame 2
>
> The input lag is 2 frames.
>
> Now:
> draw frame 2
> flush frame 2
> wait frame 1
> present frame 2
>
> The input lag is 1 frame. Flushing is done before waiting, because
> otherwise the device would be idle after waiting.
>
> Nine is affected because it also uses the pipe cap.
> ---
>  src/gallium/auxiliary/util/u_screen.c |  2 +-
>  src/gallium/state_trackers/dri/dri_drawable.c | 20 +--
>  2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_screen.c 
> b/src/gallium/auxiliary/util/u_screen.c
> index 27f51e0898e..410f17421e6 100644
> --- a/src/gallium/auxiliary/util/u_screen.c
> +++ b/src/gallium/auxiliary/util/u_screen.c
> @@ -349,21 +349,21 @@ u_pipe_screen_get_param_defaults(struct pipe_screen 
> *pscreen,
> case PIPE_CAP_MAX_VARYINGS:
>return 8;
>
> case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK:
>return 0;
>
> case PIPE_CAP_COMPUTE_SHADER_DERIVATIVES:
>return 0;
>
> case PIPE_CAP_MAX_FRAMES_IN_FLIGHT:
> -  return 2;
> +  return 1;

would it be safer to leave the current default and let drivers opt-in
to the lower # individually?  I guess triple buffering would still be
better for some of the smaller gpu's?

disclaimer: I haven't tested this myself or looked very closely at the
dri code.. so could be misunderstanding something..

BR,
-R

>
> case PIPE_CAP_DMABUF:
>  #ifdef PIPE_OS_LINUX
>return 1;
>  #else
>return 0;
>  #endif
>
> default:
>unreachable("bad PIPE_CAP_*");
> diff --git a/src/gallium/state_trackers/dri/dri_drawable.c 
> b/src/gallium/state_trackers/dri/dri_drawable.c
> index 26bfdbecc53..c1de3bed9dd 100644
> --- a/src/gallium/state_trackers/dri/dri_drawable.c
> +++ b/src/gallium/state_trackers/dri/dri_drawable.c
> @@ -555,33 +555,33 @@ dri_flush(__DRIcontext *cPriv,
> *
> * This pulls a fence off the throttling queue and waits for it if the
> * number of fences on the throttling queue has reached the desired
> * number.
> *
> * Then flushes to insert a fence at the current rendering position, 
> and
> * pushes that fence on the queue. This requires that the 
> st_context_iface
> * flush method returns a fence even if there are no commands to flush.
> */
>struct pipe_screen *screen = drawable->screen->base.screen;
> -  struct pipe_fence_handle *fence;
> +  struct pipe_fence_handle *oldest_fence, *new_fence = NULL;
>
> -  fence = swap_fences_pop_front(drawable);
> -  if (fence) {
> - (void) screen->fence_finish(screen, NULL, fence, 
> PIPE_TIMEOUT_INFINITE);
> - screen->fence_reference(screen, , NULL);
> -  }
> +  st->flush(st, flush_flags, _fence);
>
> -  st->flush(st, flush_flags, );
> +  oldest_fence = swap_fences_pop_front(drawable);
> +  if (oldest_fence) {
> + screen->fence_finish(screen, NULL, oldest_fence, 
> PIPE_TIMEOUT_INFINITE);
> + screen->fence_reference(screen, _fence, NULL);
> +  }
>
> -  if (fence) {
> - swap_fences_push_back(drawable, fence);
> - screen->fence_reference(screen, , NULL);
> +  if (new_fence) {
> + swap_fences_push_back(drawable, new_fence);
> + screen->fence_reference(screen, _fence, NULL);
>}
> }
> else if (flags & (__DRI2_FLUSH_DRAWABLE | __DRI2_FLUSH_CONTEXT)) {
>st->flush(st, flush_flags, NULL);
> }
>
> if (drawable) {
>drawable->flushing = FALSE;
> }
>
> --
> 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] [PATCH 1/2] nir: Add inverted bitwise ops

[Rob Clark]

On Thu, Apr 25, 2019 at 3:37 PM Alyssa Rosenzweig  wrote:
>
> In addition to the familiar iand/ior/ixor, some architectures feature
> destination-inverted versions inand/inor/inxor. Certain
> architectures also have source-inverted forms, dubbed iandnot/iornot
> here. Midgard has the all of these opcodes natively. Many arches have
> comparible features to implement some/all of the above. Paired with De
> Morgan's Laws, these opcodes allow anything of the form
> "~? (~?a [&|] ~?b)" to complete in one instruction.
>
> This can be used to simplify some backend-specific code on affected
> architectures, e.f. 8eb36c91 ("intel/fs: Emit logical-not of operands on
> Gen8+").
>
> Signed-off-by: Alyssa Rosenzweig 
> Cc: Ian Romanick 
> Cc: Kenneth Graunke 
> ---
>  src/compiler/nir/nir.h|  4 
>  src/compiler/nir/nir_opcodes.py   | 18 ++
>  src/compiler/nir/nir_opt_algebraic.py | 12 
>  3 files changed, 34 insertions(+)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index e878a63409d..3e01ec2cc06 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -2318,6 +2318,10 @@ typedef struct nir_shader_compiler_options {
> bool lower_hadd;
> bool lower_add_sat;
>
> +   /* Set if inand/inor/inxor and iandnot/iornot supported respectively */
> +   bool bitwise_dest_invertable;
> +   bool bitwise_src_invertable;


neat, this trick seems to work on a6xx (and I'd assume earlier gens
that use ir3 although I'd have to dust off some older blobs to check..
blob is less kind when it comes to retaining support for older hw)..

very-bikeshed-comment: split into two comments per compiler_options flag?

Reviewed-by: Rob Clark 


> +
> /**
>  * Should nir_lower_io() create load_interpolated_input intrinsics?
>  *
> diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
> index d35d820aa5b..f9d92afb53e 100644
> --- a/src/compiler/nir/nir_opcodes.py
> +++ b/src/compiler/nir/nir_opcodes.py
> @@ -690,6 +690,24 @@ binop("iand", tuint, commutative + associative, "src0 & 
> src1")
>  binop("ior", tuint, commutative + associative, "src0 | src1")
>  binop("ixor", tuint, commutative + associative, "src0 ^ src1")
>
> +# inverted bitwise logic operators
> +#
> +# These variants of the above include bitwise NOTs either on the result of 
> the
> +# whole expression or on the latter operand. On some hardware (e.g. Midgard),
> +# these are native ops. On other hardware (e.g. Intel Gen8+), these can be
> +# implemented as modifiers of the standard three. Along with appropriate
> +# algebraic passes, these should permit any permutation of inverses on AND/OR
> +# to execute in a single cycle. For example, ~(a & ~b) = ~(~(~a | ~(~b))) = 
> ~a
> +# | b = b | ~a = iornot(b, a).
> +
> +binop("inand", tuint, commutative, "~(src0 & src1)")
> +binop("inor", tuint, commutative, "~(src0 | src1)")
> +binop("inxor", tuint, commutative, "~(src0 ^ src1)")
> +binop("iandnot", tuint, "", "src0 & (~src1)")
> +binop("iornot", tuint, "", "src0 & (~src1)")
> +
> +
> +
>
>  # floating point logic operators
>  #
> diff --git a/src/compiler/nir/nir_opt_algebraic.py 
> b/src/compiler/nir/nir_opt_algebraic.py
> index dad0545594f..6cb3e8cb950 100644
> --- a/src/compiler/nir/nir_opt_algebraic.py
> +++ b/src/compiler/nir/nir_opt_algebraic.py
> @@ -1052,6 +1052,18 @@ late_optimizations = [
> (('fmax', ('fadd(is_used_once)', '#c', a), ('fadd(is_used_once)', '#c', 
> b)), ('fadd', c, ('fmax', a, b))),
>
> (('bcsel', a, 0, ('b2f32', ('inot', 'b@bool'))), ('b2f32', ('inot', 
> ('ior', a, b,
> +
> +   # We don't want to deal with inverted forms, so run this late. Any
> +   # combination of inverts on flags or output should result in a single
> +   # instruction if these are supported; cases not explicitly handled would
> +   # have been simplified via De Morgan's Law
> +   (('inot', ('iand', a, b)), ('inand', a, b), 
> 'options->bitwise_dest_invertable'),
> +   (('inot', ('ior', a, b)), ('inor', a, b), 
> 'options->bitwise_dest_invertable'),
> +   (('inot', ('ixor', a, b)), ('inxor', a, b), 
> 'options->bitwise_dest_invertable'),
> +   (('iand', ('inot', a), b), ('iandnot', b, a), 
> 'options->bitwise_src_invertable'),
> +   (('iand', a, ('inot', b)), ('iandnot', a, b), 
> 'options->bitwise_src_invertable'),
> +   (('ior', a, ('inot', b)), ('iornot', a, b), 
> 'options->bitwise_src_invertable'),
> +   (('ior', ('inot', a), b), ('iornot', b, a), 
> 'options->bitwise_src_invertable'),
>  ]
>
>  print(nir_algebraic.AlgebraicPass("nir_opt_algebraic", 
> optimizations).render())
> --
> 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] get_reviewer.pl: improve portability

[Rob Clark]

looks like the kernel get_maintainer.pl made a similar change at some
point.. anyways, seems like a good idea

r-b

On Fri, Apr 19, 2019 at 11:15 AM Alyssa Ross  wrote:
>
> Not all package managers / users will install perl into /usr/bin,
> but /usr/bin/env /should/ always be present.
>
> Using /usr/bin/env means that we can't give the -w argument to Perl,
> so I added `use warnings' in the script.
>
> Cc: Rob Clark 
> ---
>  scripts/get_reviewer.pl | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/get_reviewer.pl b/scripts/get_reviewer.pl
> index 62deb922800..1677495ad6d 100755
> --- a/scripts/get_reviewer.pl
> +++ b/scripts/get_reviewer.pl
> @@ -1,4 +1,4 @@
> -#!/usr/bin/perl -w
> +#!/usr/bin/env perl
>  # (c) 2007, Joe Perches 
>  #   created from checkpatch.pl
>  #
> @@ -14,6 +14,7 @@
>  # Licensed under the terms of the GNU GPL License version 2
>
>  use strict;
> +use warnings;
>
>  my $P = $0;
>  my $V = '0.26';
> --
> 2.19.2
>
> ___
> 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] panfrost: Track BO lifetime with jobs and reference counts

[Rob Clark]

On Tue, Apr 16, 2019 at 8:07 AM Alyssa Rosenzweig  wrote:
>
> > > diff --git a/src/gallium/drivers/panfrost/pan_job.c
> > > b/src/gallium/drivers/panfrost/pan_job.c
> > > index 66a8b0d4b07..6c68575158f 100644
> > > --- a/src/gallium/drivers/panfrost/pan_job.c
> > > +++ b/src/gallium/drivers/panfrost/pan_job.c
> > > @@ -27,6 +27,13 @@
> > >  #include "util/hash_table.h"
> > >  #include "util/ralloc.h"
> > >
> > > +static void
> > > +remove_from_ht(struct hash_table *ht, void *key)
> > > +{
> > > +struct hash_entry *entry = _mesa_hash_table_search(ht, key);
> > > +_mesa_hash_table_remove(ht, entry);
> > > +}
> > > +
> >
> > This is the same as _mesa_hash_table_remove_key(), no?
>
> Maybe? I copypasted this from v3d, but maybe we're both duplicating
> code.
>
> > Did you mean to leave this #if'ed out?
>
> Yes, job flushing is a lot more complicated / depends on a lot more
> code; I just wanted the stub here for now.
>
> > Why not use pipe_reference instead of open-coding? That helper contains
> > some neat debug-helpers etc...
>
> pipe_reference kind of scares me... Most of the abstractions here are
> based heavily on v3d's; I figure if anholt had a good reason to do it,
> that's good enough for me..

I think the only (valid) reason not to use pipe_reference would be if
it was some code that might someday be useful for a vulkan driver.

(That said, maybe we should move more and more of gallium's helpful
util stuff out of gallium so they can be re-used across the mesa
tree...)

BR,
-R

> ___
> 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] panfrost: Track BO lifetime with jobs and reference counts

[Rob Clark]

On Tue, Apr 16, 2019 at 12:31 AM Boris Brezillon
 wrote:
>
> On Tue, 16 Apr 2019 01:49:21 +
> Alyssa Rosenzweig  wrote:
>
> > @@ -1793,22 +1799,9 @@ panfrost_set_vertex_buffers(
> >  const struct pipe_vertex_buffer *buffers)
> >  {
> >  struct panfrost_context *ctx = pan_context(pctx);
> > -assert(num_buffers <= PIPE_MAX_ATTRIBS);
> > -
> > -/* XXX: Dirty tracking? etc */
> > -if (buffers) {
> > -size_t sz = sizeof(buffers[0]) * num_buffers;
> > -ctx->vertex_buffers = malloc(sz);
> > -ctx->vertex_buffer_count = num_buffers;
> > -memcpy(ctx->vertex_buffers, buffers, sz);
> > -} else {
> > -if (ctx->vertex_buffers) {
> > -free(ctx->vertex_buffers);
> > -ctx->vertex_buffers = NULL;
> > -}
> >
> > -ctx->vertex_buffer_count = 0;
> > -}
> > +util_set_vertex_buffers_mask(ctx->vertex_buffers, >vb_mask, 
> > buffers, start_slot, num_buffers);
> > +ctx->vertex_buffer_count = num_buffers;
>
> ->vertex_buffer_count should be set to fls(ctx->vb_mask) (fls == find
> last bit set) if you want the

or util_last_bit()

BR,
-R

>
> for (int i = 0; i < ctx->vertex_buffer_count; ++i)
>
> loop in panfrost_emit_vertex_data() to do the right thing. But I think
> we can get rid of ->vertex_buffer_count entirely and just do a
>
> for (int i = 0; i < ARRAY_SIZE(ctx->vertex_buffers); ++i)
>
> >  }
> ___
> 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] Proposal: MESA_debug_operations

[Rob Clark]

On Sun, Apr 14, 2019 at 2:22 PM Ilia Mirkin  wrote:
>
> Hi all,
>
> I've put together a GLSL extension proposal at:
>
> https://people.freedesktop.org/~imirkin/MESA_debug_operations.spec

I could see some cases where something like this would be useful..

BR,
-R

>
> The situation this is trying to alleviate is the fact that it's an
> _enormous_ pain to actually execute shaders and collect results on any
> particular hardware without a surrounding driver to handle all the
> mundane bits. It's much easier to stick it into an already working
> driver, and basically pass a token to the shader compiler to do what
> it will.
>
> We've had numerous occasions in nouveau development whereby some
> instruction has a flag that we don't quite understand (or even a whole
> instruction). We could do one-off hacks to make the shader compiler
> "test it out", but it's tedious. This enables permanent infrastructure
> in mesa to pass such tokens through with enough parameters to be able
> to test anything. (Although I doubt it would ever be submitted for
> inclusion in the official KHR db.)
>
> Since this relies on careful interactions with shader compiler, what
> the debug ops really mean would need to be either baked in, or
> provided via env vars. The idea isn't to have anything checked in that
> would actually use this ext, but to enable driver developers with a
> simpler testing methodology. But you could have a glsl model of how an
> operation works and record any differences. Or you could just dump the
> results into a ssbo in a compute shader for offline analysis.
>
> It introduces an ALU-style op, texture, image, and memory. I think
> that covers it, except for interpolation, but I felt tackling that one
> would be unnecessarily complicated. And interpolation frequently
> involves bits outside of the shader as well in any case.
>
> I don't have an implementation for this yet, I wanted first to gather
> some feedback (and most importantly, any opposition) before doing any
> actual work on this.
>
> Cheers,
>
>   -ilia
> ___
> 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] nir: Add nir_lower_viewport_transform

[Rob Clark]

On Sun, Apr 14, 2019 at 11:27 AM Christian Gmeiner
 wrote:
>
> Am So., 14. Apr. 2019 um 17:45 Uhr schrieb Alyssa Rosenzweig
> :
> >
> > On Mali hardware (supported by Panfrost and Lima), the fixed-function
> > transformation from world-space to screen-space coordinates is done in
> > the vertex shader prior to writing out the gl_Position varying, rather
> > than in dedicated hardware. This commit adds a shared NIR pass for
> > implementing coordinate transformation and lowering gl_Position writes
> > into screen-space gl_Position writes.
> >
> > v2: Run directly on derefs before io/vars are lowered to cleanup the
> > code substantially. Thank you to Qiang for this suggestion!
> >
> > v3: Bikeshed continues.
> >
> > v4: Add to Makefile.sources (per Jason's comment). Bikeshed comment.
> > (Trivial -- reviews are from v3)
> >
> > Signed-off-by: Alyssa Rosenzweig 
> > Suggested-by: Qiang Yu 
> > Reviewed-by: Ian Romanick 
> > Reviewed-by: Qiang Yu 
> > Cc: Jason Ekstrand 
> > Cc: Eric Anholt 
> > ---
> >  src/compiler/Makefile.sources |   1 +
> >  src/compiler/nir/meson.build  |   1 +
> >  src/compiler/nir/nir.h|   1 +
> >  .../nir/nir_lower_viewport_transform.c| 102 ++
> >  4 files changed, 105 insertions(+)
> >  create mode 100644 src/compiler/nir/nir_lower_viewport_transform.c
> >
> > diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
> > index 5737a827daa..35dd7ff1abe 100644
> > --- a/src/compiler/Makefile.sources
> > +++ b/src/compiler/Makefile.sources
> > @@ -273,6 +273,7 @@ NIR_FILES = \
> > nir/nir_lower_vars_to_ssa.c \
> > nir/nir_lower_var_copies.c \
> > nir/nir_lower_vec_to_movs.c \
> > +   nir/nir_lower_viewport_transform.c \
> > nir/nir_lower_wpos_center.c \
> > nir/nir_lower_wpos_ytransform.c \
> > nir/nir_metadata.c \
> > diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
> > index 4e5039e28e0..d6e7b2cc167 100644
> > --- a/src/compiler/nir/meson.build
> > +++ b/src/compiler/nir/meson.build
> > @@ -152,6 +152,7 @@ files_libnir = files(
> >'nir_lower_vars_to_ssa.c',
> >'nir_lower_var_copies.c',
> >'nir_lower_vec_to_movs.c',
> > +  'nir_lower_viewport_transform.c',
> >'nir_lower_wpos_center.c',
> >'nir_lower_wpos_ytransform.c',
> >'nir_lower_bit_size.c',
> > diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> > index ad72a5c9222..4323f5e0413 100644
> > --- a/src/compiler/nir/nir.h
> > +++ b/src/compiler/nir/nir.h
> > @@ -3114,6 +3114,7 @@ void nir_lower_io_to_scalar(nir_shader *shader, 
> > nir_variable_mode mask);
> >  void nir_lower_io_to_scalar_early(nir_shader *shader, nir_variable_mode 
> > mask);
> >  bool nir_lower_io_to_vector(nir_shader *shader, nir_variable_mode mask);
> >
> > +void nir_lower_viewport_transform(nir_shader *shader);
> >  bool nir_lower_uniforms_to_ubo(nir_shader *shader, int multiplier);
> >
> >  typedef struct nir_lower_subgroups_options {
> > diff --git a/src/compiler/nir/nir_lower_viewport_transform.c 
> > b/src/compiler/nir/nir_lower_viewport_transform.c
> > new file mode 100644
> > index 000..94b54524ab7
> > --- /dev/null
> > +++ b/src/compiler/nir/nir_lower_viewport_transform.c
> > @@ -0,0 +1,102 @@
> > +/*
> > + * Copyright (C) 2019 Alyssa Rosenzweig
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the 
> > "Software"),
> > + * to deal in the Software without restriction, including without 
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the 
> > next
> > + * paragraph) shall be included in all copies or substantial portions of 
> > the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > DEALINGS
> > + * IN THE SOFTWARE.
> > + */
> > +
> > +/* On some hardware (particularly, all current versions of Mali GPUs),
> > + * vertex shaders do not output gl_Position in world-space. Instead, they
> > + * output gl_Position in transformed screen space via the "pseudo"
> > + * position varying. Thus, this pass finds writes to gl_Position and
> > + * changes them to transformed writes, still to gl_Position. The
> > 

Re: [Mesa-dev] Move adriconf to mesa repositories

[Rob Clark]

+daniels

On Mon, Apr 1, 2019 at 1:55 PM Jean Hertel  wrote:
>
> Hi Rob,
>
> As we have spoken already in the past, I have the intention to move adriconf 
> under the mesa project umbrella, as an official tool for configuring DRI 
> options.
> I would like to ask your advice, as well as other mesa developers, on how to 
> properly do this. (If people is willing to accept it)
> So far the questions I have are:
>
> - What is the proccess to become an official mesa tool?

Maybe a gitlab ticket?  Or ping daniels and ask?

> - Do I need any approval? Like from other mesa developers or X.Org Foundation?

No approval from X.Org foundation or anything like that.. maybe some
general consensus among mesa dev's (or at least a few others who think
it is a good idea).  For the record, I think living under
gitlab.freedesktop.org/mesa/adriconf makes sense.

> - In this proccess, can we rename the adriconf to use a proper mesa 
> namespace? Right now it is named as br.com.jeanhertel.adriconf which is quite 
> weird, as the intention is not to be a comercial tool. See [Flathub][1].

I guess you are referring to what it is called in flathub?  I guess
that would make more sense.

> - Also, what about gitlab? If we move, can we use it? I already know the tool 
> and would really appreciate using it.

Yes, I don't think the fd.o admin's are creating new non-gitlab projects.

> - Is there anyone else willing to have commit rights on it? I known the 
> project is public, but I feel it would be nice to have someone else also with 
> commit/admin rights in case I'm hit by a bus :)

Hmm, I guess it is possible to set it up so anyone with mesa commit
rights would have adriconf commit rights.  But afaiu gitlab is
somewhat flexible on groups so we could I guess do something more fine
grained.

> - What about GSOC? On the X.Org [page][2] there is still a driconf 
> replacement idea. If we move, can we replace this with some adriconf 
> improvement ideas?

Actually either way we should update the wiki page.  I think you
should be able to create an account and make updates?

BR,
-R

>
> Kind Regards,
> Jean Hertel
>
> [1]: https://flathub.org/apps/details/br.com.jeanhertel.adriconf
> [2]: https://www.x.org/wiki/SummerOfCodeIdeas/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] mesa/st: use ESSL cap top enable gpu_shader5 (v3)

[Rob Clark]

For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
sufficiently high ESSL feature level, even if the GLSL feature level
isn't high enough.

This allows drivers to support EXT_gpu_shader5 in GLES contexts before
they support all the additional features of ARB_gpu_shader5 in GL
contexts.

Signed-off-by: Rob Clark 
---
 src/mesa/state_tracker/st_extensions.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index c953bfd9f7a..405fc21b3ad 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -1056,6 +1056,8 @@ void st_init_extensions(struct pipe_screen *screen,
consts->GLSLVersionCompat =
   screen->get_param(screen, PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY);
 
+   const unsigned ESSLVersion =
+  screen->get_param(screen, PIPE_CAP_ESSL_FEATURE_LEVEL);
const unsigned GLSLVersion =
   api == API_OPENGL_COMPAT ? consts->GLSLVersionCompat :
  consts->GLSLVersion;
@@ -1077,6 +1079,13 @@ void st_init_extensions(struct pipe_screen *screen,
 
consts->AllowGLSLCrossStageInterpolationMismatch = 
options->allow_glsl_cross_stage_interpolation_mismatch;
 
+   /* Technically we are turning on the EXT_gpu_shader5 extension,
+* ARB_gpu_shader5 does not exist in GLES, but this flag is what
+* switches on EXT_gpu_shader5:
+*/
+   if (api == API_OPENGLES2 && ESSLVersion >= 320)
+  extensions->ARB_gpu_shader5 = GL_TRUE;
+
if (GLSLVersion >= 400)
   extensions->ARB_gpu_shader5 = GL_TRUE;
if (GLSLVersion >= 410)
@@ -1540,16 +1549,18 @@ void st_init_extensions(struct pipe_screen *screen,
   extensions->EXT_shader_integer_mix;
 
extensions->OES_texture_cube_map_array =
-  extensions->ARB_ES3_1_compatibility &&
+  (extensions->ARB_ES3_1_compatibility || ESSLVersion >= 310) &&
   extensions->OES_geometry_shader &&
   extensions->ARB_texture_cube_map_array;
 
extensions->OES_viewport_array =
-  extensions->ARB_ES3_1_compatibility &&
+  (extensions->ARB_ES3_1_compatibility || ESSLVersion >= 310) &&
   extensions->OES_geometry_shader &&
   extensions->ARB_viewport_array;
 
-   extensions->OES_primitive_bounding_box = 
extensions->ARB_ES3_1_compatibility;
+   extensions->OES_primitive_bounding_box =
+  extensions->ARB_ES3_1_compatibility || ESSLVersion >= 310;
+
consts->NoPrimitiveBoundingBoxOutput = true;
 
extensions->ANDROID_extension_pack_es31a =
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH 2/3] mesa/st: use ESSL cap top enable gpu_shader5 (v2)

[Rob Clark]

On Thu, Mar 21, 2019 at 2:19 PM Ilia Mirkin  wrote:
>
> On Thu, Mar 21, 2019 at 1:45 PM Rob Clark  wrote:
> >
> > For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
> > sufficiently high ESSL feature level, even if the GLSL feature level
> > isn't high enough.
> >
> > This allows drivers to support EXT_gpu_shader5 in GLES contexts before
> > they support all the additional features of ARB_gpu_shader5 in GL
> > contexts.
> >
> > We can also use this cap to enable ARB_ES3_1_compatibility.
>
> I believe this is no longer the case, so probably remove that line.
> Also, all the cool people talk about the OES_* variants of the exts...
> Doesn't really matter, of course. They're identical.
>
> >
> > Signed-off-by: Rob Clark 
> > ---
> > This kinda morphed into also fixing OES_viewport_array (which should
> > depend on GLES 3.2)
> >
> >  src/mesa/state_tracker/st_extensions.c | 24 +---
> >  1 file changed, 17 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/mesa/state_tracker/st_extensions.c 
> > b/src/mesa/state_tracker/st_extensions.c
> > index c953bfd9f7a..7c3b98c1ba6 100644
> > --- a/src/mesa/state_tracker/st_extensions.c
> > +++ b/src/mesa/state_tracker/st_extensions.c
> > @@ -1056,6 +1056,8 @@ void st_init_extensions(struct pipe_screen *screen,
> > consts->GLSLVersionCompat =
> >screen->get_param(screen, PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY);
> >
> > +   const unsigned ESSLVersion =
> > +  screen->get_param(screen, PIPE_CAP_ESSL_FEATURE_LEVEL);
> > const unsigned GLSLVersion =
> >api == API_OPENGL_COMPAT ? consts->GLSLVersionCompat :
> >   consts->GLSLVersion;
> > @@ -1077,6 +1079,13 @@ void st_init_extensions(struct pipe_screen *screen,
> >
> > consts->AllowGLSLCrossStageInterpolationMismatch = 
> > options->allow_glsl_cross_stage_interpolation_mismatch;
> >
> > +   /* Technically we are turning on the EXT_gpu_shader5 extension,
> > +* ARB_gpu_shader5 does not exist in GLES, but this flag is what
> > +* switches on EXT_gpu_shader5:
> > +*/
> > +   if (api == API_OPENGLES2 && ESSLVersion >= 320)
> > +  extensions->ARB_gpu_shader5 = GL_TRUE;
> > +
> > if (GLSLVersion >= 400)
> >extensions->ARB_gpu_shader5 = GL_TRUE;
> > if (GLSLVersion >= 410)
> > @@ -1540,16 +1549,12 @@ void st_init_extensions(struct pipe_screen *screen,
> >extensions->EXT_shader_integer_mix;
> >
> > extensions->OES_texture_cube_map_array =
> > -  extensions->ARB_ES3_1_compatibility &&
> > +  (extensions->ARB_ES3_1_compatibility || ESSLVersion >= 310) &&
>
> It's a bit more work, but if you get all the drivers to properly
> expose this cap, you could make this *just* ESSLVersion >= x, instead
> of also relying on the ARB_* thing. Totally your call, just wanted to
> make the observation.
>
> >extensions->OES_geometry_shader &&
> >extensions->ARB_texture_cube_map_array;
> >
> > -   extensions->OES_viewport_array =
> > -  extensions->ARB_ES3_1_compatibility &&
> > -  extensions->OES_geometry_shader &&
> > -  extensions->ARB_viewport_array;
> > -
> > -   extensions->OES_primitive_bounding_box = 
> > extensions->ARB_ES3_1_compatibility;
> > +   extensions->OES_primitive_bounding_box =
> > +  extensions->ARB_ES3_1_compatibility || (ESSLVersion >= 310);
> > consts->NoPrimitiveBoundingBoxOutput = true;
> >
> > extensions->ANDROID_extension_pack_es31a =
> > @@ -1590,6 +1595,11 @@ void st_init_extensions(struct pipe_screen *screen,
> >extensions->ARB_texture_stencil8 &&
> >extensions->ARB_texture_multisample;
> >
> > +   extensions->OES_viewport_array =
> > +  (extensions->ARB_ES3_2_compatibility || ESSLVersion >= 320) &&
>
> Why is this getting bumped up to needing ES 3.2? Did you mean to leave
> this at ES3_1_compat || ESSL >= 310?
>
> "OpenGL ES 3.2, EXT_geometry_shader or OES_geometry_shader is
> required." (Note the "or". Otherwise it'd make no sense since ES 3.2
> includes geometry shaders as core functionality.)

yeah, moving it was intentional, but maybe based on mis-parsing the
spec dependencies and applying the 'C' order of operator precedence to
english.. :-P

BR,
-R

>
>
> > +  extensions->OES_geometry_shader &&
> > +  extensions->ARB_viewport_array;
> > +
> > if (screen->get_param(screen, 
> > PIPE_CAP_CONSERVATIVE_RASTER_POST_SNAP_TRIANGLES) &&
> > screen->get_param(screen, 
> > PIPE_CAP_CONSERVATIVE_RASTER_POST_SNAP_POINTS_LINES) &&
> > screen->get_param(screen, 
> > PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE)) {
> > --
> > 2.20.1
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev