Re: [Mesa-dev] Static thread safety checking with clang

[Kristian Høgsberg]

On Tue, Nov 10, 2020 at 8:00 PM Chia-I Wu  wrote:
>
> On Tue, Nov 10, 2020 at 8:09 AM Kristian Høgsberg  wrote:
> >
> > Hi,
> >
> > I wanted to call attention to
> >
> >   https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7529
> >
> > which shows how we can use a new clang __attribute__ to statically
> > check locking invariants. It's probably not perfect, but more like
> > static type checking - there will always be cases where you can't
> > statically determine if the code is right or wrong, but it will be
> > useful and correct in most cases (like in the MR).  The attributes
> > have a few quirks and I suspect that they were mostly designed and
> > tested to work for C++ classes, but I found a way to make it work for
> > C.
> >
> > For each type of lock, declare a lock capability:
> >
> >   extern lock_cap_t fd_screen_lock_cap;
> >
> > Functions that take and release that lock get annotated with:
> >
> >   static inline void
> >   fd_screen_lock(struct fd_screen *screen)
> > acquire_cap(fd_screen_lock_cap);
> >
> >   static inline void
> >   fd_screen_unlock(struct fd_screen *screen)
> > release_cap(fd_screen_lock_cap)
> >
> > where acquire_cap and release_cap are #defines for an __attribute__.
> > One of the quirks is that the function doing the locking triggers a
> > warning about how it doesn't actually take the lock, so I silenced
> > that by adding a no_thread_safety_analysis in there.
> >
> > Now whenever we have a function that expects to be called with that
> > lock held (we often call them foo_locked) we can add the requires_cap
> > annotation:
> >
> >   static struct gmem_key *
> >   gmem_key_init(struct fd_batch *batch, bool assume_zs, bool no_scis_opt)
> > requires_cap(fd_screen_lock_cap)
> >
> > and calls to this function will warn or error if called from a point
> > where it's not statically determinable that you've taken the lock:
> >
> > ../../master/src/gallium/drivers/freedreno/freedreno_gmem.c:532:25:
> > error: calling function 'gmem_key_init' requires holding lock
> > 'fd_screen_lock_cap' exclusively [-Werror,-Wthread-safety-analysis]
> > struct gmem_key *key = gmem_key_init(batch, assume_zs, no_scis_opt);
> >^
> > 1 error generated.
>
> fd_screen_lock_cap seems to be a placeholder here.  Is it one of the
> quirks?  It would be nice if the error message reads "... requiring
> hold lock '>lock' exclusively".
>
> From https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#mutex-h,
> wrapping of the threading api is expected.  I wonder if we can
> annotate simple_mtx_t (and other in-tree locking wrappers), and
> perhaps kepp lock_cap_t only for code that uses mtx_t or
> pthread_mutex_t directly.

I couldn't get the guarded_by attribute to work with anything other
than a global variable. I suspect for C++ there's an implicit 'this'
in play that allows it to refer to class members. Similar for the
other attributes that refer to capabilities.

> > Many functions that assert a lock is taken are better off using the
> > requires_cap annotation, which makes the check a compile failure
> > instead. For cases where it's not possible to determine statically, we
> > can still assert at runtime:
> >
> >   static inline void
> >   fd_screen_assert_locked(struct fd_screen *screen)
> > assert_cap(fd_screen_lock_cap)
> >
> > which tells the checker to assume the lock is taken.  Finally, it's
> > possible to annotate struct members:
> >
> >   struct fd_gmem_cache gmem_cache guarded_by(fd_screen_lock_cap);
> >
> > such that any access to that field can only happen with the lock taken:
> >
> > ../../master/src/gallium/drivers/freedreno/freedreno_gmem.c:277:20:
> > error: reading variable 'gmem_cache' requires holding lock
> > 'fd_screen_lock_cap' [-Werror,-Wthread-safety-analysis]
> > rzalloc(screen->gmem_cache.ht, struct 
> > fd_gmem_stateobj);
> > ^
> > Having these annotations also helps human readers of the code by
> > spelling out the conventions explicitly instead of relying on _locked
> > suffix conventions or documentation that call out which parts of a
> > struct are protected by which lock. All in all this seems really
> > useful.
> 100% agreed.
>
> >
> > 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

[Mesa-dev] Static thread safety checking with clang

[Kristian Høgsberg]

Hi,

I wanted to call attention to

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

which shows how we can use a new clang __attribute__ to statically
check locking invariants. It's probably not perfect, but more like
static type checking - there will always be cases where you can't
statically determine if the code is right or wrong, but it will be
useful and correct in most cases (like in the MR).  The attributes
have a few quirks and I suspect that they were mostly designed and
tested to work for C++ classes, but I found a way to make it work for
C.

For each type of lock, declare a lock capability:

  extern lock_cap_t fd_screen_lock_cap;

Functions that take and release that lock get annotated with:

  static inline void
  fd_screen_lock(struct fd_screen *screen)
acquire_cap(fd_screen_lock_cap);

  static inline void
  fd_screen_unlock(struct fd_screen *screen)
release_cap(fd_screen_lock_cap)

where acquire_cap and release_cap are #defines for an __attribute__.
One of the quirks is that the function doing the locking triggers a
warning about how it doesn't actually take the lock, so I silenced
that by adding a no_thread_safety_analysis in there.

Now whenever we have a function that expects to be called with that
lock held (we often call them foo_locked) we can add the requires_cap
annotation:

  static struct gmem_key *
  gmem_key_init(struct fd_batch *batch, bool assume_zs, bool no_scis_opt)
requires_cap(fd_screen_lock_cap)

and calls to this function will warn or error if called from a point
where it's not statically determinable that you've taken the lock:

../../master/src/gallium/drivers/freedreno/freedreno_gmem.c:532:25:
error: calling function 'gmem_key_init' requires holding lock
'fd_screen_lock_cap' exclusively [-Werror,-Wthread-safety-analysis]
struct gmem_key *key = gmem_key_init(batch, assume_zs, no_scis_opt);
   ^
1 error generated.

Many functions that assert a lock is taken are better off using the
requires_cap annotation, which makes the check a compile failure
instead. For cases where it's not possible to determine statically, we
can still assert at runtime:

  static inline void
  fd_screen_assert_locked(struct fd_screen *screen)
assert_cap(fd_screen_lock_cap)

which tells the checker to assume the lock is taken.  Finally, it's
possible to annotate struct members:

  struct fd_gmem_cache gmem_cache guarded_by(fd_screen_lock_cap);

such that any access to that field can only happen with the lock taken:

../../master/src/gallium/drivers/freedreno/freedreno_gmem.c:277:20:
error: reading variable 'gmem_cache' requires holding lock
'fd_screen_lock_cap' [-Werror,-Wthread-safety-analysis]
rzalloc(screen->gmem_cache.ht, struct fd_gmem_stateobj);
^
Having these annotations also helps human readers of the code by
spelling out the conventions explicitly instead of relying on _locked
suffix conventions or documentation that call out which parts of a
struct are protected by which lock. All in all this seems really
useful.

Kristian
___
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"?

[Kristian Høgsberg]

On Mon, Aug 3, 2020 at 10:16 AM Eric Anholt  wrote:
>
> On Mon, Aug 3, 2020 at 8:30 AM Jason Ekstrand  wrote:
> >
> > All,
> >
> > I'm sure by now you've all seen the articles, LKML mails, and other
> > chatter around inclusive language in software.  While mesa doesn't
> > provide a whole lot of documentation (hah!), we do have a website, a
> > code-base, and a git repo and this is something that we, as a project
> > should consider.
> >
> > What I'm proposing today is simply re-naming the primary Git branch
> > from "master" to "main".  Why "main"?  Because that's what GitHub has
> > chosen "main" as their new default branch name and so it sounds to me
> > like the most likely new default.
> >
> > As far as impact on the project goes, if and when we rename the
> > primary branch, the old "master" branch will be locked (no
> > pushing/merging allowed) and all MRs will have to be re-targeted
> > against the new branch.  Fortunately, that's very easy to do.  You
> > just edit the MR and there's a little drop-down box at the top for
> > which branch it targets.  I just tested this with one of mine and it
> > seems to work ok.
> >
> > As far as other bits of language in the code-base, I'm happy to see
> > those cleaned up as people have opportunity.  I'm not aware of any
> > particularly egregious offenders.  However, changing the name of the
> > primary branch is something which will cause a brief hiccup in
> > people's development process and so warrants broader discussion.
> >
> > Thoughts?
>
> +1 from me

Let's go!

> ___
> 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?

[Kristian Høgsberg]

On Mon, Mar 30, 2020, 7:59 AM Adam Jackson  wrote:

> On Sun, 2020-03-29 at 09:45 -0700, Kristian Høgsberg wrote:
>
> > As for loading, doesn't glvnd solve that?
>
> It could. It does not. Right now there's not a (good) way for the DDX
> driver to communicate a preferred implementation name to the GLX
> client. xserver's glx just knows it needs an implementation named mesa,
> and nvidia's glx, nvidia. Not a hard thing to wire up, and in fact you
> can give multiple names and the client side will try them in sequence
> so fallback stands a chance of working.
>
> Now, if we're doing that, we should maybe consider using glvnd's
> libGLdispatch directly, as I think right now we have an ugly double-
> indirection between glHamSandwichEXT and _mesa_HamSandwichEXT if you're
> building for glvnd. The only thing in the world besides Mesa that cares
> about glapi and what a DRI driver interface is is xserver, and that's a
> detail I'd like to eliminate and the new EGL-backed GLX in Xwayland
> gets really close to eliminating it. But if nobody else gets excited
> that much about fixing GLX, I completely understand.
>

Yeah it would make sense to disable the double dispatch and it would be
tempting to get rid of dri driver loading entirely then...

- ajax
>
>
___
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?

[Kristian Høgsberg]

On Sun, Mar 29, 2020, 4:09 PM Jason Ekstrand  wrote:

> On Sun, Mar 29, 2020 at 6:06 PM Bas Nieuwenhuizen
>  wrote:
> >
> > On Sun, Mar 29, 2020 at 11:36 PM Eric Engestrom 
> wrote:
> > >
> > >
> > >
> > > On 2020-03-29 at 20:58, Jason Ekstrand  wrote:
> > > > On Sun, Mar 29, 2020 at 11:45 AM Kristian Høgsberg <
> hoegsb...@gmail.com> wrote:
> > > > >
> > > > > As for loading, doesn't glvnd solve that?
> > > >
> > > > Not really.  There are still problems if you have HW drivers from
> both
> > > > repos on the same system and someone has to decide which one to use.
> > > > We would either have to come up with a good solution to that problem
> > > > or we would have to delete/disable all of the drivers still in master
> > > > in the LTS branch.  In any case, there are real problems to solve
> > > > there.
> > >
> > > That's a simple packaging issue, and IMO it's ok to just say in the
> announcement
> > > email "this 'legacy drivers' branch also contains old versions of the
> new
> > > drivers. If you ship both these and a modern version of Mesa, make sure
> > > not to build the same drivers from both trees".
> > >
> > > Packagers will then pick the right `-D{dri,gallium,vulkan}-drivers=`
> lists
> > > to avoid collisions on their distros.
> >
> > Wouldn't this be much safer anyway with a small patch to remove those
> > "new" drivers from the meson options list?
>
> It may not be that simple.  If, for instance, we wanted to cut of Gen7
> Vulkan, we would somehow have to provide an option to limit which
> hardware generations are supported in the LTS branch.  Either that or
> just delete support for Gen8+ somehow.
>

The "loader problem" that I was thinking of is the while the dri driver
interface is theoretically a stable API nobody tests mixing loaders from
one mesa release with drivers from another. glvnd does solve that problem
and deciding which Intel gens should be supported by i965 or iris *is* a
simple packaging problem.

As for anv splitting out gen7 support that's orthogonal, local to anv and
less relevant to the decision about dropping legacy dri drivers and go all
gallium. I know it's close to your heart, of course, but since vulkan had a
standard loader interface since day 1, it seems like something you can
decide on independently.


> --Jason
>
___
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?

[Kristian Høgsberg]

As for loading, doesn't glvnd solve that?

On Sun, Mar 29, 2020, 1:19 AM Marek Olšák  wrote:

> If you want a complete fork or removal, that's fine with me. It's
> technically more challenging for driver loaders and packaging though.
>
> Marek
>
> On Sun., Mar. 29, 2020, 02:51 Jason Ekstrand, 
> wrote:
>
>> On Sat, Mar 28, 2020 at 11:41 PM Marek Olšák  wrote:
>> >
>> > The #include spaghetti will be resolved before the split. I don't care
>> about including gallium, but no code will include src/mesa outside of that.
>>
>> If we make sure that we modify the #include guards on every header in
>> src/mesa_classic so that any accidental cross-includes lead to double
>> definitions and therefore compile errors, that would probably help.
>> It'd certainly give me a lot more confidence that we've done it right.
>>
>> > The biggest part is to make src/compiler completely independent and
>> that's a worthy goal by itself.
>>
>> Yeah, I've wanted to see that happen since we started splitting stuff
>> out to make Vulkan a possibility.
>>
>> > Milestones:
>> > - make src/compiler a standalone lib
>> > - don't include src/mesa in other places
>> > - split classic drivers into src/mesa_classic
>>
>> If you're willing to do the work, I guess I'm not opposed for now.
>>
>> That said, I also have some somewhat selfish reasons for wanting to do
>> a fork.  In particular, I'd like to freeze i965 and possibly Gen7
>> Vulkan in time so that we can stop maintaining the i965 and the old
>> vec4 back-end compiler.  Even though we're not adding features, I
>> still find myself having to fix those up from time to time due to
>> reworks elsewhere.  Maybe the answer is to copy and isolate them too
>> but, at that point, why not just put them in a branch?
>>
>> --Jason
>>
>>
>> > Marek
>> >
>> > On Sun., Mar. 29, 2020, 00:08 Jason Ekstrand, 
>> wrote:
>> >>
>> >> On Wed, Mar 25, 2020 at 6:32 PM Marek Olšák  wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke <
>> kenn...@whitecape.org> 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.
>> >> >
>> >> >
>> >> > If classic drivers were moved to src/mesa_classic, nothing would
>> change for downstream.
>> >>
>> >> I'm concerned that doing that is just asking for more maintenance
>> >> problems than we have today.  One of the problems we currently have is
>> >> that our #includes are still spaghetti.  We've got stuff in src/util
>> >> which inclues stuff in gallium as well as stuff in mesa/main.  If we
>> >> even have one cross-wired include, it could lead to bezar and nearly
>> >> impossible to trace bugs due to ABI incompatibility between the two
>> >> copies of src/mesa the moment we start changing structs or function
>> >> prototypes.  The obvious answer to this is "we'll sort out the
>> >> spaghetti mess".  However, that also means serious changes to
>> >> src/compiler/glsl because it includes mtypes.h.  Do we clone that too?
>> >>  I honestly think that this particular cure is likely far worse than
>> >> the disease of having to do careful testing of src/mesa changes.
>> >>
>> >> IMO, a far better plan would be to give it one more year so that
>> >> distros and users get experience with iris and then fork off an LTS
>> >> branch and delete all the legacy stuff from master.  We can continue
>> >> to do maintenance in the LTS branch as needed but I honestly don't
>> >> expect much work to happen there.  The most difficult thing will be
>> >> deciding what to remove from master but I don't want to make that
>> >> decision today.  However, doing a clean fork means we 

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

[Kristian Høgsberg]

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

If we're taking a step back here, I also want to recognize what a
tremendous success this has been so far and thank everybody involved
for building something so useful. Between gitlab and the CI, our
workflow has improved and code quality has gone up.  I don't have
anything useful to add to the technical discussion, except that that
it seems pretty standard engineering practice to build a system,
observe it and identify and eliminate bottlenecks. Planning never
hurts, of course, but I don't think anybody could have realistically
modeled and projected the cost of this infrastructure as it's grown
organically and fast.

Kristian

> Look at this from a sponsor POV, why would I give X.org/fd.o
> sponsorship money that they are just giving straight to google to pay
> for hosting credits? Google are profiting in some minor way from these
> hosting credits being bought by us, and I assume we aren't getting any
> sort of discounts here. Having google sponsor the credits costs google
> substantially less than having any other company give us money to do
> it.
>
> If our current CI architecture is going to burn this amount of money a
> year and we hadn't worked this out in advance of deploying it then I
> suggest the system should be taken offline until we work out what a
> sustainable system would look like within the budget we have, whether
> that be never transferring containers and build artifacts from the
> google network, just having local runner/build combos etc.
>
> Dave.
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
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?

[Kristian Høgsberg]

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

Nobody is entitled to remove the code, that's why we're having this
discussion. And I bet it's frustrating for you to have to deal with
this again and again, but on the other side, it's frustrating to see
this issue come up again and again with no evident progress
whatsoever. What has happened on your side since the last time this
was discussed? When is that "one day"? How are we supposed to move
this forward without bringing it up?

As for removing code that works - we do that All. The. Time. We
refactor subsystems, IRs, entire drivers get rewritten and replace the
working code that was there before, in order the lower the maintenance
burden, run across more platforms, shader a compiler pass, reduce
techincal debt etc.

Kristian

>
> Jose
>
> 
> From: Kristian Høgsberg 
> Sent: Wednesday, February 26, 2020 18:37
> To: Jason Ekstrand 
> Cc: Rob Clark ; mesa-dev 
> ; Dylan Baker ; Jose 
> Fonseca ; Brian Paul 
> Subject: Re: [Mesa-dev] Drop scons for 20.1?
>
> On Tue, Feb 25, 2020 at 8:15 PM Jason Ekstrand  wrote:
> >
> > +Jose & Brian
> >
> > I'm not personally opposed but I also can't remember the last time I had to
> > fix the scons build. I think it's been years. Maybe that's because I don't
> > work on GL anymore? In any case, I don't know that it's really costing us
> > that much given that basically none of the drivers actually build with it.
> > But fat meh, I guess.
>
> Maybe it is a bit meh... I did the MR to remove SCons and it's smaller
> that I thought it would be:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F3955data=02%7C01%7Cjfonseca%40vmware.com%7C6b2e8f2abc98458d18ad08d7baeb0443%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637183390863817583sdata=96lM4flW9ja6fJG95nlNdmftNiYpajxpg0Il850%2FDLk%3Dreserved=0
>
> 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. But
> whenever it comes up, Dylan maybe fixes something on the windows
> build, we talk about trying to switch Windows to meson and then...
> nothing.
>
> Also, we've had this unfortunate split between Linux and Windows build
> systems where autotools suck on Windows and nobody on Unix ever had a
> reason to use SCons.  With meson we've picked something that's a
> legitimate improvement on both sides, get's us back to one build
> system and done more than due dilligence to make it work on Windows
> and we're not taking the last step because... meh?
>
> Kristian
>
> > --Jason
> >
> > On February 25, 2020 21:56:30 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.
> > >
> > > 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
> > >>

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

[Kristian Høgsberg]

On Tue, Feb 25, 2020 at 8:15 PM Jason Ekstrand  wrote:
>
> +Jose & Brian
>
> I'm not personally opposed but I also can't remember the last time I had to
> fix the scons build. I think it's been years. Maybe that's because I don't
> work on GL anymore? In any case, I don't know that it's really costing us
> that much given that basically none of the drivers actually build with it.
> But fat meh, I guess.

Maybe it is a bit meh... I did the MR to remove SCons and it's smaller
that I thought it would be:

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

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. But
whenever it comes up, Dylan maybe fixes something on the windows
build, we talk about trying to switch Windows to meson and then...
nothing.

Also, we've had this unfortunate split between Linux and Windows build
systems where autotools suck on Windows and nobody on Unix ever had a
reason to use SCons.  With meson we've picked something that's a
legitimate improvement on both sides, get's us back to one build
system and done more than due dilligence to make it work on Windows
and we're not taking the last step because... meh?

Kristian

> --Jason
>
> On February 25, 2020 21:56:30 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.
> >
> > 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
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Drop scons for 20.1?

[Kristian Høgsberg]

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

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

[Kristian Høgsberg]

On Wed, Dec 4, 2019 at 10:31 AM Rob Clark  wrote:
>
> 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).

Another option would be to do a LTS-kind of release of mesa and then
drop the non-gallium drivers. It could even be limited in scope to the
non-gallium drivers, in the sense that we'd only do releases for fixes
to those drivers. It's basically option 1), but saying that we still
care about maintaining the drivers, but they wont receive new
features. With i965 being at GL 4.6, I don't think that's an
unreasonable stance (contrast with years ago when i965 feature level
was lagging the hw capability and spec).

At the end of the day, it will impact the Intel team the most and I
think it's largely their call.

Kristian

>
> 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] Call shmget() with permission 0600 instead of 0777

[Kristian Høgsberg]

Looks good,

Reviewed-by: Kristian H. Kristensen 

On Tue, Nov 12, 2019 at 10:47 AM Brian Paul  wrote:
>
> Ping again.
>
>
> On 10/24/2019 03:25 PM, Brian Paul wrote:
> > Ping.  Anyone?
> >
> > -Brian
> >
> > On Tue, Oct 22, 2019 at 3:52 PM Brian Paul  > > wrote:
> >
> > A security advisory (TALOS-2019-0857/CVE-2019-5068) found that
> > creating shared memory regions with permission mode 0777 could allow
> > any user to access that memory.  Several Mesa drivers use shared-
> > memory XImages to implement back buffers for improved performance.
> >
> > This path changes the shmget() calls to use 0600 (user r/w).
> >
> > Tested with legacy Xlib driver and llvmpipe.
> >
> > Cc: mesa-sta...@lists.freedesktop.org
> > 
> > ---
> >   src/gallium/winsys/sw/dri/dri_sw_winsys.c   | 3 ++-
> >   src/gallium/winsys/sw/xlib/xlib_sw_winsys.c | 3 ++-
> >   src/mesa/drivers/x11/xm_buffer.c| 3 ++-
> >   3 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
> > b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
> > index 761f5d1..2e5970b 100644
> > --- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
> > +++ b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
> > @@ -92,7 +92,8 @@ alloc_shm(struct dri_sw_displaytarget *dri_sw_dt,
> > unsigned size)
> >   {
> >  char *addr;
> >
> > -   dri_sw_dt->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT|0777);
> > +   /* 0600 = user read+write */
> > +   dri_sw_dt->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT | 0600);
> >  if (dri_sw_dt->shmid < 0)
> > return NULL;
> >
> > diff --git a/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c
> > b/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c
> > index c14c9de..edebb48 100644
> > --- a/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c
> > +++ b/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c
> > @@ -126,7 +126,8 @@ alloc_shm(struct xlib_displaytarget *buf,
> > unsigned size)
> >  shminfo->shmid = -1;
> >  shminfo->shmaddr = (char *) -1;
> >
> > -   shminfo->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT|0777);
> > +   /* 0600 = user read+write */
> > +   shminfo->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT | 0600);
> >  if (shminfo->shmid < 0) {
> > return NULL;
> >  }
> > diff --git a/src/mesa/drivers/x11/xm_buffer.c
> > b/src/mesa/drivers/x11/xm_buffer.c
> > index d945d8a..0da08a6 100644
> > --- a/src/mesa/drivers/x11/xm_buffer.c
> > +++ b/src/mesa/drivers/x11/xm_buffer.c
> > @@ -89,8 +89,9 @@ alloc_back_shm_ximage(XMesaBuffer b, GLuint width,
> > GLuint height)
> > return GL_FALSE;
> >  }
> >
> > +   /* 0600 = user read+write */
> >  b->shminfo.shmid = shmget(IPC_PRIVATE,
> > b->backxrb->ximage->bytes_per_line
> > -* b->backxrb->ximage->height,
> > IPC_CREAT|0777);
> > + * b->backxrb->ximage->height,
> > IPC_CREAT | 0600);
> >  if (b->shminfo.shmid < 0) {
> > _mesa_warning(NULL, "shmget failed while allocating back
> > buffer.\n");
> > XDestroyImage(b->backxrb->ximage);
> > --
> > 1.8.5.6
> >
> > ___
> > 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] [PATCH] s/APIENTRY/GLAPIENTRY/ in teximage.c

[Kristian Høgsberg]

On Mon, Nov 11, 2019 at 3:45 PM Brian Paul  wrote:
>
> The later is the right symbol for entrypoint functions.

Reviewed-by: Kristian H. Kristensen 

> ---
>  src/mesa/main/texgetimage.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
> index e43f336..d6ec4c5 100644
> --- a/src/mesa/main/texgetimage.c
> +++ b/src/mesa/main/texgetimage.c
> @@ -1969,7 +1969,7 @@ _mesa_GetCompressedTextureImage(GLuint texture, GLint 
> level,
>  }
>
>
> -void APIENTRY
> +void GLAPIENTRY
>  _mesa_GetCompressedTextureSubImage(GLuint texture, GLint level,
> GLint xoffset, GLint yoffset,
> GLint zoffset, GLsizei width,
> --
> 1.8.5.6
>
> ___
> 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] Switching to Gitlab Issues instead of Bugzilla?

[Kristian Høgsberg]

On Wed, Sep 18, 2019 at 8:45 AM Adam Jackson  wrote:
>
> On Thu, 2019-08-29 at 11:52 -0700, Kenneth Graunke wrote:
>
> > 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.
>
> It's been almost three weeks, and this seems to have resulted in broad
> consensus and very little objection, mostly around how to build
> searches effectively. So, let's do it.
>
> I've enabled filing issues for the remaining mesa projects that didn't
> have it already (vkpipeline-db, shader-db, drm, and mesa itself). I
> also turned merge requests on for mesa/drm (which is just libdrm, not
> the kernel). I'll be going through bugzilla for the Mesa and DRI
> products and migrating or closing bugs as appropriate. After each
> component is migrated it will be closed for bug entry, so there will be
> a small window here where bugs can be filed in two places, hopefully
> this shouldn't cause too much confusion.

Thanks Adam! I moved the freedreno bugs from krh/mesa to mesa/mesa.
For reference, here's the commandline I pieced together from Adam's
pointers:

https://docs.gitlab.com/ee/api/issues.html#move-an-issue

and

https://gitlab.freedesktop.org/profile/personal_access_tokens

and then:

for i in {1..46}; do echo move issue $i; curl --header "PRIVATE-TOKEN:
$token" --form to_project_id=176
https://gitlab.freedesktop.org/api/v4/projects/420/issues/$i/move;
echo; done

Kristian

> The remaining bikeshed here is the drm kernel repository, and
> relatedly, what to do with bugs that are kernel issues. For now I'm
> going to handle that by trying to avoid migrating obvious kernel
> issues. There's the outline of a migration plan already in:
>
> https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/69
>
> If the kernel maintainers are ready to move the canonical repo URL and
> issues, then let's get that moving sooner rather than later.
>
> For progress on the migration, suggestions about how and where to move
> issues, etc., please see:
>
> https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/190
>
> - ajax
>
> ___
> 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] Switching to Gitlab Issues instead of Bugzilla?

[Kristian Høgsberg]

On Thu, Aug 29, 2019 at 12:44 PM Chris Wilson  wrote:
>
> Quoting Kenneth Graunke (2019-08-29 19:52:51)
> > 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...)
>
> All that I ask is that we move the kernel bugzilla along with it. Trying
> to keep abreast of the bugs in the whole stack is important. Fwiw, the
> kernel contains the https:bugs.freedesktop.org/enter_bug.cgi?product=DRI
> URL so would need some redirection for a few years...

Would Rob's suggestion of creating a placeholder drm kernel repo for
the purpose of issue tracking work for you?

Kristian

> -Chris
> ___
> 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] Switching to Gitlab Issues instead of Bugzilla?

[Kristian Høgsberg]

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...)
>
> 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.

Definitely in favor here. We've been using it for tracking freedreno
issues over in my gitlab mesa, but would much prefer to use the main
repo.

Kristian

> --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] [MR] Update README to recommend MRs instead of `git send-email`

[Kristian Høgsberg]

On Tue, Jul 9, 2019 at 12:17 AM Daniel Stone  wrote:
>
> Hi,
>
> On Sat, 6 Jul 2019 at 18:39, Ilia Mirkin  wrote:
> > I see this as driving away contributions, esp from new people. MR's
> > are annoying to create, since they require dealing with the hosting
> > provider, getting it to host clones, etc. Everyone has email.
>
> My position - and the evidence of velocity from projects who have
> switched - is already pretty clear, but you might be interested to
> read that even kernel.org admins are trying to move away from email:
> https://people.kernel.org/monsieuricon/patches-carved-into-developer-sigchains

I have the same experience - I've used git since before it was usable
and I'm more than happy to not have to worry about making git
send-email work. I'm pretty sure that gitlab in general lowers the bar
for contributions considerably, I know I find my self doing a lot more
reviews and drive-by comments because of how easy it feels.

> Cheers,
> Daniel
> ___
> 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] nir: silence three compiler warnings seen with MinGW

[Kristian Høgsberg]

Reviewed-by: Kristian H. Kristensen 

On Thu, May 23, 2019 at 9:52 AM Brian Paul  wrote:
>
> Ping.
>
> -Brian
>
> On 05/20/2019 07:36 AM, Brian Paul wrote:
> > Silence two unused var warnings.  And init elem_size, elem_align to
> > zero to silence "maybe uninitialized" warnings.
> > ---
> >   src/compiler/nir/nir_lower_int_to_float.c | 2 +-
> >   src/compiler/nir/nir_opt_copy_prop_vars.c | 4 +---
> >   src/compiler/nir_types.cpp| 2 +-
> >   3 files changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/compiler/nir/nir_lower_int_to_float.c 
> > b/src/compiler/nir/nir_lower_int_to_float.c
> > index 439afa0..66a740d9 100644
> > --- a/src/compiler/nir/nir_lower_int_to_float.c
> > +++ b/src/compiler/nir/nir_lower_int_to_float.c
> > @@ -28,7 +28,7 @@
> >   static bool
> >   assert_ssa_def_is_not_int(nir_ssa_def *def, void *arg)
> >   {
> > -   BITSET_WORD *int_types = arg;
> > +   MAYBE_UNUSED BITSET_WORD *int_types = arg;
> >  assert(!BITSET_TEST(int_types, def->index));
> >  return true;
> >   }
> > diff --git a/src/compiler/nir/nir_opt_copy_prop_vars.c 
> > b/src/compiler/nir/nir_opt_copy_prop_vars.c
> > index 94bc8af..0fd96b7 100644
> > --- a/src/compiler/nir/nir_opt_copy_prop_vars.c
> > +++ b/src/compiler/nir/nir_opt_copy_prop_vars.c
> > @@ -433,9 +433,7 @@ load_element_from_ssa_entry_value(struct 
> > copy_prop_var_state *state,
> > nir_builder *b, nir_intrinsic_instr 
> > *intrin,
> > struct value *value, unsigned index)
> >   {
> > -   const struct glsl_type *type = entry->dst->type;
> > -   unsigned num_components = glsl_get_vector_elements(type);
> > -   assert(index < num_components);
> > +   assert(index < glsl_get_vector_elements(entry->dst->type));
> >
> >  /* We don't have the element available, so let the instruction do the 
> > work. */
> >  if (!entry->src.ssa.def[index])
> > diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
> > index 3bf93c5..e2dfc40 100644
> > --- a/src/compiler/nir_types.cpp
> > +++ b/src/compiler/nir_types.cpp
> > @@ -630,7 +630,7 @@ glsl_get_natural_size_align_bytes(const struct 
> > glsl_type *type,
> > *size = 0;
> > *align = 0;
> > for (unsigned i = 0; i < type->length; i++) {
> > - unsigned elem_size, elem_align;
> > + unsigned elem_size = 0, elem_align = 0;
> >glsl_get_natural_size_align_bytes(type->fields.structure[i].type,
> >  _size, _align);
> >*align = MAX2(*align, elem_align);
> >
>
> ___
> 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] Add an ASSERTED macro to use in place of MAYBE_UNUSED?

[Kristian Høgsberg]

On Mon, Apr 22, 2019 at 3:11 PM Matt Turner  wrote:
>
> On Mon, Apr 22, 2019 at 1:09 PM Kristian Høgsberg  wrote:
> >
> > On Mon, Apr 22, 2019 at 12:11 PM Jason Ekstrand  
> > wrote:
> > >
> > > All,
> > >
> > > I've seen discussions come up several times lately about whether you 
> > > should use MAYBE_UNUSED or UNUSED in what scenario and why do we have two 
> > > of them anyway.  That got me thinking a bit.  Maybe what we actually want 
> > > instead of MAYBE_UNUSED is something like this:
> > >
> > > #ifdef NDEBUG
> > > #define ASSERTED UNUSED
> > > #else
> > > #define ASSERTED
> > > #endif
> > >
> > > That way, if you only need a parameter for asserts, you can declare it 
> > > ASSERTED and it won't warn in release builds will still throw a warning 
> > > if you do a debug build which doesn't use it.  Of course, there are other 
> > > times when something is validly MAYBE_UNUSED such as auto-generated code 
> > > or the genX code we use on Intel.  However, this provides additional 
> > > meaning and means the compiler warnings are still useful even after 
> > > you've relegated a value to assert-only.
> > >
> > > Thoughts?  I'm also open to a better name; that's the best I could do in 
> > > 5 minutes.
> >
> > I think that's going in the wrong direction - if anything I think that
> > having both UNUSED and MAYBE_UNUSED is redundant and feel that just
> > UNUSED would be fine. __attribute__((unused)) doesn't mean "strictly
> > not used", it means "don't warn if this isn't used".
>
> I agree that having both UNUSED and MAYBE_UNUSED is silly and I would
> be happy to see MAYBE_UNUSED go away.
>
> I think the advantage of Jason's proposal is that we are alerted if
> there is actually dead code. E.g., if we remove the assert that used a
> variable, we currently won't get a warning from the compiler that the
> variable is unused. At least in release builds we would, if we did
> what Jason suggests.
>
> Maybe we do what Jason suggests and then remove MAYBE_UNUSED?

Right... I see now, that's sounds reasonable.

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

Re: [Mesa-dev] Add an ASSERTED macro to use in place of MAYBE_UNUSED?

[Kristian Høgsberg]

On Mon, Apr 22, 2019 at 12:11 PM Jason Ekstrand  wrote:
>
> All,
>
> I've seen discussions come up several times lately about whether you should 
> use MAYBE_UNUSED or UNUSED in what scenario and why do we have two of them 
> anyway.  That got me thinking a bit.  Maybe what we actually want instead of 
> MAYBE_UNUSED is something like this:
>
> #ifdef NDEBUG
> #define ASSERTED UNUSED
> #else
> #define ASSERTED
> #endif
>
> That way, if you only need a parameter for asserts, you can declare it 
> ASSERTED and it won't warn in release builds will still throw a warning if 
> you do a debug build which doesn't use it.  Of course, there are other times 
> when something is validly MAYBE_UNUSED such as auto-generated code or the 
> genX code we use on Intel.  However, this provides additional meaning and 
> means the compiler warnings are still useful even after you've relegated a 
> value to assert-only.
>
> Thoughts?  I'm also open to a better name; that's the best I could do in 5 
> minutes.

I think that's going in the wrong direction - if anything I think that
having both UNUSED and MAYBE_UNUSED is redundant and feel that just
UNUSED would be fine. __attribute__((unused)) doesn't mean "strictly
not used", it means "don't warn if this isn't used".

>
> --Jason
> ___
> 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 8/8] panfrost: Add backend targeting the DRM driver

[Kristian Høgsberg]

On Mon, Mar 4, 2019 at 6:29 PM Dave Airlie  wrote:
>
> On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg  wrote:
> >
> > On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig  
> > wrote:
> > >
> > > > Why aren't we using regular dma-buf fences here? The submit ioctl
> > > > should be able to take a number of in fences to wait on and return an
> > > > out fence if requested.
> > >
> > > Ah-ha, that sounds like the "proper" approach for mainline. Much of this
> > > was (incorrectly) inherited from the Arm driver. Thank you for the
> > > pointer.
> >
> > I'm not sure - I mean, the submit should take in/out fences, but the
> > atom mechanism here sounds more like it's for declaring the
> > dependencies between multiple batches in a renderpass/frame to allow
> > the kernel to shcedule them? The sync fd may be a little to heavy
> > handed for that, and if you want to express that kind of dependency to
> > allow the kernel to reschedule, maybe we need both?
>
> You should more likely be using syncobjects, not fences.
>
> You can convert syncobjs to fences, but fences consume an fd which you
> only really want if inter-device.

Fence fd's are also required for passing through protocol for explicit
synchronization.

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

Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver

[Kristian Høgsberg]

On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig  wrote:
>
> > Why aren't we using regular dma-buf fences here? The submit ioctl
> > should be able to take a number of in fences to wait on and return an
> > out fence if requested.
>
> Ah-ha, that sounds like the "proper" approach for mainline. Much of this
> was (incorrectly) inherited from the Arm driver. Thank you for the
> pointer.

I'm not sure - I mean, the submit should take in/out fences, but the
atom mechanism here sounds more like it's for declaring the
dependencies between multiple batches in a renderpass/frame to allow
the kernel to shcedule them? The sync fd may be a little to heavy
handed for that, and if you want to express that kind of dependency to
allow the kernel to reschedule, maybe we need both?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver

[Kristian Høgsberg]

On Mon, Mar 4, 2019 at 4:43 PM Alyssa Rosenzweig  wrote:
>
> Wooo!!!
>
> Seeing this patch in my inbox has been some of the best news all day!
>
> Without further ado, my (solicited?) comments:
>
> > +/* Copyright 2018, Linaro, Ltd., Rob Herring  */
>
> Please triple check upstream that this license is okay; the other files
> in include/drm-uapi are BSDish.
>
> > +/* timeouts are specified in clock-monotonic absolute times (to simplify
> > + * restarting interrupted ioctls).  The following struct is logically the
> > + * same as 'struct timespec' but 32/64b ABI safe.
> > + */
> > +struct drm_panfrost_timespec {
> > + __s64 tv_sec;  /* seconds */
> > + __s64 tv_nsec; /* nanoseconds */
> > +};
>
> What's this for -- is there not a shared struct for this if it's
> necessary? (I'm assuming this was copied from etna..?)
>
> > + __u32 flags;  /* in, mask of ETNA_BO_x */
>
> As Rob said, s/ETNA/PAN/g
>
> > + struct drm_panfrost_timespec timeout;   /* in */
>
> (Presumably we just want a timeout in one of nanoseconds / milliseconds
> / second, not the full timespec... 64-bit time gives a pretty wide range
> even for high-precision timeouts, which I don't know that we need. Also,
> it's signed for some reason...?)
>
> > + struct drm_panfrost_gem_submit_atom_dep deps[2];
>
> I'm concerned about hardcoding deps to 2 here. I know the Arm driver
> does it, but I'm super uncomfortable by them doing it too. Keep in mind,
> when they have complex dependencies they insert dummy "dependency-only"
> jobs into the graph, though I concede I haven't seen this yet.

Why aren't we using regular dma-buf fences here? The submit ioctl
should be able to take a number of in fences to wait on and return an
out fence if requested. See I915_EXEC_FENCE_OUT and
I915_EXEC_FENCE_ARRAY in
https://cgit.freedesktop.org/~airlied/linux/tree/include/uapi/drm/i915_drm.h?h=drm-next
or MSM_SUBMIT_FENCE_FD_IN/OUT in
https://cgit.freedesktop.org/~airlied/linux/tree/include/uapi/drm/msm_drm.h?h=drm-next

> I'm not at all sure what the right number is, especially since the new
> kernel interface seems to support waiting on BOs? Or am I
> misinterpreting this?
>
> Regardless, this will start to matter when we implement support for more
> complex FBOs (where various FBOs samples from various other FBOs), which
> I think can have arbitrarily complicated dependency graphs. So
> hardcoding to [2] is inappropriate if we want to use deps for waiting on
> FBOs. On the other hand, if we use a kernel-side BO wait or fences or
> something to resolve dependencies, do we even need two deps, or just
> one?
>
> > + // TODO cache allocations
> > + // TODO properly handle errors
> > + // TODO take into account extra_flags
>
> Not a blocker at all for merge, but these should be taken care of before
> we drop support for the non-DRM stuff (since at least the
> lack of GROWABLE support represents a regression compared to the Arm
> driver).
>
> > + // TODO map and unmap on demand?
>
> I don't know if this matters too much...? Usually if we're allocating a
> slab, that means we want it mapped immediately, unless we set the
> INVISIBLE flag which means we odn't want it mapped at all.
>
> Maybe we'll have fancier scenarios in the future, but at the moment I
> think we can safely cross off at least the first half of the TODO.
>
> As you know I'm not a believer in unmapping/freeing resources ever, so I
> don't get an opinion there ;)
>
> > + gem_info.handle = gem_new.handle;
> > + ret = drmIoctl(drm->fd, DRM_IOCTL_PANFROST_GEM_INFO, _info);
> > + if (ret) {
> > +fprintf(stderr, "DRM_IOCTL_PANFROST_GEM_INFO failed: 
> > %d\n", ret);
> > + assert(0);
> > + }
>
> Maybe a question for Rob, but why isn't this info passed along with the
> allocate in the first place? I guess the extra roundtrip to the kernel
> isn't a huge deal, but it seems a little odd...?
>
> > +static uint8_t
> > +allocate_atom()
> > +{
> > + /* Use to allocate atom numbers for jobs. We probably want to 
> > overhaul this in kernel space at some point. */
> > + static uint8_t atom_counter = 0;
> > +
> > +atom_counter++;
> > +
> > +/* Workaround quirk where atoms must be strictly positive */
> > +
> > +if (atom_counter == 0)
> > +atom_counter++;
> > +
> > +return atom_counter;
> > +}
>
> So, this routine (which is copied straight from the non-DRM code) is
> specifically to workaround a quirk in the Arm driver where atom numbers
> must be non-zero u8's. I'm skeptical the DRM interface needs this.
>
> > + idx++;
>
> Nice one, no idea why I didn't think of doing it this way :)
>
> > +panfrost_fence_create(struct panfrost_context *ctx)
>
> I'd appreciate a link to documentation about mainline fences, since I
> have no idea what's happening here :)
>
> > +static void
> > +panfrost_drm_enable_counters(struct panfrost_screen *screen)
> > +{
> > +

Re: [Mesa-dev] [PATCH] intel: limit urb size for SKL/KBL/CFL GT1

[Kristian Høgsberg]

What happened to this patch? We carry it downstream for the deqp fix.
Can we get it into 19.0?

Thanks,
Kristian

On Wed, Aug 29, 2018 at 5:39 PM Lionel Landwerlin
 wrote:
>
> The documentation puts the URB size for SKL GT1 as "128K - 192K". I
> guess this means we can't tell which one it is, so we have to go for
> the lower bound. This change also changes the max VS URB entries which
> is lower on GT1 skus.
>
> Fixes a CTS test :
>
>   dEQP-GLES31.functional.geometry_shading.layered.render_with_default_layer_3d
>
> Signed-off-by: Lionel Landwerlin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107505
> ---
>  src/intel/dev/gen_device_info.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
> index b0ae4d18034..ed1e73efa61 100644
> --- a/src/intel/dev/gen_device_info.c
> +++ b/src/intel/dev/gen_device_info.c
> @@ -617,7 +617,8 @@ static const struct gen_device_info 
> gen_device_info_skl_gt1 = {
> .num_subslices = { 2, },
> .num_eu_per_subslice = 6,
> .l3_banks = 2,
> -   .urb.size = 192,
> +   .urb.size = 128,
> +   .urb.max_entries[MESA_SHADER_VERTEX] = 928,
> .simulator_id = 12,
>  };
>
> @@ -689,6 +690,8 @@ static const struct gen_device_info 
> gen_device_info_kbl_gt1 = {
> .num_subslices = { 2, },
> .num_eu_per_subslice = 6,
> .l3_banks = 2,
> +   .urb.size = 128,
> +   .urb.max_entries[MESA_SHADER_VERTEX] = 928,
> .simulator_id = 16,
>  };
>
> @@ -775,6 +778,8 @@ static const struct gen_device_info 
> gen_device_info_cfl_gt1 = {
> .num_subslices = { 2, },
> .num_eu_per_subslice = 6,
> .l3_banks = 2,
> +   .urb.size = 128,
> +   .urb.max_entries[MESA_SHADER_VERTEX] = 928,
> .simulator_id = 24,
>  };
>  static const struct gen_device_info gen_device_info_cfl_gt2 = {
> --
> 2.18.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] freedreno: Fix meson build.

[Kristian Høgsberg]

On Thu, Feb 7, 2019 at 8:03 AM Daniel Stone  wrote:
>
> On Thu, 7 Feb 2019 at 14:59, Eric Engestrom  wrote:
> > On Wednesday, 2019-02-06 18:36:09 +, Vinson Lee wrote:
> > > ../src/gallium/drivers/freedreno/freedreno_resource.c: In function 
> > > ‘fd_resource_create_with_modifiers’:
> > > ../src/gallium/drivers/freedreno/freedreno_resource.c:884:30: error: 
> > > ‘DRM_FORMAT_MOD_QCOM_COMPRESSED’ undeclared (first use in this function)
> > >allow_ubwc = find_modifier(DRM_FORMAT_MOD_QCOM_COMPRESSED, modifiers, 
> > > count);
> >
> > That's a weird error... I would've expected the `#include `
> > to fail with a "No such file". If you copied the wrong part of the error
> > message, can you update that?
>
> Presumably it just finds an outdated copy of drm_fourcc.h, which
> doesn't have the Qualcomm modifier, from the system include path.

Yes - I recommend not having include/drm-uapi in the include path and
instead include kernel headers as #include "drm-uapi/drm_fourcc.h" to
avoid pulling in system headers.

Kristian

> Cheers,
> Daniel
> ___
> 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] loader: fix the no-modifiers case

[Kristian Høgsberg]

On Tue, Jan 22, 2019 at 11:45 AM Rob Clark  wrote:
>
> Normally modifiers take precendence over use flags, as they are more
> explicit.  But if the driver supports modifiers, but the xserver does
> not, then we should fallback to the old mechanism of allocating a buffer
> using 'use' flags.
>
> Fixes: 069fdd5f9facbd72fb6a289696c7b74e3237e70f
> Signed-off-by: Rob Clark 

Reviewed-by: Kristian H. Kristensen 

> ---
> Backport note:  This fixes an issue with enabling UBWC in freedreno/a6xx
> (which is something I'd like to land soonish, but not something that
> exists yet in release branches).  Unless a similar issue is reported in
> other drivers, this may not be worth backporting to release branches, at
> least not until it has had some soak time in master.
>
> Backtrace to explain the issue:
>
>   Breakpoint 1, fd_resource_create_with_modifiers (pscreen=0x574ae0, 
> tmpl=0x7fdbf0, modifiers=0x7fdb38, count=1)
>   at ../src/gallium/drivers/freedreno/freedreno_resource.c:838
>   838   struct fd_screen *screen = fd_screen(pscreen);
>   1: *tmpl = {reference = {count = 0}, width0 = 800, height0 = 600, depth0 = 
> 1, array_size = 1, format = PIPE_FORMAT_B8G8R8A8_UNORM,
> target = PIPE_TEXTURE_2D, last_level = 0, nr_samples = 0, 
> nr_storage_samples = 0, usage = 0, bind = 1572874, flags = 0, next = 0x0,
> screen = 0x0}
>   (gdb) bt
>   #0  fd_resource_create_with_modifiers (pscreen=0x574ae0, tmpl=0x7fdbf0, 
> modifiers=0x7fdb38, count=1) at 
> ../src/gallium/drivers/freedreno/freedreno_resource.c:838
>   #1  0x007fbde0 in fd_resource_create (pscreen=0x574ae0, 
> tmpl=0x7fdbf0) at 
> ../src/gallium/drivers/freedreno/freedreno_resource.c:956
>   #2  0x007fbe54e2a4 in u_transfer_helper_resource_create 
> (pscreen=0x574ae0, templ=0x7fdbf0) at 
> ../src/gallium/auxiliary/util/u_transfer_helper.c:126
>   #3  0x007fbdcc8148 in dri2_create_image_common (_screen=0x570530, 
> width=800, height=600, format=4099, use=19, modifiers=0x0, count=0, 
> loaderPrivate=0x6c4160) at ../src/gallium/state_trackers/dri/dri2.c:1039
>   #4  0x007fbdcc8214 in dri2_create_image (_screen=0x570530, width=800, 
> height=600, format=4099, use=19, loaderPrivate=0x6c4160) at 
> ../src/gallium/state_trackers/dri/dri2.c:1061
>   #5  0x007fbec89a30 in dri3_alloc_render_buffer (draw=0x531418, 
> format=4099, width=800, height=600, depth=24) at 
> ../src/loader/loader_dri3_helper.c:1341
>   #6  0x007fbec8aab4 in dri3_get_buffer (driDrawable=0x5387b0, 
> format=4099, buffer_type=loader_dri3_buffer_back, draw=0x531418) at 
> ../src/loader/loader_dri3_helper.c:1822
>   #7  0x007fbec8b10c in loader_dri3_get_buffers (driDrawable=0x5387b0, 
> format=4099, stamp=0x64d480, loaderPrivate=0x531418, buffer_mask=1, 
> buffers=0x7fdf20) at ../src/loader/loader_dri3_helper.c:2021
>   #8  0x007fbdcc68c4 in dri_image_drawable_get_buffers 
> (drawable=0x64d480, images=0x7fdf20, statts=0x65ee90, statts_count=2) at 
> ../src/gallium/state_trackers/dri/dri2.c:339
>   #9  0x007fbdcc6c44 in dri2_allocate_textures (ctx=0x5a7540, 
> drawable=0x64d480, statts=0x65ee90, statts_count=2) at 
> ../src/gallium/state_trackers/dri/dri2.c:466
>   #10 0x007fbdccb580 in dri_st_framebuffer_validate (stctx=0x535cf0, 
> stfbi=0x64d480, statts=0x65ee90, count=2, out=0x7fe0c8) at 
> ../src/gallium/state_trackers/dri/dri_drawable.c:85
>   #11 0x007fbe048c84 in st_framebuffer_validate (stfb=0x65e9c0, 
> st=0x535cf0) at ../src/mesa/state_tracker/st_manager.c:222
>   #12 0x007fbe04a884 in st_api_make_current (stapi=0x7fbe8d90d8 
> , stctxi=0x535cf0, stdrawi=0x64d480, streadi=0x64d480) at 
> ../src/mesa/state_tracker/st_manager.c:1074
>   #13 0x007fbdccaf44 in dri_make_current (cPriv=0x67bdc0, 
> driDrawPriv=0x5387b0, driReadPriv=0x5387b0) at 
> ../src/gallium/state_trackers/dri/dri_context.c:301
>   #14 0x007fbdcc2910 in driBindContext (pcp=0x67bdc0, pdp=0x5387b0, 
> prp=0x5387b0) at ../src/mesa/drivers/dri/common/dri_util.c:579
>   #15 0x007fbec6b7e0 in dri3_bind_context (context=0x51ccd0, 
> old=0x7fbecd0798 , draw=2097154, read=2097154) at 
> ../src/glx/dri3_glx.c:210
>   #16 0x007fbec4b010 in MakeContextCurrent (dpy=0x503d00, draw=2097154, 
> read=2097154, gc_user=0x51ccd0) at ../src/glx/glxcurrent.c:220
>   #17 0x007fbec4b184 in glXMakeCurrent (dpy=0x503d00, draw=2097154, 
> gc=0x51ccd0) at ../src/glx/glxcurrent.c:267
>   #18 0x007fbee8deac in ?? () from /lib64/libGLX.so.0
>   #19 0x007fbee8f7d4 in ?? () from /lib64/libGLX.so.0
>   #20 0x0040b330 in GLStateGLX::valid() ()
>   #21 0x00409a28 in CanvasGeneric::do_make_current() ()
>   #22 0x0040a4f0 in CanvasGeneric::reset() ()
>   #23 0x00406714 in main ()
>   (gdb)
>
> In dri3_alloc_render_buffer() the request gets turned into
> createImageWithModifiers() but in dri2_create_image_common() it gets
> turned back into pscreen->create_resource() (ie. without modifiers) so
> 

Re: [Mesa-dev] [PATCH] st/dri: fix dri2_format_table for argb1555 and rgb565

[Kristian Høgsberg]

Reviewed-by: Kristian H. Kristensen 

On Fri, Jan 11, 2019 at 3:19 PM Marek Olšák  wrote:
>
> From: Marek Olšák 
>
> The bug caused that rgb565 framebuffers used argb1555.
>
> Fixes: 433ca3127a3b94bfe9a513e7c7ce594e09e1359f
> ---
>  src/gallium/state_trackers/dri/dri2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index 6fc07e42f74..ebbbabb6492 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -85,21 +85,21 @@ static const struct dri2_format_mapping 
> dri2_format_table[] = {
>{ __DRI_IMAGE_FOURCC_ARGB,  __DRI_IMAGE_FORMAT_ARGB,
>  __DRI_IMAGE_COMPONENTS_RGBA,  PIPE_FORMAT_BGRA_UNORM },
>{ __DRI_IMAGE_FOURCC_ABGR,  __DRI_IMAGE_FORMAT_ABGR,
>  __DRI_IMAGE_COMPONENTS_RGBA,  PIPE_FORMAT_RGBA_UNORM },
>{ __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_FORMAT_SARGB8,
>  __DRI_IMAGE_COMPONENTS_RGBA,  PIPE_FORMAT_BGRA_SRGB },
>{ __DRI_IMAGE_FOURCC_XRGB,  __DRI_IMAGE_FORMAT_XRGB,
>  __DRI_IMAGE_COMPONENTS_RGB,   PIPE_FORMAT_BGRX_UNORM },
>{ __DRI_IMAGE_FOURCC_XBGR,  __DRI_IMAGE_FORMAT_XBGR,
>  __DRI_IMAGE_COMPONENTS_RGB,   PIPE_FORMAT_RGBX_UNORM },
> -  { __DRI_IMAGE_FOURCC_ARGB1555,  __DRI_IMAGE_FORMAT_RGB565,
> +  { __DRI_IMAGE_FOURCC_ARGB1555,  __DRI_IMAGE_FORMAT_ARGB1555,
>  __DRI_IMAGE_COMPONENTS_RGBA,  PIPE_FORMAT_B5G5R5A1_UNORM },
>{ __DRI_IMAGE_FOURCC_RGB565,__DRI_IMAGE_FORMAT_RGB565,
>  __DRI_IMAGE_COMPONENTS_RGB,   PIPE_FORMAT_B5G6R5_UNORM },
>{ __DRI_IMAGE_FOURCC_R8,__DRI_IMAGE_FORMAT_R8,
>  __DRI_IMAGE_COMPONENTS_R, PIPE_FORMAT_R8_UNORM },
>{ __DRI_IMAGE_FOURCC_R16,   __DRI_IMAGE_FORMAT_R16,
>  __DRI_IMAGE_COMPONENTS_R, PIPE_FORMAT_R16_UNORM },
>{ __DRI_IMAGE_FOURCC_GR88,  __DRI_IMAGE_FORMAT_GR88,
>  __DRI_IMAGE_COMPONENTS_RG,PIPE_FORMAT_RG88_UNORM },
>{ __DRI_IMAGE_FOURCC_GR1616,__DRI_IMAGE_FORMAT_GR88,
> --
> 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] autotools: Deprecate the use of autotools

[Kristian Høgsberg]

On Fri, Jan 11, 2019 at 2:28 PM Ilia Mirkin  wrote:
>
> On Fri, Jan 11, 2019 at 5:12 PM Matt Turner  wrote:
> >
> > From: Gert Wollny 
> >
> > Since Meson will eventually be the only build system deprecate autotools
> > now. It can still be used by invoking configure with the flag
> >   --enable-autotools
> >
> > NAKed-by: Ilia Mirkin 
>
> [nouveau]
>
> > Acked-by: Eric Engestrom 
> > Acked-by: Kenneth Graunke 
> > Acked-by: Lionel Landwerlin 
> > Acked-by: Jason Ekstrand 
> > Reviewed-by: Matt Turner 
>
> [intel]
>
> > Acked-by: Rob Clark 
>
> [freedreno]
>
> > Acked-by: Marek Olšák 
>
> [radeon]
>
> > Reviewed-by: Christian Gmeiner 
>
> [etnaviv]
>
> > Reviewed-by: Eric Anholt 
>
> [vc4]
>
> > Signed-off-by: Gert Wollny 
>
> [sorry Gert, not sure how to classify you]
>
> I think the vmware team (which largely maintains llvmpipe and svga) is
> probably worth hearing from -- I believe they've largely stayed out of
> it. But an ack/nack would be good. Also virgl isn't represented, I
> believe. Probably not *required* to hear from these, but perhaps worth
> a poke?

If we want to round up Ack/Nacks from distros, I can lead with an

Acked-by: Kristian H. Kristensen 

on behalf of chromeos.

> > ---
> > I think there's support for overriding the sole objection to this patch.
> >
> > To confirm:
> >
> > (1) The plan is to remove Autotools, perhaps after the 19.0 release
> >
> > (2) This patch's purpose is to ensure that everyone knows that
> > Autotools will be going away (think: people who build Mesa as
> > part of an automated process and wouldn't notice a deprecation
> > warning unless it requires some action from them)
>
> If it's being removed _after_ the 19.0 release, does it make sense to
> have a patch like this _in_ the 19.0 release? (Perhaps the answer is
> `yes', but I'd still like to ask the question.)
>
> >
> > (3) We expect all reasonable concerns about Meson to be resolved
> > before Autotools is removed (e.g., reconfiguration problems,
> > retrieving configuration command line, configuration status
> > output, etc.)
> >
> >  configure.ac | 13 +
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/configure.ac b/configure.ac
> > index e4d20054d5f..c7473d77eff 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -52,6 +52,19 @@ mingw*)
> >  ;;
> >  esac
> >
> > +AC_ARG_ENABLE(autotools,
> > +   [AS_HELP_STRING([--enable-autotools],
> > +   [Enable the use of this autotools based build 
> > configuration])],
> > +   [enable_autotools=$enableval], [enable_autotools=no])
> > +
> > +if test "x$enable_autotools" != "xyes" ; then
> > +AC_MSG_ERROR([the autotools build system has been deprecated in favour 
> > of
> > +meson and will be removed eventually. For instructions on how to use 
> > meson
> > +see https://www.mesa3d.org/meson.html.
> > +If you still want to use the autotools build, then add 
> > --enable-autotools
> > +to the configure command line.])
> > +fi
> > +
> >  # Support silent build rules, requires at least automake-1.11. Disable
> >  # by either passing --disable-silent-rules to configure or passing V=1
> >  # to make
> > --
> > 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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] freedreno/drm: sync uapi again

[Kristian Høgsberg]

Reviewed-by: Kristian H. Kristensen 

On Mon, Jan 7, 2019 at 4:27 PM Chia-I Wu  wrote:
>
> "pad" was missing in Mesa's msm_drm.h.  sizeof(drm_msm_gem_info)
> remains the same, but now the compiler initializes the field to
> zero.
>
> Buffer allocation results in EINVAL without this for me.
>
> Cc: Rob Clark 
> Cc: Kristian Høgsberg 
> Signed-off-by: Chia-I Wu 
> ---
>  src/freedreno/drm/msm_drm.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/freedreno/drm/msm_drm.h b/src/freedreno/drm/msm_drm.h
> index 09f16fd7be..91a16b333c 100644
> --- a/src/freedreno/drm/msm_drm.h
> +++ b/src/freedreno/drm/msm_drm.h
> @@ -122,6 +122,7 @@ struct drm_msm_gem_info {
> __u32 info;   /* in - one of MSM_INFO_* */
> __u64 value;  /* in or out */
> __u32 len;/* in or out */
> +   __u32 pad;
>  };
>
>  #define MSM_PREP_READ0x01
> --
> 2.20.1.97.g81188d93c3-goog
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel/compiler: move nir_lower_bool_to_int32 before nir_lower_locals_to_regs

[Kristian Høgsberg]

This regresses at least
dEQP-GLES3.functional.shaders.functions.control_flow.return_in_loop_vertex
on freedreno:

Test case 
'dEQP-GLES3.functional.shaders.functions.control_flow.return_in_loop_vertex'..
deqp-gles3: ../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c:49:
lower_alu_instr: Assertion `alu->dest.dest.is_ssa' failed.

Program received signal SIGABRT, Aborted.
__libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
47  ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file
or directory.
(gdb) bt
#0  __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
#1  0xf7cee18e in __libc_signal_restore_set (set=0xfffee2dc) at
../sysdeps/unix/sysv/linux/nptl-signals.h:80
#2  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xf7ceef12 in __GI_abort () at abort.c:79
#4  0xf7ce8e84 in __assert_fail_base (fmt=0xf7da3fdc "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x
, file=0xf7ae6d48
"../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c",
file@entry=0xf7c5d010 "", line=49, line@entry=4158390024,
function=function@entry=0xf7b6be60 <__PRETTY_FUNCTION__.24316>
"lower_alu_instr") at assert.c:92
#5  0xf7ce8f22 in __GI___assert_fail (assertion=0x , file=0xf7c5d010 "",
line=4158390024, line@entry=49, function=0xf7b6be60
<__PRETTY_FUNCTION__.24316> "lower_alu_instr") at assert.c:101
#6  0xf78f08ca in lower_alu_instr (alu=0xf7dbff08 ) at
../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c:49
#7  nir_lower_bool_to_int32_impl (impl=0xf8e378) at
../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c:114
#8  nir_lower_bool_to_int32 (shader=) at
../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c:157
#9  0xf7a97584 in ir3_context_init (compiler=0xbe31c0,
so=so@entry=0xf97378) at
../../../mesa/src/freedreno/ir3/ir3_context.c:80
#10 0xf7a95f58 in ir3_compile_shader_nir (compiler=,
so=so@entry=0xf97378) at
../../../mesa/src/freedreno/ir3/ir3_compiler_nir.c:2994
#11 0xf7aa1adc in create_variant (shader=shader@entry=0xf9fe60,
key=key@entry=0xfffee764, binning_pass=binning_pass@entry=true) at
../../../mesa/src/freedreno/ir3/ir3_shader.c:182
#12 0xf7aa1d9c in ir3_shader_get_variant (shader=0xf9fe60,
key=key@entry=0xfffee764, binning_pass=,
created=0xfffee743, created@entry=0xfffee723) at
../../../mesa/src/freedreno/ir3/ir3_shader.c:233
#13 0xf7a88068 in ir3_shader_variant (shader=, key=...,
binning_pass=binning_pass@entry=true, debug=debug@entry=0xc9a794) at
../../../../../mesa/src/gallium/drivers/freedreno/ir3/ir3_gallium.c:86
#14 0xf7a87a74 in ir3_cache_lookup (cache=0xc89520,
key=key@entry=0xfffee844, debug=debug@entry=0xc9a794) at
../../../../../mesa/src/gallium/drivers/freedreno/ir3/ir3_cache.c:96
#15 0xf7a7ad6e in fd6_emit_get_prog (emit=0xfffee838) at
../../../../../mesa/src/gallium/drivers/freedreno/a6xx/fd6_emit.h:103
#16 fd6_draw_vbo (ctx=0xc95ca0, info=0xfffeea70, index_offset=80) at
../../../../../mesa/src/gallium/drivers/freedreno/a6xx/fd6_draw.c:186
#17 0xf7a4551a in fd_draw_vbo (pctx=, info=0xfffeea70)
at ../../../../../mesa/src/gallium/drivers/freedreno/freedreno_draw.c:291
#18 0xf79f8802 in u_vbuf_draw_vbo (mgr=,
info=) at
../../../../mesa/src/gallium/auxiliary/util/u_vbuf.c:1449
#19 0xf77d2f42 in st_draw_vbo (ctx=, prims=0xfffeed54,
nr_prims=, ib=0xfffeed44, index_bounds_valid=0 '\000',
min_index=0, max_index=3, tfb_vertcount=0x0, stream=0, indirect=0x0)
at ../../../mesa/src/mesa/state_tracker/st_draw.c:268
#20 0xf766b338 in _mesa_validated_drawrangeelements (ctx=0xca3e00,
mode=mode@entry=4, index_bounds_valid=,
start=, end=end@entry=4294967295, count=count@entry=6,
type=type@entry=5123, indices=indices@entry=0xac3d60, basevertex=0,
numInstances=numInstances@entry=1, baseInstance=0) at
../../../mesa/src/mesa/main/draw.c:849
#21 0xf766c36a in _mesa_validated_drawrangeelements (baseInstance=0,
numInstances=1, basevertex=0, indices=0xac3d60, type=5123, count=6,
end=4294967295, start=0, index_bounds_valid=0 '\000', mode=4,
ctx=) at ../../../mesa/src/mesa/main/draw.c:768
#22 _mesa_DrawElements (mode=4, count=6, type=5123, indices=0xac3d60)
at ../../../mesa/src/mesa/main/draw.c:1003
#23 0x008f4e94 in _start ()

Kristian

On Wed, Dec 19, 2018 at 12:16 AM Iago Toral Quiroga  wrote:
>
> The former expects to see SSA-only things, but the latter injects registers.
>
> The assertions in the lowering where not seeing this because they asserted
> on the bit_size values only, not on the is_ssa field, so add that assertion
> too.
>
> Fixes: 11dc1307794e "nir: Add a bool to int32 lowering pass"
> CC: mesa-sta...@lists.freedesktop.org
> ---
>  src/compiler/nir/nir_lower_bool_to_int32.c | 2 ++
>  src/intel/compiler/brw_nir.c   | 4 ++--
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/nir/nir_lower_bool_to_int32.c 
> b/src/compiler/nir/nir_lower_bool_to_int32.c
> index 064b27b9025..fdd2f55175d 100644
> --- 

Re: [Mesa-dev] [PATCH] genxml: Consistently use a numeric "MOCS" field

[Kristian Høgsberg]

Reviewed-by: Kristian H. Kristensen 

On Tue, Dec 11, 2018 at 9:25 PM Jordan Justen  wrote:
>
> Reviewed-by: Jordan Justen 
>
> On 2018-12-11 20:23:06, Kenneth Graunke wrote:
> > When we first started using genxml, we decided to represent MOCS as an
> > actual structure, and pack values.  However, in many places, it was more
> > convenient to use a numeric value rather than treating it as a struct,
> > so we added secondary setters in a bunch of places as well.
> >
> > We were not entirely consistent, either.  Some places only had one.
> > Gen6 had both kinds of setters for STATE_BASE_ADDRESS, but newer gens
> > only had the struct-based setters.  The names were sometimes "Constant
> > Buffer Object Control State" instead of "Memory", making it harder to
> > find.  Many had prefixes like "Vertex Buffer MOCS"...in a vertex buffer
> > packet...which is a bit redundant.
> >
> > On modern hardware, MOCS is simply an index into a table, but we were
> > still carrying around the structure with an "Index to MOCS Table" field,
> > in addition to the direct numeric setters.  This is clunky - we really
> > just want a number on new hardware.
> >
> > This patch eliminates the struct-based setters, and makes the numeric
> > setters be consistently called "MOCS".  We leave the struct definition
> > around on Gen7-8 for reference purposes, but it is unused.
> > ---
> >  src/intel/blorp/blorp_genX_exec.h |  2 +-
> >  src/intel/genxml/gen10.xml| 53 +
> >  src/intel/genxml/gen11.xml| 53 +
> >  src/intel/genxml/gen6.xml | 28 ++-
> >  src/intel/genxml/gen7.xml | 35 -
> >  src/intel/genxml/gen75.xml| 38 --
> >  src/intel/genxml/gen8.xml | 47 +---
> >  src/intel/genxml/gen9.xml | 50 +---
> >  src/intel/isl/isl_emit_depth_stencil.c|  6 +-
> >  src/intel/vulkan/anv_private.h| 76 ---
> >  src/intel/vulkan/gen7_cmd_buffer.c|  2 +-
> >  src/intel/vulkan/gen8_cmd_buffer.c|  2 +-
> >  src/intel/vulkan/genX_cmd_buffer.c| 19 +++--
> >  src/intel/vulkan/genX_gpu_memcpy.c|  4 +-
> >  src/intel/vulkan/genX_state.c |  6 +-
> >  src/mesa/drivers/dri/i965/genX_state_upload.c | 14 ++--
> >  16 files changed, 177 insertions(+), 258 deletions(-)
> >
> > diff --git a/src/intel/blorp/blorp_genX_exec.h 
> > b/src/intel/blorp/blorp_genX_exec.h
> > index 065980616ec..42494ffbc86 100644
> > --- a/src/intel/blorp/blorp_genX_exec.h
> > +++ b/src/intel/blorp/blorp_genX_exec.h
> > @@ -311,7 +311,7 @@ blorp_fill_vertex_buffer_state(struct blorp_batch 
> > *batch,
> > vb[idx].BufferPitch = stride;
> >
> >  #if GEN_GEN >= 6
> > -   vb[idx].VertexBufferMOCS = addr.mocs;
> > +   vb[idx].MOCS = addr.mocs;
> >  #endif
> >
> >  #if GEN_GEN >= 7
> > diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml
> > index 2d3bc39b1b9..21cd8a17d91 100644
> > --- a/src/intel/genxml/gen10.xml
> > +++ b/src/intel/genxml/gen10.xml
> > @@ -219,14 +219,9 @@
> >   > type="uint"/>
> >
> >
> > -  
> > -
> > -  
> > -
> >
> >  
> > - > type="MEMORY_OBJECT_CONTROL_STATE"/>
> > -
> > +
> >  
> >  
> >  
> > @@ -495,7 +490,6 @@
> >   > type="bool"/>
> >   > type="bool"/>
> >   > type="bool"/>
> > - > type="MEMORY_OBJECT_CONTROL_STATE"/>
> >  
> >  
> >  
> > @@ -993,7 +987,7 @@
> >  
> >   > type="address"/>
> >   > type="uint"/>
> > - > type="MEMORY_OBJECT_CONTROL_STATE"/>
> > +
> >   > type="uint">
> >
> >  
> > @@ -1085,7 +1079,7 @@
> >   > default="3"/>
> >   > default="0"/>
> >   > default="26"/>
> > - > type="MEMORY_OBJECT_CONTROL_STATE"/>
> > +
> >  
> >   > type="3DSTATE_CONSTANT_BODY"/>
> >
> > @@ -1095,7 +1089,7 @@
> >   > default="3"/>
> >   > default="0"/>
> >   > default="22"/>
> > - > type="MEMORY_OBJECT_CONTROL_STATE"/>
> > +
> >  
> >   > type="3DSTATE_CONSTANT_BODY"/>
> >
> > @@ -1105,7 +1099,7 @@
> >   > default="3"/>
> >   > default="0"/>
> >   > default="25"/>
> > - > type="MEMORY_OBJECT_CONTROL_STATE"/>
> > +
> >  
> >   > type="3DSTATE_CONSTANT_BODY"/>
> >
> > @@ -1116,7 +1110,7 @@
> >   > default="0"/>
> >   > default="23"/>
> >   > type="uint"/>
> > - > type="MEMORY_OBJECT_CONTROL_STATE"/>
> > +
> >  
> >   > type="3DSTATE_CONSTANT_BODY"/>
> >
> > @@ -1126,7 +1120,7 @@
> >   > default="3"/>
> >   > default="0"/>
> >   > default="21"/>
> > - > type="MEMORY_OBJECT_CONTROL_STATE"/>
> > +
> >  
> >   > type="3DSTATE_CONSTANT_BODY"/>
> >
> > @@ -1157,8 +1151,7 @@
> >  
> >  
> >  
> > - > type="MEMORY_OBJECT_CONTROL_STATE"/>
> > -
> > +
> >  
> >   

Re: [Mesa-dev] [PATCH] glapi: Fix DispatchSanity_test

[Kristian Høgsberg]

On Tue, Dec 11, 2018 at 3:33 AM Emil Velikov  wrote:
>
> On Mon, 10 Dec 2018 at 18:56, Kristian Høgsberg  wrote:
> >
> > On Mon, Dec 10, 2018 at 7:38 AM Emil Velikov  
> > wrote:
> > >
> > > On Fri, 7 Dec 2018 at 23:48, Kristian H. Kristensen  
> > > wrote:
> > > >
> > > > ---
> > > >  src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml | 2 +-
> > > >  src/mapi/glapi/gen/es_EXT.xml | 2 ++
> > > >  src/mapi/glapi/gen/gl_API.xml | 2 --
> > > >  src/mesa/main/tests/dispatch_sanity.cpp   | 3 +++
> > > >  4 files changed, 6 insertions(+), 3 deletions(-)
> > > >
> > > There's a bit more to it. I'm testing something up and will send a
> > > patch shortly.
> >
> > You could also just review this patch and tell me what's missing.
> > Either way, we need to fix the test suite, so let's close this soon.
> > I'll commit this end of today if I don't hear from you.
> >
> As you can see in v2 - tracking down exactly what works and is
> reasonable took quite a bit.
> Fwiw I've kept you as the patch author, although I feel that's not
> your main concern.

No, I'm not to worried about that, I just don't feel good about the
"let me rewrite your patch for you" style of review. But I appreciate
your help in this case, thanks.

Kristian

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

Re: [Mesa-dev] [PATCH v2] glapi: fixup EXT_multisampled_render_to_texture dispatch

[Kristian Høgsberg]

On Mon, Dec 10, 2018 at 2:12 PM Ian Romanick  wrote:
>
> Reviewed-by: Ian Romanick 

Thanks Ian. I went ahead and pushed this to appease the CI bots.

Kristian

> On 12/10/18 10:14 AM, Emil Velikov wrote:
> > From: "Kristian H. Kristensen" 
> >
> > There's a few missing and convoluted bits:
> >
> >  - FramebufferTexture2DMultisampleEXT
> > Missing sanity check, should be desktop="false"
> >
> >  - RenderbufferStorageMultisampleEXT
> > Missing sanity check, is aliased to RenderbufferStorageMultisample.
> > Thus it's set only when desktop GL or GLES2 v3.0+, while the extension
> > is GLES2 2.0+.
> >
> > If we flip the aliasing we'll break indirect GLX, so loosen the version
> > to 2.0. Not perfect, yet this is the most sane thing I could think of.
> >
> > v2: [Emil] Fixup RenderbufferStorageMultisampleEXT, commmit message
> >
> > Cc: Kristian H. Kristensen 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108974
> > Fixes: 1b331ae505e ("mesa: Add core support for 
> > EXT_multisampled_render_to_texture{,2}")
> > Reviewed-by: Emil Velikov 
> > Signed-off-by: Emil Velikov 
> > ---
> >  src/mapi/glapi/gen/ARB_framebuffer_object.xml  | 10 +-
> >  .../glapi/gen/EXT_multisampled_render_to_texture.xml   |  2 +-
> >  src/mapi/glapi/gen/es_EXT.xml  |  2 ++
> >  src/mapi/glapi/gen/gl_API.xml  |  2 --
> >  src/mesa/main/tests/dispatch_sanity.cpp|  6 +-
> >  5 files changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/mapi/glapi/gen/ARB_framebuffer_object.xml 
> > b/src/mapi/glapi/gen/ARB_framebuffer_object.xml
> > index bd0793c8ece..295175c8816 100644
> > --- a/src/mapi/glapi/gen/ARB_framebuffer_object.xml
> > +++ b/src/mapi/glapi/gen/ARB_framebuffer_object.xml
> > @@ -172,7 +172,15 @@
> >   
> >  
> >
> > -
> > +
> > +
> >  
> >  
> >  
> > diff --git a/src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml 
> > b/src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml
> > index 555b008bd33..d76ecd47d0e 100644
> > --- a/src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml
> > +++ b/src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml
> > @@ -20,7 +20,7 @@
> >  
> >  -->
> >
> > -
> > + > desktop="false">
> >  
> >  
> >  
> > diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
> > index bbc4a1a1118..917fed62f98 100644
> > --- a/src/mapi/glapi/gen/es_EXT.xml
> > +++ b/src/mapi/glapi/gen/es_EXT.xml
> > @@ -810,6 +810,8 @@
> >  
> >  
> >
> > + > xmlns:xi="http://www.w3.org/2001/XInclude"/>
> > +
> >  
> >  
> >  
> > diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> > index f1def8090de..f4d0808f13b 100644
> > --- a/src/mapi/glapi/gen/gl_API.xml
> > +++ b/src/mapi/glapi/gen/gl_API.xml
> > @@ -8175,8 +8175,6 @@
> >
> >   > xmlns:xi="http://www.w3.org/2001/XInclude"/>
> >
> > - > xmlns:xi="http://www.w3.org/2001/XInclude"/>
> > -
> >   > xmlns:xi="http://www.w3.org/2001/XInclude"/>
> >
> >  
> > diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
> > b/src/mesa/main/tests/dispatch_sanity.cpp
> > index fb2acfbdeea..307639a4a4e 100644
> > --- a/src/mesa/main/tests/dispatch_sanity.cpp
> > +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> > @@ -2236,6 +2236,10 @@ const struct function gles2_functions_possible[] = {
> > /* GL_NV_conservative_raster_pre_snap_triangles */
> > { "glConservativeRasterParameteriNV", 20, -1 },
> >
> > +   /* GL_EXT_multisampled_render_to_texture */
> > +   { "glRenderbufferStorageMultisampleEXT", 20, -1 },
> > +   { "glFramebufferTexture2DMultisampleEXT", 20, -1 },
> > +
> > { NULL, 0, -1 }
> >  };
> >
> > @@ -2330,7 +2334,7 @@ const struct function gles3_functions_possible[] = {
> > // glProgramParameteri aliases glProgramParameteriEXT in GLES 2
> > // We check for the aliased -NV version in GLES 2
> > // { "glReadBuffer", 30, -1 },
> > -   { "glRenderbufferStorageMultisample", 30, -1 },
> > +   // glRenderbufferStorageMultisample aliases 
> > glRenderbufferStorageMultisampleEXT in GLES 2
> > { "glResumeTransformFeedback", 30, -1 },
> > { "glSamplerParameterf", 30, -1 },
> > { "glSamplerParameterfv", 30, -1 },
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] glapi: fixup EXT_multisampled_render_to_texture dispatch

[Kristian Høgsberg]

On Mon, Dec 10, 2018 at 10:17 AM Emil Velikov  wrote:
>
> From: "Kristian H. Kristensen" 
>
> There's a few missing and convoluted bits:
>
>  - FramebufferTexture2DMultisampleEXT
> Missing sanity check, should be desktop="false"
>
>  - RenderbufferStorageMultisampleEXT
> Missing sanity check, is aliased to RenderbufferStorageMultisample.
> Thus it's set only when desktop GL or GLES2 v3.0+, while the extension
> is GLES2 2.0+.
>
> If we flip the aliasing we'll break indirect GLX, so loosen the version
> to 2.0. Not perfect, yet this is the most sane thing I could think of.
>
> v2: [Emil] Fixup RenderbufferStorageMultisampleEXT, commmit message

Ok, that looks good, thanks Emil.

>
> Cc: Kristian H. Kristensen 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108974
> Fixes: 1b331ae505e ("mesa: Add core support for 
> EXT_multisampled_render_to_texture{,2}")
> Reviewed-by: Emil Velikov 
> Signed-off-by: Emil Velikov 
> ---
>  src/mapi/glapi/gen/ARB_framebuffer_object.xml  | 10 +-
>  .../glapi/gen/EXT_multisampled_render_to_texture.xml   |  2 +-
>  src/mapi/glapi/gen/es_EXT.xml  |  2 ++
>  src/mapi/glapi/gen/gl_API.xml  |  2 --
>  src/mesa/main/tests/dispatch_sanity.cpp|  6 +-
>  5 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/src/mapi/glapi/gen/ARB_framebuffer_object.xml 
> b/src/mapi/glapi/gen/ARB_framebuffer_object.xml
> index bd0793c8ece..295175c8816 100644
> --- a/src/mapi/glapi/gen/ARB_framebuffer_object.xml
> +++ b/src/mapi/glapi/gen/ARB_framebuffer_object.xml
> @@ -172,7 +172,15 @@
> 
>  
>
> -
> +
> +
>  
>  
>  
> diff --git a/src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml 
> b/src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml
> index 555b008bd33..d76ecd47d0e 100644
> --- a/src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml
> +++ b/src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml
> @@ -20,7 +20,7 @@
>  
>  -->
>
> -
> + desktop="false">
>  
>  
>  
> diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
> index bbc4a1a1118..917fed62f98 100644
> --- a/src/mapi/glapi/gen/es_EXT.xml
> +++ b/src/mapi/glapi/gen/es_EXT.xml
> @@ -810,6 +810,8 @@
>  
>  
>
> + xmlns:xi="http://www.w3.org/2001/XInclude"/>
> +
>  
>  
>  
> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> index f1def8090de..f4d0808f13b 100644
> --- a/src/mapi/glapi/gen/gl_API.xml
> +++ b/src/mapi/glapi/gen/gl_API.xml
> @@ -8175,8 +8175,6 @@
>
>   xmlns:xi="http://www.w3.org/2001/XInclude"/>
>
> - xmlns:xi="http://www.w3.org/2001/XInclude"/>
> -
>   xmlns:xi="http://www.w3.org/2001/XInclude"/>
>
>  
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index fb2acfbdeea..307639a4a4e 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -2236,6 +2236,10 @@ const struct function gles2_functions_possible[] = {
> /* GL_NV_conservative_raster_pre_snap_triangles */
> { "glConservativeRasterParameteriNV", 20, -1 },
>
> +   /* GL_EXT_multisampled_render_to_texture */
> +   { "glRenderbufferStorageMultisampleEXT", 20, -1 },
> +   { "glFramebufferTexture2DMultisampleEXT", 20, -1 },
> +
> { NULL, 0, -1 }
>  };
>
> @@ -2330,7 +2334,7 @@ const struct function gles3_functions_possible[] = {
> // glProgramParameteri aliases glProgramParameteriEXT in GLES 2
> // We check for the aliased -NV version in GLES 2
> // { "glReadBuffer", 30, -1 },
> -   { "glRenderbufferStorageMultisample", 30, -1 },
> +   // glRenderbufferStorageMultisample aliases 
> glRenderbufferStorageMultisampleEXT in GLES 2
> { "glResumeTransformFeedback", 30, -1 },
> { "glSamplerParameterf", 30, -1 },
> { "glSamplerParameterfv", 30, -1 },
> --
> 2.19.2
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glapi: Fix DispatchSanity_test

[Kristian Høgsberg]

On Mon, Dec 10, 2018 at 7:38 AM Emil Velikov  wrote:
>
> On Fri, 7 Dec 2018 at 23:48, Kristian H. Kristensen  
> wrote:
> >
> > ---
> >  src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml | 2 +-
> >  src/mapi/glapi/gen/es_EXT.xml | 2 ++
> >  src/mapi/glapi/gen/gl_API.xml | 2 --
> >  src/mesa/main/tests/dispatch_sanity.cpp   | 3 +++
> >  4 files changed, 6 insertions(+), 3 deletions(-)
> >
> There's a bit more to it. I'm testing something up and will send a
> patch shortly.

You could also just review this patch and tell me what's missing.
Either way, we need to fix the test suite, so let's close this soon.
I'll commit this end of today if I don't hear from you.

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

Re: [Mesa-dev] Mesa (master): mesa: Add core support for EXT_multisampled_render_to_texture{, 2}

[Kristian Høgsberg]

On Fri, Dec 7, 2018 at 1:49 AM Michel Dänzer  wrote:
>
> On 2018-12-07 2:02 a.m., GitLab Mirror wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 1b331ae505e63033634d9f5267ca1949336f75d8
> > URL:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=1b331ae505e63033634d9f5267ca1949336f75d8
> >
> > Author: Kristian H. Kristensen 
> > Date:   Mon Nov  5 21:19:21 2018 -0800
> >
> > mesa: Add core support for EXT_multisampled_render_to_texture{,2}
> >
> > This also turns on EXT_multisampled_render_to_texture which is a
> > subset of EXT_multisampled_render_to_texture2, allowing only
> > COLOR_ATTACHMENT0.
> >
> > Reviewed-by: Eric Anholt 
> > Signed-off-by: Kristian H. Kristensen 
>
> This broke tests, both with meson and autotools.

Apologies all around, thanks Samuel for fixing.

Kristian

>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> 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] Lets talk about autotools

[Kristian Høgsberg]

On Mon, Dec 3, 2018 at 10:28 AM Emil Velikov  wrote:
>
> On Mon, 3 Dec 2018 at 17:49, Dylan Baker  wrote:
> >
> > Quoting Emil Velikov (2018-12-03 07:54:38)
> > > Hi all,
> > >
> > > On Thu, 29 Nov 2018 at 17:44, Emil Velikov  
> > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I can see why people may opt to not use or maintain the autotools build.
> > > > Although I would kindly ask that we do not remove it just yet.
> > > >
> > > > In Mesa, we have different parts not used by different teams. As such
> > > > we tend to remove stuff when nobody is around to maintain it anymore.
> > > >
> > > > That said, I'm planning to continue maintaining it and would appreciate
> > > > if we keep it in-tree.
> > > >
> > > > As people may be concerned about bugreports and alike we can trivially
> > > > add a warning (as configure is invoked) to forwards any issues to my
> > > > email. Additionally (or alternatively) we can have an autotools bugzilla
> > > > category with me as the default assignee.
> > > >
> > >
> > > Seems like I failed to make things clear enough with earlier message.
> > >
> > > There is _no_ expectation for anyone to touch or even look at autotools.
> > > Hence, my suggestion to have configure.ac point people to me in case of 
> > > issues.
> > >
> > > If people have CI that uses it - feel free to drop it.
> > >
> >
> > I've tried to stay out of this discussion, because everyone knows my 
> > opinion,
> > and I feel I don't have much to add, however...
> >
> > >
> > > That said, many have asked why I'd go through the pain of maintaining it:
> > >  - Most Linux distributions have switched, but there'still a few 
> > > outstanding
> > >  - Non Linux distributions have not switched
> >
> > Haiku has at least :)
> >
> \o/
>
> > >  - The meson build is missing features, relative the autotools one
> >
> > The only feature that I know that meson does not have relative to autotools 
> > is
> > the gl mangling stuff (which is intentional, we'll add it if someone shows 
> > up
> > with a need for it). Everything else is either intentionally not implemented
> > (GLX TLS toggling for example, which meson hardcodes on for OSes that 
> > support
> > it, and off for those that don't).
> >
> On top of the TLS and symbol mangling (for which I agree) there is:
>
>  - no CrOS support
>  - static/shared mesa (or at least parts of) - Kitware guys are still using it
>  - non-static gallium targets - yes it's intentionally 'hidden' in 
> configure.ac
>  - disable direct glx - non linux people use this
>
> I understand the reluctance on the latter two, yet leaving CrOS and
> Kitware in the cold seems strange.

We're mostly ready to switch, Chad's done the work to update the
ebuilds and sdk. Don't keep autotools on account of us - excited to
see this work mature.

Kristian

>
> > >  - I've been approached by individuals, who cannot quite yet use meson
> >
> > At this point we've been very clear of our intentions to move to meson, as 
> > Matt
> > said I have worked very hard to resolve any issues developers and users 
> > have had
> > (and have spent a lot of time booting VM's and fixing meson and mesa's meson
> > build on non-linux OSes) or reported, but we can't resolve issues that 
> > aren't
> > reported. If people are having issues using meson and they're not filing a 
> > bug
> > with meson or with mesa, or mailing the list, or getting on IRC, there is
> > nothing we can do for them, and at some point they need to speak up, or 
> > accept
> > things.
> >
> As the Mesa community grows, the amount of discussions/patches we
> produce is quite intimidating.
>
> Over the years, I've been reaching out to distributions and
> maintainers, many of which doing this as a hobby, to ease their mind.
>
> Your point is valid - issues should be brought forward. Although
> without encouragement things are hard sometimes.
>
> Thanks
> -Emil
> ___
> 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 v2 2/5] gallium: Add new PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE

[Kristian Høgsberg]

On Fri, Nov 30, 2018 at 10:17 AM Marek Olšák  wrote:
>
> On Fri, Nov 30, 2018 at 1:13 PM Kristian Høgsberg  wrote:
>>
>> On Fri, Nov 16, 2018 at 7:48 PM Marek Olšák  wrote:
>> >
>> > I think the name PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE is slightly 
>> > misleading, because it doesn't imply anything about the OpenGL ES 
>> > behavior, which is that a texture is multisampled in the cache, but 
>> > single-sampled in memory. This should be mentioned somewhere.
>>
>> Not sure exactly which change you're recommending, but in retrospect,
>> I think it would be better to name the cap in term of how it changes
>> the gallium API instead of the GLES extension it enables. How about
>> PIPE_CAP_SURFACE_SAMPLE_COUNT, to indicate that it allows overriding
>> sample counts in pipe_surface?
>
>
> That's an interesting idea, but how does it convey that multisampled surfaces 
> are never multisampled in memory?

How are you going to convey all that in a cap enum name? In general,
the cap names are concise hints and not super descriptive - you have
to go read the documentation to understand the semantics.

Do you have a specific name you'd like to see or can we go with
PIPE_CAP_SURFACE_SAMPLE_COUNT?

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

Re: [Mesa-dev] [PATCH v2 2/5] gallium: Add new PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE

[Kristian Høgsberg]

On Fri, Nov 16, 2018 at 7:48 PM Marek Olšák  wrote:
>
> I think the name PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE is slightly 
> misleading, because it doesn't imply anything about the OpenGL ES behavior, 
> which is that a texture is multisampled in the cache, but single-sampled in 
> memory. This should be mentioned somewhere.

Not sure exactly which change you're recommending, but in retrospect,
I think it would be better to name the cap in term of how it changes
the gallium API instead of the GLES extension it enables. How about
PIPE_CAP_SURFACE_SAMPLE_COUNT, to indicate that it allows overriding
sample counts in pipe_surface?

>
> Marek
>
>
> On Tue, Nov 6, 2018 at 5:19 PM Kristian H. Kristensen  
> wrote:
>>
>> This new pipe cap and the new nr_samples field in pipe_surface lets a
>> state tracker bind a render target with a different sample count than
>> the resource. This allows for implementing
>> EXT_multisampled_render_to_texture and
>> EXT_multisampled_render_to_texture2.
>>
>> Signed-off-by: Kristian H. Kristensen 
>> ---
>>  src/gallium/auxiliary/util/u_framebuffer.c | 10 --
>>  src/gallium/docs/source/screen.rst |  3 +++
>>  src/gallium/include/pipe/p_defines.h   |  1 +
>>  src/gallium/include/pipe/p_state.h |  6 ++
>>  4 files changed, 18 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_framebuffer.c 
>> b/src/gallium/auxiliary/util/u_framebuffer.c
>> index 5bafddc726f..127623a7677 100644
>> --- a/src/gallium/auxiliary/util/u_framebuffer.c
>> +++ b/src/gallium/auxiliary/util/u_framebuffer.c
>> @@ -229,13 +229,19 @@ util_framebuffer_get_num_samples(const struct 
>> pipe_framebuffer_state *fb)
>> if (!(fb->nr_cbufs || fb->zsbuf))
>>return MAX2(fb->samples, 1);
>>
>> +   /**
>> +* If a driver doesn't advertise PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE,
>> +* pipe_surface::nr_samples will always be 0.
>> +*/
>> for (i = 0; i < fb->nr_cbufs; i++) {
>>if (fb->cbufs[i]) {
>> - return MAX2(1, fb->cbufs[i]->texture->nr_samples);
>> + return MAX3(1, fb->cbufs[i]->texture->nr_samples,
>> + fb->cbufs[i]->nr_samples);
>>}
>> }
>> if (fb->zsbuf) {
>> -  return MAX2(1, fb->zsbuf->texture->nr_samples);
>> +  return MAX3(1, fb->zsbuf->texture->nr_samples,
>> +  fb->zsbuf->nr_samples);
>> }
>>
>> return 1;
>> diff --git a/src/gallium/docs/source/screen.rst 
>> b/src/gallium/docs/source/screen.rst
>> index 0abd164494c..2a062a7027c 100644
>> --- a/src/gallium/docs/source/screen.rst
>> +++ b/src/gallium/docs/source/screen.rst
>> @@ -477,6 +477,9 @@ subpixel precision bias in bits during conservative 
>> rasterization.
>>0 means no limit.
>>  * ``PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET``: The maximum supported value 
>> for
>>of pipe_vertex_element::src_offset.
>> +* ``PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE``: Whether the driver
>> +  supports pipe_surface overrides of resource nr_samples. If set, will
>> +  enable EXT_multisampled_render_to_texture.
>>
>>  .. _pipe_capf:
>>
>> diff --git a/src/gallium/include/pipe/p_defines.h 
>> b/src/gallium/include/pipe/p_defines.h
>> index dacedf5b936..0ecfaf3ba5e 100644
>> --- a/src/gallium/include/pipe/p_defines.h
>> +++ b/src/gallium/include/pipe/p_defines.h
>> @@ -823,6 +823,7 @@ enum pipe_cap
>> PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS,
>> PIPE_CAP_MAX_TEXTURE_UPLOAD_MEMORY_BUDGET,
>> PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET,
>> +   PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE,
>>  };
>>
>>  /**
>> diff --git a/src/gallium/include/pipe/p_state.h 
>> b/src/gallium/include/pipe/p_state.h
>> index fd670345aad..89cffb15bd8 100644
>> --- a/src/gallium/include/pipe/p_state.h
>> +++ b/src/gallium/include/pipe/p_state.h
>> @@ -443,6 +443,12 @@ struct pipe_surface
>> uint16_t width;   /**< logical width in pixels */
>> uint16_t height;  /**< logical height in pixels */
>>
>> +   /** Number of samples for the surface.  This can be different from the
>> +* resource nr_samples when the resource is bound using
>> +* FramebufferTexture2DMultisampleEXT.
>> +*/
>> +   unsigned nr_samples:8;
>> +
>> union pipe_surface_desc u;
>>  };
>>
>> --
>> 2.19.1.930.g4563a0d9d0-goog
>>
>> ___
>> 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 v2 2/5] gallium: Add new PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE

[Kristian Høgsberg]

On Tue, Nov 6, 2018 at 6:26 PM Roland Scheidegger  wrote:
>
> Am 07.11.18 um 00:03 schrieb Kristian Høgsberg:
> > On Tue, Nov 6, 2018 at 2:44 PM Axel Davy  wrote:
> >>
> >> Hi,
> >>
> >> Is there anything to be done in the nine state trackers (or other state
> >> trackers).
> >>
> >> Nine uses create_surface. Should it expect the field to be filled
> >> properly by the driver ?
> >
> > Nothing is required from any state tracker, but if your API has an
> > extension like EXT_multisampled_render_to_texture, and the driver has
> > this new capability, you can set pipe_surface::nr_samples. The driver
> > will then render with that many samples internally and transparently
> > resolve the rendering to the (non-MSAA) resource.
> >
> >> On 06/11/2018 23:09, Kristian H. Kristensen wrote:
> >>> +   /**
> >>> +* If a driver doesn't advertise 
> >>> PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE,
> >>> +* pipe_surface::nr_samples will always be 0.
> >>> +*/
> >> The above comment should be added to the comment below.
> >>> +   /** Number of samples for the surface.  This can be different from the
> >>> +* resource nr_samples when the resource is bound using
> >>> +* FramebufferTexture2DMultisampleEXT.
> >>> +*/
> >>> +   unsigned nr_samples:8;
> >
> > Hm, I probably need to reword that a bit, since it implies the surface
> > sample count can be same as the resource, when it is only ever either
> > surface samples = 0 or surface samples > 1 with resource samples = 1.
> Wouldn't it be more logical if you rather adjust the code to match the
> comment? That is, the surface would inherit the sample count of the
> resource by default, but can be set to something different for this
> extension.

Yeah, that should work. I wanted to avoid rewriting every gallium
driver to look at surf->nr_samples instead of
surf->texture->nr_samples, but since they're the same without the new
cap, that shouldn't be necessary.

>
> > Kristian
> >
> >>> +
> >>>  union pipe_surface_desc u;
> >>>   };
> >>>
> >>
> >>
> >> Yours,
> >>
> >>
> >> Axel Davy
> >>
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Csroland%40vmware.com%7Cbd68e613af17447b3eae08d6443c12d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636771422156943417sdata=pji9JMcMB0DQyRIzske1nXJyCpneZ4RxITU9ov2A92o%3Dreserved=0
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Csroland%40vmware.com%7Cbd68e613af17447b3eae08d6443c12d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636771422156943417sdata=pji9JMcMB0DQyRIzske1nXJyCpneZ4RxITU9ov2A92o%3Dreserved=0
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 1/5] mesa: Add core support for EXT_multisampled_render_to_texture2

[Kristian Høgsberg]

On Tue, Nov 6, 2018 at 3:03 PM Ilia Mirkin  wrote:
>
> On Tue, Nov 6, 2018 at 5:18 PM Kristian H. Kristensen
>  wrote:
> >
> > This also turns on EXT_multisampled_render_to_texture which is a
> > subset of EXT_multisampled_render_to_texture2, allowing only
> > COLOR_ATTACHMENT0.
>
> You also enable the texture2 variant as well, no?

Yes, I'll update the subject.

>
> >
> > Signed-off-by: Kristian H. Kristensen 
> > ---
> >  .../EXT_multisampled_render_to_texture.xml| 34 ++
> >  src/mapi/glapi/gen/Makefile.am|  1 +
> >  src/mapi/glapi/gen/gl_API.xml |  2 +
> >  src/mapi/glapi/gen/meson.build|  1 +
> >  src/mesa/drivers/common/meta.c|  2 +-
> >  src/mesa/main/extensions_table.h  |  2 +
> >  src/mesa/main/fbobject.c  | 45 +--
> >  src/mesa/main/fbobject.h  |  8 +++-
> >  src/mesa/main/mtypes.h|  2 +
> >  9 files changed, 81 insertions(+), 16 deletions(-)
> >  create mode 100644 
> > src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml
> >
> > diff --git a/src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml 
> > b/src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml
> > new file mode 100644
> > index 000..cf44e6976f0
> > --- /dev/null
> > +++ b/src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml
> > @@ -0,0 +1,34 @@
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > + > value="0x8CAB"/>
> > + > value="0x8D56"/>
> > + > value="0x8D57"/>
> > + > value="0x8D6C"/>
>
> I don't see any logic to enable retrieving these (*_SAMPLES_EXT), so I
> think this implementation is slightly incomplete.

Will add.

> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
> > index 6e0ee1e1687..40538b0ff2e 100644
> > --- a/src/mapi/glapi/gen/Makefile.am
> > +++ b/src/mapi/glapi/gen/Makefile.am
> > @@ -200,6 +200,7 @@ API_XML = \
> > EXT_external_objects_fd.xml \
> > EXT_framebuffer_object.xml \
> > EXT_gpu_shader4.xml \
> > +   EXT_multisampled_render_to_texture.xml \
> > EXT_packed_depth_stencil.xml \
> > EXT_provoking_vertex.xml \
> > EXT_separate_shader_objects.xml \
> > diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> > index aae9a5835db..ee4d13f1f06 100644
> > --- a/src/mapi/glapi/gen/gl_API.xml
> > +++ b/src/mapi/glapi/gen/gl_API.xml
> > @@ -8166,6 +8166,8 @@
> >
> >   > xmlns:xi="http://www.w3.org/2001/XInclude"/>
> >
> > + > xmlns:xi="http://www.w3.org/2001/XInclude"/>
> > +
> >   > xmlns:xi="http://www.w3.org/2001/XInclude"/>
> >
> >  
> > diff --git a/src/mapi/glapi/gen/meson.build b/src/mapi/glapi/gen/meson.build
> > index f494e9707b6..8cc163b2989 100644
> > --- a/src/mapi/glapi/gen/meson.build
> > +++ b/src/mapi/glapi/gen/meson.build
> > @@ -107,6 +107,7 @@ api_xml_files = files(
> >'EXT_external_objects_fd.xml',
> >'EXT_framebuffer_object.xml',
> >'EXT_gpu_shader4.xml',
> > +  'EXT_multisampled_render_to_texture.xml',
> >'EXT_packed_depth_stencil.xml',
> >'EXT_provoking_vertex.xml',
> >'EXT_separate_shader_objects.xml',
> > diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
> > index 4392c4bbd88..3515e312023 100644
> > --- a/src/mesa/drivers/common/meta.c
> > +++ b/src/mesa/drivers/common/meta.c
> > @@ -127,7 +127,7 @@ _mesa_meta_framebuffer_texture_image(struct gl_context 
> > *ctx,
> > assert(att);
> >
> > _mesa_framebuffer_texture(ctx, fb, attachment, att, texObj, texTarget,
> > - level, layer, false);
> > + level, att->NumSamples, layer, false);
> >  }
> >
> >  static struct gl_shader *
> > diff --git a/src/mesa/main/extensions_table.h 
> > b/src/mesa/main/extensions_table.h
> > index a516a1b17f8..f13b8b6a21a 100644
> > --- a/src/mesa/main/extensions_table.h
> > +++ b/src/mesa/main/extensions_table.h
> > @@ -241,6 +241,8 @@ EXT(EXT_map_buffer_range, 
> > ARB_map_buffer_range
> >  EXT(EXT_memory_object   , EXT_memory_object
> >   , GLL, GLC,  x , ES2, 2017)
> >  EXT(EXT_memory_object_fd, EXT_memory_object_fd 
> >   , GLL, GLC,  x , ES2, 2017)
> >  EXT(EXT_multi_draw_arrays   , dummy_true   
> >   , GLL,  x , ES1, ES2, 1999)
> > +EXT(EXT_multisampled_render_to_texture  , 
> > EXT_multisampled_render_to_texture ,  x ,  x ,  x , ES2, 2016)
> > +EXT(EXT_multisampled_render_to_texture2 , 
> > EXT_multisampled_render_to_texture ,  x ,  x ,  x , ES2, 2016)
> >  EXT(EXT_occlusion_query_boolean , ARB_occlusion_query  
> >   ,  x ,  x ,  x , ES2, 2001)
> >  

Re: [Mesa-dev] [PATCH mesa 1/2] egl: add missing includes

[Kristian Høgsberg]

On Fri, Nov 16, 2018 at 9:34 AM Emil Velikov  wrote:
>
> On Fri, 16 Nov 2018 at 10:07, Eric Engestrom  wrote:

I find that I also need

diff --git a/src/egl/main/egldevice.h b/src/egl/main/egldevice.h
index ddcdcd17f5a..03988913ecd 100644
--- a/src/egl/main/egldevice.h
+++ b/src/egl/main/egldevice.h
@@ -30,6 +30,7 @@
 #define EGLDEVICE_INCLUDED


+#include 
 #include 
 #include "egltypedefs.h"

for the use of NULL in the inline _eglLookupDevice further down.

Kristian

> >
> > Signed-off-by: Eric Engestrom 
> > ---
> >  src/egl/drivers/dri2/egl_dri2.c | 1 +
> >  src/egl/main/eglapi.c   | 2 ++
> >  src/egl/main/eglapi.h   | 1 +
> >  src/egl/main/eglglobals.c   | 2 ++
> >  src/egl/main/eglsurface.c   | 2 ++
> >  5 files changed, 8 insertions(+)
> >
>
> I haven't explicitly checked each include but I know you're build
> tested this. For the lot
> Acked-by: Emil Velikov 
>
> -Emil
> ___
> 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 v2 2/5] gallium: Add new PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE

[Kristian Høgsberg]

On Tue, Nov 6, 2018 at 2:44 PM Axel Davy  wrote:
>
> Hi,
>
> Is there anything to be done in the nine state trackers (or other state
> trackers).
>
> Nine uses create_surface. Should it expect the field to be filled
> properly by the driver ?

Nothing is required from any state tracker, but if your API has an
extension like EXT_multisampled_render_to_texture, and the driver has
this new capability, you can set pipe_surface::nr_samples. The driver
will then render with that many samples internally and transparently
resolve the rendering to the (non-MSAA) resource.

> On 06/11/2018 23:09, Kristian H. Kristensen wrote:
> > +   /**
> > +* If a driver doesn't advertise 
> > PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE,
> > +* pipe_surface::nr_samples will always be 0.
> > +*/
> The above comment should be added to the comment below.
> > +   /** Number of samples for the surface.  This can be different from the
> > +* resource nr_samples when the resource is bound using
> > +* FramebufferTexture2DMultisampleEXT.
> > +*/
> > +   unsigned nr_samples:8;

Hm, I probably need to reword that a bit, since it implies the surface
sample count can be same as the resource, when it is only ever either
surface samples = 0 or surface samples > 1 with resource samples = 1.

Kristian

> > +
> >  union pipe_surface_desc u;
> >   };
> >
>
>
> Yours,
>
>
> Axel Davy
>
> ___
> 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 2/4] st/mesa: Add support for EXT_multisampled_render_to_texture

[Kristian Høgsberg]

On Tue, Nov 6, 2018 at 12:09 PM Ilia Mirkin  wrote:
>
> On Tue, Nov 6, 2018 at 2:31 PM Kristian H. Kristensen
>  wrote:
> >
> > In gallium, we model the attachment sample count as a new nr_samples
> > field in pipe_surface. A driver can indicate support for the extension
> > using the new pipe cap, PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE.
> >
> > Signed-off-by: Kristian H. Kristensen 
> > ---
> >  src/gallium/include/pipe/p_defines.h   | 1 +
> >  src/gallium/include/pipe/p_state.h | 6 ++
> >  src/mesa/state_tracker/st_cb_fbo.c | 3 +++
> >  src/mesa/state_tracker/st_cb_fbo.h | 1 +
> >  src/mesa/state_tracker/st_extensions.c | 1 +
> >  5 files changed, 12 insertions(+)
> >
> > diff --git a/src/gallium/include/pipe/p_defines.h 
> > b/src/gallium/include/pipe/p_defines.h
> > index dacedf5b936..0ecfaf3ba5e 100644
> > --- a/src/gallium/include/pipe/p_defines.h
> > +++ b/src/gallium/include/pipe/p_defines.h
> > @@ -823,6 +823,7 @@ enum pipe_cap
> > PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS,
> > PIPE_CAP_MAX_TEXTURE_UPLOAD_MEMORY_BUDGET,
> > PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET,
> > +   PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE,
>
> I think you forgot to "git add src/gallium/docs/source/screen.rst"

Ah yes, uhm, forgot :) Didn't know about that, will update.

> Also, I don't feel strongly about a situation where there are so few
> st/mesa changes, but most of the time, gallium changes are done
> separately of st/mesa changes.

I thought that might be the case. I'll split the commit.

> >  };
> >
> >  /**
> > diff --git a/src/gallium/include/pipe/p_state.h 
> > b/src/gallium/include/pipe/p_state.h
> > index fd670345aad..89cffb15bd8 100644
> > --- a/src/gallium/include/pipe/p_state.h
> > +++ b/src/gallium/include/pipe/p_state.h
> > @@ -443,6 +443,12 @@ struct pipe_surface
> > uint16_t width;   /**< logical width in pixels */
> > uint16_t height;  /**< logical height in pixels */
> >
> > +   /** Number of samples for the surface.  This can be different from the
> > +* resource nr_samples when the resource is bound using
> > +* FramebufferTexture2DMultisampleEXT.
> > +*/
> > +   unsigned nr_samples:8;
> > +
> > union pipe_surface_desc u;
> >  };
> >
> > diff --git a/src/mesa/state_tracker/st_cb_fbo.c 
> > b/src/mesa/state_tracker/st_cb_fbo.c
> > index 0e535257cb4..8901a8680ef 100644
> > --- a/src/mesa/state_tracker/st_cb_fbo.c
> > +++ b/src/mesa/state_tracker/st_cb_fbo.c
> > @@ -516,6 +516,7 @@ st_update_renderbuffer_surface(struct st_context *st,
> > surf->texture != resource ||
> > surf->width != rtt_width ||
> > surf->height != rtt_height ||
> > +   surf->nr_samples != strb->rtt_nr_samples ||
> > surf->u.tex.level != level ||
> > surf->u.tex.first_layer != first_layer ||
> > surf->u.tex.last_layer != last_layer) {
> > @@ -523,6 +524,7 @@ st_update_renderbuffer_surface(struct st_context *st,
> >struct pipe_surface surf_tmpl;
> >memset(_tmpl, 0, sizeof(surf_tmpl));
> >surf_tmpl.format = format;
> > +  surf_tmpl.nr_samples = strb->rtt_nr_samples;
> >surf_tmpl.u.tex.level = level;
> >surf_tmpl.u.tex.first_layer = first_layer;
> >surf_tmpl.u.tex.last_layer = last_layer;
> > @@ -572,6 +574,7 @@ st_render_texture(struct gl_context *ctx,
> > strb->rtt_face = att->CubeMapFace;
> > strb->rtt_slice = att->Zoffset;
> > strb->rtt_layered = att->Layered;
> > +   strb->rtt_nr_samples = att->NumSamples;
> > pipe_resource_reference(>texture, pt);
> >
> > st_update_renderbuffer_surface(st, strb);
> > diff --git a/src/mesa/state_tracker/st_cb_fbo.h 
> > b/src/mesa/state_tracker/st_cb_fbo.h
> > index 345c11442c6..046f01713ce 100644
> > --- a/src/mesa/state_tracker/st_cb_fbo.h
> > +++ b/src/mesa/state_tracker/st_cb_fbo.h
> > @@ -69,6 +69,7 @@ struct st_renderbuffer
> > boolean is_rtt; /**< whether Driver.RenderTexture was called */
> > unsigned rtt_face, rtt_slice;
> > boolean rtt_layered; /**< whether glFramebufferTexture was called */
> > +   unsigned rtt_nr_samples; /**< from FramebufferTexture2DMultisampleEXT */
> >  };
> >
> >
> > diff --git a/src/mesa/state_tracker/st_extensions.c 
> > b/src/mesa/state_tracker/st_extensions.c
> > index 16889074f66..9a1594212dd 100644
> > --- a/src/mesa/state_tracker/st_extensions.c
> > +++ b/src/mesa/state_tracker/st_extensions.c
> > @@ -740,6 +740,7 @@ void st_init_extensions(struct pipe_screen *screen,
> >{ o(EXT_draw_buffers2),PIPE_CAP_INDEP_BLEND_ENABLE   
> > },
> >{ o(EXT_memory_object),PIPE_CAP_MEMOBJ   
> > },
> >{ o(EXT_memory_object_fd), PIPE_CAP_MEMOBJ   
> > },
> > +  { o(EXT_multisampled_render_to_texture), 
> > PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE },
> >{ o(EXT_semaphore),PIPE_CAP_FENCE_SIGNAL 
> >   

Re: [Mesa-dev] [PATCH] egl/android: Declare droid_load_driver() static

[Kristian Høgsberg]

Thanks Tapani!
On Wed, Sep 12, 2018 at 9:47 PM Tapani Pälli  wrote:
>
> Reviewed-by: Tapani Pälli 
>
> On 09/13/2018 02:14 AM, Kristian H. Kristensen wrote:
> > Signed-off-by: Kristian H. Kristensen 
> > ---
> >   src/egl/drivers/dri2/platform_android.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/egl/drivers/dri2/platform_android.c 
> > b/src/egl/drivers/dri2/platform_android.c
> > index ecc0245c9a..00e62b067f 100644
> > --- a/src/egl/drivers/dri2/platform_android.c
> > +++ b/src/egl/drivers/dri2/platform_android.c
> > @@ -1362,7 +1362,7 @@ static const __DRIextension 
> > *droid_image_loader_extensions[] = {
> >  NULL,
> >   };
> >
> > -EGLBoolean
> > +static EGLBoolean
> >   droid_load_driver(_EGLDisplay *disp)
> >   {
> >  struct dri2_egl_display *dri2_dpy = disp->DriverData;
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Workaround the gen9 hw astc5x5 sampler bug

[Kristian Høgsberg]

On Thu, Sep 6, 2018 at 11:40 AM Jason Ekstrand  wrote:
>
> On Thu, Sep 6, 2018 at 1:36 PM Kristian Høgsberg  wrote:
>>
>> On Thu, Sep 6, 2018 at 9:35 AM Jason Ekstrand  wrote:
>> >
>> > From: Topi Pohjolainen 
>> >
>> > gen9 hardware has a bug in the sampler cache that can cause GPU hangs
>> > whenever an texture with aux compression enabled is in the sampler cache
>> > together with an ASTC5x5 texture.  Because we can't control what the
>> > client binds at any given time, we have two options: resolve the CCS or
>> > decompresss the ASTC.  Doing a CCS resolve is far less drastic and will
>> > likely have a smaller performance impact.
>>
>> Looks like a reasonable workaround for an awful hw bug. Should we
>> clear brw->gen9_astc5x5_wa_tex_mask to 0 on batch flush and non-wa
>> related texture cache flushes?
>
>
> That's an interesting question.  My fear if we do that is that someone will 
> come along and flush in a really awkward place between 
> brw_predraw_resolve_inputs and brw_update_texture_surface.  If that happened, 
> we would think it was zero while setting up surface state later on while 
> walking the atoms list.  In particular, I think the very blorp resolves 
> triggered by this code might do that.  I'd rather not risk it.

Yup, it's not exactly trivial to argue that that will never happen, so
better play it safe.

Reviewed-by: Kristian H. Kristensen 

> --Jason
>
>>
>> Kristian
>>
>> > Co-authored-by: Jason Ekstrand 
>> > ---
>> >  src/mesa/drivers/dri/i965/brw_blorp.c |  8 ++
>> >  src/mesa/drivers/dri/i965/brw_context.h   | 10 +++
>> >  src/mesa/drivers/dri/i965/brw_draw.c  | 79 ++-
>> >  .../drivers/dri/i965/brw_wm_surface_state.c   |  6 ++
>> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c |  8 +-
>> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  3 +-
>> >  6 files changed, 108 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
>> > b/src/mesa/drivers/dri/i965/brw_blorp.c
>> > index 7476cee43a4..0d305dea83b 100644
>> > --- a/src/mesa/drivers/dri/i965/brw_blorp.c
>> > +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
>> > @@ -178,11 +178,19 @@ blorp_surf_for_miptree(struct brw_context *brw,
>> >
>> >surf->aux_addr.buffer = mt->aux_buf->bo;
>> >surf->aux_addr.offset = mt->aux_buf->offset;
>> > +
>> > +  if (!is_render_target && brw->screen->devinfo.gen == 9)
>> > + gen9_astc5x5_sampler_wa(brw, GEN9_ASTC5X5_WA_TEX_TYPE_AUX);
>> > } else {
>> >surf->aux_addr = (struct blorp_address) {
>> >   .buffer = NULL,
>> >};
>> >memset(>clear_color, 0, sizeof(surf->clear_color));
>> > +
>> > +  if (!is_render_target && brw->screen->devinfo.gen == 9 &&
>> > +  (mt->format == MESA_FORMAT_RGBA_ASTC_5x5 ||
>> > +   mt->format == MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x5))
>> > + gen9_astc5x5_sampler_wa(brw, GEN9_ASTC5X5_WA_TEX_TYPE_ASTC5x5);
>> > }
>> > assert((surf->aux_usage == ISL_AUX_USAGE_NONE) ==
>> >(surf->aux_addr.buffer == NULL));
>> > diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
>> > b/src/mesa/drivers/dri/i965/brw_context.h
>> > index d3b96953467..a7bc3612d75 100644
>> > --- a/src/mesa/drivers/dri/i965/brw_context.h
>> > +++ b/src/mesa/drivers/dri/i965/brw_context.h
>> > @@ -168,6 +168,11 @@ enum brw_cache_id {
>> > BRW_MAX_CACHE
>> >  };
>> >
>> > +enum gen9_astc5x5_wa_tex_type {
>> > +   GEN9_ASTC5X5_WA_TEX_TYPE_ASTC5x5 = 1 << 0,
>> > +   GEN9_ASTC5X5_WA_TEX_TYPE_AUX = 1 << 1,
>> > +};
>> > +
>> >  enum brw_state_id {
>> > /* brw_cache_ids must come first - see brw_program_cache.c */
>> > BRW_STATE_URB_FENCE = BRW_MAX_CACHE,
>> > @@ -1326,6 +1331,8 @@ struct brw_context
>> >  */
>> > enum isl_aux_usage draw_aux_usage[MAX_DRAW_BUFFERS];
>> >
>> > +   enum gen9_astc5x5_wa_tex_type gen9_astc5x5_wa_tex_mask;
>> > +
>> > __DRIcontext *driContext;
>> > struct intel_screen *screen;
>> >  };
>> > @@ -1350,6 +1357,9 @@ void intel_update_renderbuffers(__DRIcontext 
>> > *context,
>> >  __DRIdrawable *drawable);
>> >  voi

Re: [Mesa-dev] [PATCH] i965: Workaround the gen9 hw astc5x5 sampler bug

[Kristian Høgsberg]

On Thu, Sep 6, 2018 at 9:35 AM Jason Ekstrand  wrote:
>
> From: Topi Pohjolainen 
>
> gen9 hardware has a bug in the sampler cache that can cause GPU hangs
> whenever an texture with aux compression enabled is in the sampler cache
> together with an ASTC5x5 texture.  Because we can't control what the
> client binds at any given time, we have two options: resolve the CCS or
> decompresss the ASTC.  Doing a CCS resolve is far less drastic and will
> likely have a smaller performance impact.

Looks like a reasonable workaround for an awful hw bug. Should we
clear brw->gen9_astc5x5_wa_tex_mask to 0 on batch flush and non-wa
related texture cache flushes?

Kristian

> Co-authored-by: Jason Ekstrand 
> ---
>  src/mesa/drivers/dri/i965/brw_blorp.c |  8 ++
>  src/mesa/drivers/dri/i965/brw_context.h   | 10 +++
>  src/mesa/drivers/dri/i965/brw_draw.c  | 79 ++-
>  .../drivers/dri/i965/brw_wm_surface_state.c   |  6 ++
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c |  8 +-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  3 +-
>  6 files changed, 108 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> index 7476cee43a4..0d305dea83b 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> @@ -178,11 +178,19 @@ blorp_surf_for_miptree(struct brw_context *brw,
>
>surf->aux_addr.buffer = mt->aux_buf->bo;
>surf->aux_addr.offset = mt->aux_buf->offset;
> +
> +  if (!is_render_target && brw->screen->devinfo.gen == 9)
> + gen9_astc5x5_sampler_wa(brw, GEN9_ASTC5X5_WA_TEX_TYPE_AUX);
> } else {
>surf->aux_addr = (struct blorp_address) {
>   .buffer = NULL,
>};
>memset(>clear_color, 0, sizeof(surf->clear_color));
> +
> +  if (!is_render_target && brw->screen->devinfo.gen == 9 &&
> +  (mt->format == MESA_FORMAT_RGBA_ASTC_5x5 ||
> +   mt->format == MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x5))
> + gen9_astc5x5_sampler_wa(brw, GEN9_ASTC5X5_WA_TEX_TYPE_ASTC5x5);
> }
> assert((surf->aux_usage == ISL_AUX_USAGE_NONE) ==
>(surf->aux_addr.buffer == NULL));
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index d3b96953467..a7bc3612d75 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -168,6 +168,11 @@ enum brw_cache_id {
> BRW_MAX_CACHE
>  };
>
> +enum gen9_astc5x5_wa_tex_type {
> +   GEN9_ASTC5X5_WA_TEX_TYPE_ASTC5x5 = 1 << 0,
> +   GEN9_ASTC5X5_WA_TEX_TYPE_AUX = 1 << 1,
> +};
> +
>  enum brw_state_id {
> /* brw_cache_ids must come first - see brw_program_cache.c */
> BRW_STATE_URB_FENCE = BRW_MAX_CACHE,
> @@ -1326,6 +1331,8 @@ struct brw_context
>  */
> enum isl_aux_usage draw_aux_usage[MAX_DRAW_BUFFERS];
>
> +   enum gen9_astc5x5_wa_tex_type gen9_astc5x5_wa_tex_mask;
> +
> __DRIcontext *driContext;
> struct intel_screen *screen;
>  };
> @@ -1350,6 +1357,9 @@ void intel_update_renderbuffers(__DRIcontext *context,
>  __DRIdrawable *drawable);
>  void intel_prepare_render(struct brw_context *brw);
>
> +void gen9_astc5x5_sampler_wa(struct brw_context *brw,
> + enum gen9_astc5x5_wa_tex_type curr_mask);
> +
>  void brw_predraw_resolve_inputs(struct brw_context *brw, bool rendering,
>  bool *draw_aux_buffer_disabled);
>
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index 71461d7b0a7..d261db81907 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -378,6 +378,39 @@ intel_disable_rb_aux_buffer(struct brw_context *brw,
> return found;
>  }
>
> +/** Implement the ASTC 5x5 sampler workaround
> + *
> + * Gen9 sampling hardware has a bug where an ASTC 5x5 compressed surface
> + * cannot live in the sampler cache at the same time as an aux compressed
> + * surface.  In order to work around the bug we have to stall rendering with 
> a
> + * CS and pixel scoreboard stall (implicit in the CS stall) and invalidate 
> the
> + * texture cache whenever one of ASTC 5x5 or aux compressed may be in the
> + * sampler cache and we're about to render with something which samples from
> + * the other.
> + *
> + * In the case of a single shader which textures from both ASTC 5x5 and
> + * a texture which is CCS or HiZ compressed, we have to resolve the aux
> + * compressed texture prior to rendering.  This second part is handled in
> + * brw_predraw_resolve_inputs() below.
> + */
> +void
> +gen9_astc5x5_sampler_wa(struct brw_context *brw,
> +enum gen9_astc5x5_wa_tex_type curr_mask)
> +{
> +   if (brw->screen->devinfo.gen != 9)
> +  return;
> +
> +   if (((brw->gen9_astc5x5_wa_tex_mask & GEN9_ASTC5X5_WA_TEX_TYPE_ASTC5x5) &&
> +(curr_mask & 

Re: [Mesa-dev] [PATCH 1/3] freedreno: Fix warnings

[Kristian Høgsberg]

The remaining two patches are stuck in moderation for being too big.
They update the generated headers and adds the a6xx backend. They're
in this branch:

  https://gitlab.freedesktop.org/krh/mesa/commits/wip/a6xx-rebase-3

for reference.

Kristian

On Wed, Aug 15, 2018 at 9:18 AM Kristian H. Kristensen
 wrote:
>
> From: "Kristian H. Kristensen" 
>
> Signed-off-by: Kristian H. Kristensen 
> ---
>  src/gallium/drivers/freedreno/a5xx/fd5_compute.c   | 2 +-
>  src/gallium/drivers/freedreno/freedreno_resource.c | 8 
>  src/gallium/drivers/freedreno/ir3/ir3.h| 8 ++--
>  src/gallium/drivers/freedreno/ir3/ir3_cmdline.c| 2 +-
>  src/gallium/drivers/freedreno/ir3/ir3_shader.h | 4 +---
>  5 files changed, 9 insertions(+), 15 deletions(-)
>
> diff --git a/src/gallium/drivers/freedreno/a5xx/fd5_compute.c 
> b/src/gallium/drivers/freedreno/a5xx/fd5_compute.c
> index 8e2c228e90..66ed7a4af5 100644
> --- a/src/gallium/drivers/freedreno/a5xx/fd5_compute.c
> +++ b/src/gallium/drivers/freedreno/a5xx/fd5_compute.c
> @@ -181,7 +181,7 @@ static void
>  fd5_launch_grid(struct fd_context *ctx, const struct pipe_grid_info *info)
>  {
> struct fd5_compute_stateobj *so = ctx->compute;
> -   struct ir3_shader_key key = {0};
> +   struct ir3_shader_key key = {};
> struct ir3_shader_variant *v;
> struct fd_ringbuffer *ring = ctx->batch->draw;
> unsigned i, nglobal = 0;
> diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c 
> b/src/gallium/drivers/freedreno/freedreno_resource.c
> index 3fbf50003e..f882cf5a8b 100644
> --- a/src/gallium/drivers/freedreno/freedreno_resource.c
> +++ b/src/gallium/drivers/freedreno/freedreno_resource.c
> @@ -211,7 +211,7 @@ fd_try_shadow_resource(struct fd_context *ctx, struct 
> fd_resource *rsc,
>
> mtx_unlock(>screen->lock);
>
> -   struct pipe_blit_info blit = {0};
> +   struct pipe_blit_info blit = {};
> blit.dst.resource = prsc;
> blit.dst.format   = prsc->format;
> blit.src.resource = pshadow;
> @@ -305,7 +305,7 @@ static void
>  fd_blit_from_staging(struct fd_context *ctx, struct fd_transfer *trans)
>  {
> struct pipe_resource *dst = trans->base.resource;
> -   struct pipe_blit_info blit = {0};
> +   struct pipe_blit_info blit = {};
>
> blit.dst.resource = dst;
> blit.dst.format   = dst->format;
> @@ -325,7 +325,7 @@ static void
>  fd_blit_to_staging(struct fd_context *ctx, struct fd_transfer *trans)
>  {
> struct pipe_resource *src = trans->base.resource;
> -   struct pipe_blit_info blit = {0};
> +   struct pipe_blit_info blit = {};
>
> blit.src.resource = src;
> blit.src.format   = src->format;
> @@ -372,7 +372,7 @@ flush_resource(struct fd_context *ctx, struct fd_resource 
> *rsc, unsigned usage)
> fd_batch_reference(_batch, rsc->write_batch);
>
> if (usage & PIPE_TRANSFER_WRITE) {
> -   struct fd_batch *batch, *batches[32] = {0};
> +   struct fd_batch *batch, *batches[32] = {};
> uint32_t batch_mask;
>
> /* This is a bit awkward, probably a fd_batch_flush_locked()
> diff --git a/src/gallium/drivers/freedreno/ir3/ir3.h 
> b/src/gallium/drivers/freedreno/ir3/ir3.h
> index 8bac91660b..63215cefc9 100644
> --- a/src/gallium/drivers/freedreno/ir3/ir3.h
> +++ b/src/gallium/drivers/freedreno/ir3/ir3.h
> @@ -445,14 +445,12 @@ struct ir3 {
>  #endif
>  };
>
> -typedef struct nir_register nir_register;
> -
>  struct ir3_array {
> struct list_head node;
> unsigned length;
> unsigned id;
>
> -   nir_register *r;
> +   struct nir_register *r;
>
> /* To avoid array write's from getting DCE'd, keep track of the
>  * most recent write.  Any array access depends on the most
> @@ -470,13 +468,11 @@ struct ir3_array {
>
>  struct ir3_array * ir3_lookup_array(struct ir3 *ir, unsigned id);
>
> -typedef struct nir_block nir_block;
> -
>  struct ir3_block {
> struct list_head node;
> struct ir3 *shader;
>
> -   const nir_block *nblock;
> +   const struct nir_block *nblock;
>
> struct list_head instr_list;  /* list of ir3_instruction */
>
> diff --git a/src/gallium/drivers/freedreno/ir3/ir3_cmdline.c 
> b/src/gallium/drivers/freedreno/ir3/ir3_cmdline.c
> index 23d5006352..b41c32d375 100644
> --- a/src/gallium/drivers/freedreno/ir3/ir3_cmdline.c
> +++ b/src/gallium/drivers/freedreno/ir3/ir3_cmdline.c
> @@ -379,7 +379,7 @@ int main(int argc, char **argv)
>
> while (n < argc) {
> char *filename = argv[n];
> -   char *ext = rindex(filename, '.');
> +   char *ext = strrchr(filename, '.');
>
> if (strcmp(ext, ".tgsi") == 0) {
> if (num_files != 0)
> diff --git a/src/gallium/drivers/freedreno/ir3/ir3_shader.h 
> b/src/gallium/drivers/freedreno/ir3/ir3_shader.h
> index 507e89c473..288e9fa4e7 100644
> --- 

Re: [Mesa-dev] Why are pbuffers backed by a pixmaps (Was Re: [PATCH] egl: Fix leak of X11 pixmaps backing pbuffers in DRI3.)

[Kristian Høgsberg]

On Mon, Aug 13, 2018 at 3:53 AM Emil Velikov  wrote:
>
> Hi Adam,
>
> Thanks for the extensive write-up.
>
> On 9 August 2018 at 20:30, Adam Jackson  wrote:
> > On Thu, 2018-08-09 at 18:22 +0100, Emil Velikov wrote:
> >
> >> In the GLX case, it's required due to server-side rendering. One needs
> >> a separate primitive for each pbuffer, thus the information can be
> >> passed long the wire.
> >
> > I can't parse this. "Primitive"?
> >
> > So, backstory time. GLX_SGIX_pbuffer was the genesis of pbuffers.
> > Here's what it has to say about how a pbuffer is unlike other GLX
> > drawables (some of which is a comment about how things happened to work
> > on IRIX):
> >
> > "GLXPbuffers are equivalent to GLXPixmaps with the following
> > exceptions:
> >
> > 1.  There is no associated X pixmap. Also, since a GLXPbuffer is a GLX
> > resource, it may not be possible to render to it using X or an
> > X extension other than GLX.
> >
> > 2.  The format of the color buffers and the type and size of any
> > associated ancillary buffers for a GLXPbuffer can only be
> > described with a GLXFBConfig -- an X Visual cannot be used.
> >
> > 3.  It is possible to create a GLXPbuffer whose contents may be
> > asynchronously lost at any time.
> >
> > 4.  GLXPbuffers can be rendered to using either direct or indirect
> > rendering contexts.
> >
> > 5.  The allocation of a GLXPbuffer can fail if there are insufficient
> > resources (i.e., all the pbuffer memory has been allocated and
> > the implementation does not virtualize pbuffer memory.)"
> >
> > In contrast, a GLXPixmap _must_ be renderable by X11, cannot lose its
> > contents, and _may_ not be renderable by direct contexts. All of this
> > dates to like 1997, so we didn't have FBOs yet, and any rendering
> > surface would have been allocated by "the server" [1]. That extension
> > was merged into GLX 1.3 pretty much unchanged, and GLX 1.3 was 1998.
> >
> > Xorg didn't get GLX 1.3 working until like 2007 [2]. As an
> > implementation choice, Xorg _does_ back pbuffers with pixmaps, both in
> > that it calls ->CreatePixmap internally to make them and that it tracks
> > them as actual pixmaps [3]. We never clobber pbuffers, we have no
> > problem rendering to pbuffers from X11, and we have no problem
> > rendering to GLXPixmaps from direct contexts. Effectively, other than
> > the resource type, the difference between a pbuffer and a glxpixmap is
> > that the latter takes two XIDs and two resource creation calls.
> >
> So if I understood you correctly [and the spec] there is no
> requirement (nor ban) on rendering to pbuffers from X11.
> It's an implementation decision to allow it.

You can't render to the underlying pixmaps, since the drawable ID is
internal to the GLX implementation.

> > EGL dates to 2003, which means it predates even EXT_framebuffer_object,
> > so the pbuffer bit of GLX was kept in the new API. The EGL spec says a
> > pbuffer has no associated native window or native window type - no
> > kidding, it's not a window - but it does not require that a pbuffer
> > have no native object backing it at all.
> >
> I> Now, direct rendering in GLX is underspecified; the implementation is
> > free to use whatever subset of GLX, and whatever private protocol, it
> > wants. In principle the client could allocate the pbuffer's storage
> > from the "server" (the drm, here), and pass that handle and its new XID
> > name to the X server to bind them together so indirect contexts can
> > name it as well.
> >
> > An EGL implementation could take even more liberties. Even on an X11
> > window system there's no intrinsic reason that an EGL pbuffer need to
> > exist as a native winsys object; all that's required is that pbuffers
> > work with any API that takes an EGLSurface parameter. You might choose
> > to mirror EGL surfaces as GLX objects, or not, whatever your
> > implementation finds convenient. In practice, we back pbuffers with
> > pixmaps because we also back pixmaps with pixmaps, and there's no
> > reason to make those paths diverge more than they have to.
> >
> I was thinking in the opposite direction - we already have pbuffer
> implementation, which is duplicated across egl/android and
> egl/surfaceless.
> We could trivially make that a helper function and reuse across the board.
>
> No need to special case X11, Android, etc - far less code and
> divergence across platforms.
> Using the same codepath across all EGL won't be that bad, right?

I think that's good clean up at this point, but when I wrote the
pbuffer support it was the other way around - we already had pixmaps
and it was easy to use those for pbuffers.

Kristian

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

Re: [Mesa-dev] [PATCH 1/2] mesa : MESA_framebuffer_flip_y extension

[Kristian Høgsberg]

On Thu, Jun 7, 2018 at 6:02 PM Jason Ekstrand  wrote:
>
> On June 7, 2018 16:47:17 Ilia Mirkin  wrote:
>
> > On Thu, Jun 7, 2018 at 7:31 PM, Fritz Koenig  wrote:
> >> On Thu, Jun 7, 2018 at 4:10 PM Ilia Mirkin  wrote:
> >>>
> >>> It's slightly different than what you've specified, but can't you
> >>> achieve this with GL_ARB_clip_control / GL_EXT_clip_control ?
> >>
> >> It can be, but there is a lot of extra work that needs to be done to
> >> get ReadPixels to work correctly.  It would be preferable to have the
> >> driver handle all of that work.
> >
> > A bit more prior art research:
> >
> > GL_MESA_pack_invert - specifies this precisely for glReadPixels.
> >
> > Your version of the spec needs more information. What does "flipped"
> > mean? Does it affect gl_FragCoord / gl_SamplePosition /
> > interpolateAtOffset? Does it affect the winding?

The effect of this extension is mostly not visible from GL - the
corner case where it is is if you take a texture from a flipped fbo
and bind to a non-flipped FBO. I think it makes more sense to specify
as not affecting anything, except for the pixels in the buffer ending
up upside down. That's more robust than listing all the state that it
does modify under the hood to achieve that and is more future proof
wrt extensions that add state that depends on coordinate system
polarity.

The use case in question is WebGL rendering in Chrome, which renders
to an FBO with the normal GL orientation. The end result is a buffer
that is upside down as far as KMS is concerned. We want to use the
buffer on a KMS plane, but not all display controllers support
y-flipping. We could (and tried) use all the extensions listed above
to flip the rendering, but got stuck on glReadPixels. If we have to
use a mesa extension to achieve this, I'd much rather depend on this
simple extension that just activates functionality already present
(and tested on each CI run). We also don't have to rewrite WebGL
visible state (viewports, scissor etc), which make this all much
simpler.

> > Might help to say that this is designed to undo the winsys flipping
> > relative to fbo rendering.
>
> More designed to emulate winsys flipping on a texture that isn't flipped.
> Basically, everything is "like normal" except that the result of your
> rendering is flipped vertically in the texture.  It's a bit wired but
> that's the idea.

It's kinda interesting how we ended up in this situation... mesa has
always flipped winsys FBOs and not user FBOs, but there's no overhead
in just flipping all FBOs, and back before we started importing X
pixmaps and EGLImages and binding to FBOs, there was no way to know
which way the user FBO was oriented in memory. So I don't think it was
ever necessary to distinguish between user and winsys FBOs, at least
not for coordinate orientation. Then we started rendering to external
buffers, and the non-flippedness of user FBOs leaked out and became de
facto convention, which we probably can't change now.

So today we have this situation where applications that render to a
winsys FBO work as they've always done, compositors or other apps that
knowingly render to a user FBO and then present the result externally
(eg KMS) just render upside down. And then WebGL, which has the
traditional GL orientation but render through an FBO to an EGLImage.

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

Re: [Mesa-dev] [PATCH 1/2] mesa : MESA_framebuffer_flip_y extension

[Kristian Høgsberg]

On Thu, Jun 7, 2018 at 4:02 PM Fritz Koenig  wrote:
>
> Adds an extension to glFramebufferParameteri
> that will specify if the framebuffer is vertically
> flipped. Historically system framebuffers are
> vertically flipped and user framebuffers are not.
> Checking to see the state was done by looking at
> the name field.  This adds an explicit field.
> ---
>  docs/specs/MESA_framebuffer_flip_y.spec | 59 +
>  include/GLES2/gl2ext.h  |  5 +++
>  src/mapi/glapi/registry/gl.xml  |  6 +++
>  src/mesa/main/extensions_table.h|  1 +
>  src/mesa/main/fbobject.c|  8 
>  src/mesa/main/framebuffer.c |  1 +
>  src/mesa/main/glheader.h|  3 ++
>  src/mesa/main/mtypes.h  |  4 ++
>  8 files changed, 87 insertions(+)
>  create mode 100644 docs/specs/MESA_framebuffer_flip_y.spec
>
> diff --git a/docs/specs/MESA_framebuffer_flip_y.spec 
> b/docs/specs/MESA_framebuffer_flip_y.spec
> new file mode 100644
> index 00..b9867e0683
> --- /dev/null
> +++ b/docs/specs/MESA_framebuffer_flip_y.spec
> @@ -0,0 +1,59 @@
> +Name
> +
> +MESA_framebuffer_flip_y
> +
> +Name Strings
> +
> +GL_MESA_framebuffer_flip_y
> +
> +Contact
> +
> +Fritz Koenig 
> +
> +Status
> +
> +Proposal
> +
> +Version
> +
> +Version 1, June 7, 2018
> +
> +Number
> +
> +TBD
> +
> +Dependencies
> +
> +OpenGLES 3.1 is required.
> +
> +Overview
> +
> +This extension adds the ability to specify that the internal framebuffer
> +object is vertically flipped.
> +
> +IP Status
> +
> +None
> +
> +Issues
> +
> +None
> +
> +New Procedures and Functions
> +
> +None
> +
> +New Types
> +
> +None
> +
> +New Tokens
> +
> +Accepted by the  argument of FramebufferParameteri:
> +
> +GL_FRAMEBUFFER_FLIP_Y_EXT   0x8BBB

The name of the token should use the same prefix/suffix as the
extension, that is: GL_FRAMEBUFFER_FLIP_Y_MESA

> +
> +Revision History
> +
> +Version 1, June, 2018
> +Initial draft (Fritz Koenig)
> diff --git a/include/GLES2/gl2ext.h b/include/GLES2/gl2ext.h
> index a7d19a1fc8..7fb5e9ca5f 100644
> --- a/include/GLES2/gl2ext.h
> +++ b/include/GLES2/gl2ext.h
> @@ -2334,6 +2334,11 @@ GL_APICALL void GL_APIENTRY glGetPerfQueryInfoINTEL 
> (GLuint queryId, GLuint quer
>  #endif
>  #endif /* GL_INTEL_performance_query */
>
> +#ifndef GL_MESA_framebuffer_flip_y
> +#define GL_MESA_framebuffer_flip_y 1
> +#define GL_FRAMEBUFFER_FLIP_Y_EXT 0x8BBB
> +#endif /* GL_MESA_framebuffer_flip_y */
> +
>  #ifndef GL_MESA_program_binary_formats
>  #define GL_MESA_program_binary_formats 1
>  #define GL_PROGRAM_BINARY_FORMAT_MESA 0x875F
> diff --git a/src/mapi/glapi/registry/gl.xml b/src/mapi/glapi/registry/gl.xml
> index 833478aa51..3a3d4f3d81 100644
> --- a/src/mapi/glapi/registry/gl.xml
> +++ b/src/mapi/glapi/registry/gl.xml
> @@ -6568,6 +6568,7 @@ typedef unsigned int GLhandleARB;
>  
>  
>  
> +
>  
>
>   comment="Reassigned from AMD to QCOM">
> @@ -44356,6 +44357,11 @@ typedef unsigned int GLhandleARB;
>  
>  
>  
> +
> +
> +
> +
> +
>  
>  
>  
> diff --git a/src/mesa/main/extensions_table.h 
> b/src/mesa/main/extensions_table.h
> index 79ef228b69..03a5c7b345 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -322,6 +322,7 @@ EXT(KHR_texture_compression_astc_hdr, 
> KHR_texture_compression_astc_hdr
>  EXT(KHR_texture_compression_astc_ldr, 
> KHR_texture_compression_astc_ldr   , GLL, GLC,  x , ES2, 2012)
>  EXT(KHR_texture_compression_astc_sliced_3d  , 
> KHR_texture_compression_astc_sliced_3d , GLL, GLC,  x , ES2, 2015)
>
> +EXT(MESA_framebuffer_flip_y , MESA_framebuffer_flip_y
> ,   x,   x,  x , ES2, 2018)
>  EXT(MESA_pack_invert, MESA_pack_invert   
> , GLL, GLC,  x ,  x , 2002)
>  EXT(MESA_shader_integer_functions   , MESA_shader_integer_functions  
> , GLL, GLC,  x ,  30, 2016)
>  EXT(MESA_texture_signed_rgba, EXT_texture_snorm  
> , GLL, GLC,  x ,  x , 2009)
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index a63e8b8de5..efa000ede7 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -1448,6 +1448,14 @@ framebuffer_parameteri(struct gl_context *ctx, struct 
> gl_framebuffer *fb,
> case GL_FRAMEBUFFER_DEFAULT_FIXED_SAMPLE_LOCATIONS:
>fb->DefaultGeometry.FixedSampleLocations = param;
>break;
> +   case GL_FRAMEBUFFER_FLIP_Y_EXT:
> +  if (!ctx->Extensions.MESA_framebuffer_flip_y) {
> + _mesa_error(ctx, GL_INVALID_OPERATION,
> +  "%s(MESA_framebuffer_flip_y not implemented)", func);
> + break;
> + 

Re: [Mesa-dev] [PATCH] st/va: Support YUV formats in vaCreateSurfaces

[Kristian Høgsberg]

Looks good - I was going to say the C++ comment should be /* */ but I see
there's already a // in the file so...  ¯\_(ツ)_/¯

Reviewed-by: Kristian H. Kristensen 
On Fri, Apr 27, 2018 at 8:35 AM Drew Davenport 
wrote:

> diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trackers/va/surface.c
> index 0824f1b74a..003f88f1f9 100644
> --- a/src/gallium/state_trackers/va/surface.c
> +++ b/src/gallium/state_trackers/va/surface.c
> @@ -531,10 +531,12 @@ surface_from_external_memory(VADriverContextP ctx,
vlVaSurface *surface,
>   {
>  vlVaDriver *drv;
>  struct pipe_screen *pscreen;
> -   struct pipe_resource *resource;
>  struct pipe_resource res_templ;
>  struct winsys_handle whandle;
>  struct pipe_resource *resources[VL_NUM_COMPONENTS];
> +   const enum pipe_format *resource_formats = NULL;
> +   VAStatus result;
> +   int i;

>  pscreen = VL_VA_PSCREEN(ctx);
>  drv = VL_VA_DRIVER(ctx);
> @@ -548,17 +550,12 @@ surface_from_external_memory(VADriverContextP ctx,
vlVaSurface *surface,
>  memory_attribute->num_planes < 1)
> return VA_STATUS_ERROR_INVALID_PARAMETER;

> -   switch (memory_attribute->pixel_format) {
> -   case VA_FOURCC_RGBA:
> -   case VA_FOURCC_RGBX:
> -   case VA_FOURCC_BGRA:
> -   case VA_FOURCC_BGRX:
> -  if (memory_attribute->num_planes != 1)
> - return VA_STATUS_ERROR_INVALID_PARAMETER;
> -  break;
> -   default:
> +   if (memory_attribute->num_planes > VL_NUM_COMPONENTS)
> +  return VA_STATUS_ERROR_INVALID_PARAMETER;
> +
> +   resource_formats = vl_video_buffer_formats(pscreen,
templat->buffer_format);
> +   if (!resource_formats)
> return VA_STATUS_ERROR_INVALID_PARAMETER;
> -   }

>  memset(_templ, 0, sizeof(res_templ));
>  res_templ.target = PIPE_TEXTURE_2D;
> @@ -567,29 +564,45 @@ surface_from_external_memory(VADriverContextP ctx,
vlVaSurface *surface,
>  res_templ.array_size = 1;
>  res_templ.width0 = memory_attribute->width;
>  res_templ.height0 = memory_attribute->height;
> -   res_templ.format = surface->templat.buffer_format;
>  res_templ.bind = PIPE_BIND_SAMPLER_VIEW;
>  res_templ.usage = PIPE_USAGE_DEFAULT;

>  memset(, 0, sizeof(struct winsys_handle));
>  whandle.type = DRM_API_HANDLE_TYPE_FD;
>  whandle.handle = memory_attribute->buffers[index];
> -   whandle.stride = memory_attribute->pitches[0];
> -
> -   resource = pscreen->resource_from_handle(pscreen, _templ,
,
> -
  PIPE_HANDLE_USAGE_READ_WRITE);
> -
> -   if (!resource)
> -  return VA_STATUS_ERROR_ALLOCATION_FAILED;

> +   // Create a resource for each plane.
>  memset(resources, 0, sizeof resources);
> -   resources[0] = resource;
> +   for (i = 0; i < memory_attribute->num_planes; i++) {
> +  res_templ.format = resource_formats[i];
> +  if (res_templ.format == PIPE_FORMAT_NONE) {
> + result = VA_STATUS_ERROR_INVALID_PARAMETER;
> + goto fail;
> +  }

> -   surface->buffer = vl_video_buffer_create_ex2(drv->pipe, templat,
resources);
> -   if (!surface->buffer)
> -  return VA_STATUS_ERROR_ALLOCATION_FAILED;
> +  whandle.stride = memory_attribute->pitches[i];
> +  whandle.offset = memory_attribute->offsets[i];
> +  resources[i] = pscreen->resource_from_handle(pscreen, _templ,
,
> +
PIPE_HANDLE_USAGE_READ_WRITE);
> +  if (!resources[i]) {
> + result = VA_STATUS_ERROR_ALLOCATION_FAILED;
> + goto fail;
> +  }
> +   }

> +   surface->buffer = vl_video_buffer_create_ex2(drv->pipe, templat,
resources);
> +   if (!surface->buffer) {
> +  result = VA_STATUS_ERROR_ALLOCATION_FAILED;
> +  goto fail;
> +   }
>  return VA_STATUS_SUCCESS;
> +
> +fail:
> +   for (i = 0; i < VL_NUM_COMPONENTS; i++) {
> +  if (resources[i])
> + pscreen->resource_destroy(pscreen, resources[i]);
> +   }
> +   return result;
>   }

>   VAStatus
> --
> 2.17.0.441.gb46fe60e1d-goog

> ___
> 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/va: Fix potential buffer overread

[Kristian Høgsberg]

On Tue, Apr 24, 2018 at 4:02 PM Drew Davenport 
wrote:

> VASurfaceAttribExternalBuffers.pitches is indexed by
> plane. Current implementation only supports single plane layout.

Reviewed-by: Kristian H. Kristensen 

> ---
>   src/gallium/state_trackers/va/surface.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trackers/va/surface.c
> index 8604136944..6fe21b89e5 100644
> --- a/src/gallium/state_trackers/va/surface.c
> +++ b/src/gallium/state_trackers/va/surface.c
> @@ -574,7 +574,7 @@ suface_from_external_memory(VADriverContextP ctx,
vlVaSurface *surface,
>  memset(, 0, sizeof(struct winsys_handle));
>  whandle.type = DRM_API_HANDLE_TYPE_FD;
>  whandle.handle = memory_attibute->buffers[index];
> -   whandle.stride = memory_attibute->pitches[index];
> +   whandle.stride = memory_attibute->pitches[0];

>  resource = pscreen->resource_from_handle(pscreen, _templ,
,

  PIPE_HANDLE_USAGE_READ_WRITE);
> --
> 2.17.0.441.gb46fe60e1d-goog

> ___
> 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] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

[Kristian Høgsberg]

On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher <alexdeuc...@gmail.com> wrote:

> On Wed, Feb 21, 2018 at 1:14 AM, Chad Versace <chadvers...@chromium.org>
wrote:
> > On Thu 21 Dec 2017, Daniel Vetter wrote:
> >> On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen <
hoegsb...@google.com> wrote:
> >>> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico <
mvicom...@nvidia.com> wrote:
> >>>> On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg <
hoegsb...@gmail.com> wrote:
> >>>>> I'd like to see concrete examples of actual display controllers
> >>>>> supporting more format layouts than what can be specified with a 64
> >>>>> bit modifier.
> >>>>
> >>>> The main problem is our tiling and other metadata parameters can't
> >>>> generally fit in a modifier, so we find passing a blob of metadata a
> >>>> more suitable mechanism.
> >>>
> >>> I understand that you may have n knobs with a total of more than a
total of
> >>> 56 bits that configure your tiling/swizzling for color buffers. What
I don't
> >>> buy is that you need all those combinations when passing buffers
around
> >>> between codecs, cameras and display controllers. Even if you're
sharing
> >>> between the same 3D drivers in different processes, I expect just
locking
> >>> down, say, 64 different combinations (you can add more over time) and
> >>> assigning each a modifier would be sufficient. I doubt you'd extract
> >>> meaningful performance gains from going all the way to a blob.
> >
> > I agree with Kristian above. In my opinion, choosing to encode in
> > modifiers a precise description of every possible tiling/compression
> > layout is not technically incorrect, but I believe it misses the point.
> > The intention behind modifiers is not to exhaustively describe all
> > possibilites.
> >
> > I summarized this opinion in VK_EXT_image_drm_format_modifier,
> > where I wrote an "introdution to modifiers" section. Here's an excerpt:
> >
> > One goal of modifiers in the Linux ecosystem is to enumerate for
each
> > vendor a reasonably sized set of tiling formats that are
appropriate for
> > images shared across processes, APIs, and/or devices, where each
> > participating component may possibly be from different vendors.
> > A non-goal is to enumerate all tiling formats supported by all
vendors.
> > Some tiling formats used internally by vendors are inappropriate for
> > sharing; no modifiers should be assigned to such tiling formats.

> Where it gets tricky is how to select that subset?  Our tiling mode
> are defined more by the asic specific constraints than the tiling mode
> itself.  At a high level we have basically 3 tiling modes (out of 16
> possible) that would be the minimum we'd want to expose for gfx6-8.
> gfx9 uses a completely new scheme.
> 1. Linear (per asic stride requirements, not usable by many hw blocks)
> 2. 1D Thin (5 layouts, displayable, depth, thin, rotated, thick)
> 3. 2D Thin (1D tiling constraints, plus pipe config (18 possible),
> tile split (7 possible), sample split (4 possible), num banks (4
> possible), bank width (4 possible), bank height (4 possible), macro
> tile aspect (4 possible) all of which are asic config specific)

> I guess we could do something like:
> AMD_GFX6_LINEAR_ALIGNED_64B
> AMD_GFX6_LINEAR_ALIGNED_256B
> AMD_GFX6_LINEAR_ALIGNED_512B
> AMD_GFX6_1D_THIN_DISPLAY
> AMD_GFX6_1D_THIN_DEPTH
> AMD_GFX6_1D_THIN_ROTATED
> AMD_GFX6_1D_THIN_THIN
> AMD_GFX6_1D_THIN_THICK

AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_

Re: [Mesa-dev] [PATCH 1/2] i965/bufmgr: Add a create_from_prime_tiled function

[Kristian Høgsberg]

On Sun, Jan 21, 2018 at 8:05 PM, Jason Ekstrand  wrote:
> This new function is an import and a set tiling in one go.
> ---
>  src/mesa/drivers/dri/i965/brw_bufmgr.c | 41 
> ++
>  src/mesa/drivers/dri/i965/brw_bufmgr.h |  4 
>  2 files changed, 36 insertions(+), 9 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> index 469895e..889350c 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> @@ -1133,8 +1133,9 @@ brw_bo_get_tiling(struct brw_bo *bo, uint32_t 
> *tiling_mode,
> return 0;
>  }
>
> -struct brw_bo *
> -brw_bo_gem_create_from_prime(struct brw_bufmgr *bufmgr, int prime_fd)
> +static struct brw_bo *
> +brw_bo_gem_create_from_prime_internal(struct brw_bufmgr *bufmgr, int 
> prime_fd,
> +  int tiling_mode, uint32_t stride)
>  {
> int ret;
> uint32_t handle;
> @@ -1185,14 +1186,18 @@ brw_bo_gem_create_from_prime(struct brw_bufmgr 
> *bufmgr, int prime_fd)
> bo->reusable = false;
> bo->external = true;
>
> -   memclear(get_tiling);
> -   get_tiling.handle = bo->gem_handle;
> -   if (drmIoctl(bufmgr->fd, DRM_IOCTL_I915_GEM_GET_TILING, _tiling))
> -  goto err;
> +   if (tiling_mode < 0) {
> +  memclear(get_tiling);
> +  get_tiling.handle = bo->gem_handle;
> +  if (drmIoctl(bufmgr->fd, DRM_IOCTL_I915_GEM_GET_TILING, _tiling))
> + goto err;
>
> -   bo->tiling_mode = get_tiling.tiling_mode;
> -   bo->swizzle_mode = get_tiling.swizzle_mode;
> -   /* XXX stride is unknown */
> +  bo->tiling_mode = get_tiling.tiling_mode;
> +  bo->swizzle_mode = get_tiling.swizzle_mode;
> +  /* XXX stride is unknown */
> +   } else {
> +  bo_set_tiling_internal(bo, tiling_mode, stride);
> +   }

Since most of this logic is specific to the tiling == -1 case, maybe
move the get_tiling path to brw_bo_gem_create_from_prime(). Either
move bo_set_tiling() to brw_bo_gem_create_from_prime_tiled() or call
it from here when stride > 0.

Either way,

Reviewed-by: Kristian H. Kristensen 

>
>  out:
> mtx_unlock(>lock);
> @@ -1204,6 +1209,24 @@ err:
> return NULL;
>  }
>
> +struct brw_bo *
> +brw_bo_gem_create_from_prime(struct brw_bufmgr *bufmgr, int prime_fd)
> +{
> +   return brw_bo_gem_create_from_prime_internal(bufmgr, prime_fd, -1, 0);
> +}
> +
> +struct brw_bo *
> +brw_bo_gem_create_from_prime_tiled(struct brw_bufmgr *bufmgr, int prime_fd,
> +   uint32_t tiling_mode, uint32_t stride)
> +{
> +   assert(tiling_mode == I915_TILING_NONE ||
> +  tiling_mode == I915_TILING_X ||
> +  tiling_mode == I915_TILING_Y);
> +
> +   return brw_bo_gem_create_from_prime_internal(bufmgr, prime_fd,
> +tiling_mode, stride);
> +}
> +
>  static void
>  brw_bo_make_external(struct brw_bo *bo)
>  {
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.h 
> b/src/mesa/drivers/dri/i965/brw_bufmgr.h
> index 8bfb0e4..6811e78 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.h
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.h
> @@ -339,6 +339,10 @@ void brw_destroy_hw_context(struct brw_bufmgr *bufmgr, 
> uint32_t ctx_id);
>  int brw_bo_gem_export_to_prime(struct brw_bo *bo, int *prime_fd);
>  struct brw_bo *brw_bo_gem_create_from_prime(struct brw_bufmgr *bufmgr,
>  int prime_fd);
> +struct brw_bo *brw_bo_gem_create_from_prime_tiled(struct brw_bufmgr *bufmgr,
> +  int prime_fd,
> +  uint32_t tiling_mode,
> +  uint32_t stride);
>
>  uint32_t brw_bo_export_gem_handle(struct brw_bo *bo);
>
> --
> 2.5.0.400.gff86faf
>
> ___
> 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 2/2] i965: Set tiling on BOs imported with modifiers

[Kristian Høgsberg]

On Mon, Jan 22, 2018 at 10:03 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> On January 22, 2018 09:10:52 Kristian Høgsberg <hoegsb...@gmail.com> wrote:
>
>> On Sun, Jan 21, 2018 at 8:05 PM, Jason Ekstrand <ja...@jlekstrand.net>
>> wrote:
>>>
>>> We need this to ensure that GTT maps work on buffers we get from Vulkan
>>> on the off chance that someone does a readpixels or something.  Soon, we
>>> will be removing GTT maps from i965 entirely and this can be reverted.
>>> None the less, it's needed for stable.
>>>
>>> Cc: mesa-sta...@lists.freedesktop.org
>>> Cc: Kenneth Graunke <kenn...@whitecape.org>
>>> ---
>>>  src/mesa/drivers/dri/i965/intel_screen.c | 11 ++-
>>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
>>> b/src/mesa/drivers/dri/i965/intel_screen.c
>>> index b563bbf..e877f93 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_screen.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
>>> @@ -1043,7 +1043,16 @@ intel_create_image_from_fds_common(__DRIscreen
>>> *dri_screen,
>>>
>>> image->planar_format = f;
>>>
>>> -   image->bo = brw_bo_gem_create_from_prime(screen->bufmgr, fds[0]);
>>> +   if (modifier != DRM_FORMAT_MOD_INVALID) {
>>> +  const struct isl_drm_modifier_info *mod_info =
>>> + isl_drm_modifier_get_info(modifier);
>>
>>
>> You need to handle mod_info == NULL for unknown modifiers.
>
>
> The code above this checks that the modifier is supported and bails if it
> isn't.

So it does. Looking forward to our bright future without gtt maps. In
the interim, thanks for fixing this.

Reviewed-by: Kristian H. Kristensen <hoegsb...@google.com>

Kristian

>
>
>> Kristian
>>
>>> +  uint32_t tiling = isl_tiling_to_i915_tiling(mod_info->tiling);
>>> +  image->bo = brw_bo_gem_create_from_prime_tiled(screen->bufmgr,
>>> fds[0],
>>> + tiling,
>>> strides[0]);
>>> +   } else {
>>> +  image->bo = brw_bo_gem_create_from_prime(screen->bufmgr, fds[0]);
>>> +   }
>>> +
>>> if (image->bo == NULL) {
>>>free(image);
>>>return NULL;
>>> --
>>> 2.5.0.400.gff86faf
>>>
>>> ___
>>> 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 2/2] i965: Set tiling on BOs imported with modifiers

[Kristian Høgsberg]

On Sun, Jan 21, 2018 at 8:05 PM, Jason Ekstrand  wrote:
> We need this to ensure that GTT maps work on buffers we get from Vulkan
> on the off chance that someone does a readpixels or something.  Soon, we
> will be removing GTT maps from i965 entirely and this can be reverted.
> None the less, it's needed for stable.
>
> Cc: mesa-sta...@lists.freedesktop.org
> Cc: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/intel_screen.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index b563bbf..e877f93 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -1043,7 +1043,16 @@ intel_create_image_from_fds_common(__DRIscreen 
> *dri_screen,
>
> image->planar_format = f;
>
> -   image->bo = brw_bo_gem_create_from_prime(screen->bufmgr, fds[0]);
> +   if (modifier != DRM_FORMAT_MOD_INVALID) {
> +  const struct isl_drm_modifier_info *mod_info =
> + isl_drm_modifier_get_info(modifier);

You need to handle mod_info == NULL for unknown modifiers.

Kristian

> +  uint32_t tiling = isl_tiling_to_i915_tiling(mod_info->tiling);
> +  image->bo = brw_bo_gem_create_from_prime_tiled(screen->bufmgr, fds[0],
> + tiling, strides[0]);
> +   } else {
> +  image->bo = brw_bo_gem_create_from_prime(screen->bufmgr, fds[0]);
> +   }
> +
> if (image->bo == NULL) {
>free(image);
>return NULL;
> --
> 2.5.0.400.gff86faf
>
> ___
> 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] [ANNOUNCE] Wayland/Weston/Mesa HDR support (proof of concept)

[Kristian Høgsberg]

On Thu, Dec 21, 2017 at 6:21 AM, Ville Syrjälä
 wrote:
> Here's a quick proof of concept implementation of HDR support
> for Wayland/Weston/Mesa.
>
> I'm not posting this as patches right now because I'm not sure
> that would do much good given how rough this is. But here are
> all the repos/branches:
> git://github.com/vsyrjala/wayland.git hdr_poc
> git://github.com/vsyrjala/wayland-protocols.git hdr_poc
> git://github.com/vsyrjala/weston.git hdr_poc
> git://github.com/vsyrjala/mesa.git hdr_poc
> git://github.com/vsyrjala/linux.git hdr_poc
>
> The kernel HDR bits were partially done by Uma Shankar, the rest
> I hacked together myself.

Hi Ville,

This looks really interesting, thanks for the heads up.

Kristian

> As far as Wayland protocol goes I'm adding three new
> extensions (should probably just have one with several requests?):
> - zwp_colorspace_v1 - Specify the primaries/whitepoint chromacities
>   and transfer function for a surface
> - zwp_ycbcr_encoding_v1 - Specify the encoding for YCbCr surfaces
> - zwp_hdr_metadata_v1 - Allow the client to pass HDR metadata to
>   the compositor
> Note that I've not given any thought to how the compositor might
> advertize its capabilities.
>
> I also hacked in a bunch of 10bpc+ YCbCr support to the protocol and
> Weston so that I can actually get some HDR video onto the screen.
>
> On the Mesa side I've crudely implementated the following egl/vk
> extesions:
> - EXT_gl_colorspace_*
> - EXT_surface_SMPTE2086_metadata
> - EXT_surface_CTA861_3_metadata
>   (sidenote: these egl extension don't seem to match CTA-861.3 nicely
>when it comes to the min/max luminance stuff)
> - VK_EXT_hdr_metadata
>
> VK_EXT_hdr_metadata I plugged in for anv only, but the implementation
> is in the common wayland wsi code. Note that I haven't actually tested
> the vulkan stuff at all because I don't talk Vulkan (at least not yet).
>
> Also note that I've not connected up the HDR metadata pipeline
> properly. The client can provide the metadata, but the compositor
> doesn't actually pass it on to the display. For the time being the
> HDR metadata that gets passed to the display is partially specified
> in weston.ini and partially just hardocded (see
> libweston/compositor-drm.c).
>
> The Weston implementation involves a bunch of shaders and matrices to
> do the ycbcr->rgb, "degamma", csc for each surface, blend it all as
> linear RGB into an fp16 fbo, and finally blit that out to the final
> framebuffer while applying the ST2084 PQ transfer function in the
> process.
>
> The reason for the fp16 fbo is that we store the full 1 nits of
> linear RGB. That needs plenty of precisions in the low end so your
> regular 10bpc fb doesn't seem to cut it. And also the display gamma LUT
> doesn't have enough input precision for it either. Sadly there's no
> fixed function hardware in the GPU to do the ST2084 PQ when blending.
> When the output is not HDR I do skip the fp16 fbo step and use the
> gamma LUT in the display engine instead.
>
> Another approach to the precisions problem might be to not store the
> entire 1 nits of linear, and just cut off the super bright stuff
> (your display can't show it anyway). But I've not really bothered to
> figure out how low in nits we'd have to go here, probably too low.
> Maybe blending as sRGB and the doing sRGB->PQ with the gamma LUT might
> help a little bit?
>
> Ideally we would bypass this all for a single fullscreen HDR surface
> and just pass the PQ encoded data directly through. But I've not
> implemented that. In fact I even disable the buffer_age damage stuff
> when using the fp16 fbo, so we'll recompose the entire screen every
> time. Yeah, I'm lazy.
>
> Another thought that occurred to me was that it shouldn't be too hard
> to make Weston do some tone mapping when there's a HDR client and no
> HDR screen. To that end I included the ACES colorspaces in my
> colorspace list, but I didn't actually look into plugging the ACES tone
> mapping curve into the shaders. Might be a fun excercise, even though
> the practical applications might be close to nil. Probably better to
> not advertize HDR/wide gamuts when we can't actually output the stuff,
> and instead let the client do its own tone mapping.
>
> OK, so what can you do with this? I've included a few test clients:
> - simple-colorspace
>   Just a copy of simple-egl but it uses the egl extension to specify
>   the colorspace, and produces ST2084 PQ encoded data when asked
> - simple-hdr-video
>   Uses ffmpeg to decode video into shm buffers, and sets the
>   colorspace/ycbcr encoding etc. appropriately. Ie. this one can
>   actually output HDR video
>
> Here's a weston.ini snippet that gets you outputting HDR:
> [core]
> gbm-format=xrgb2101010
>
> [output]
> name=HDMI-A-2
> colorspace=BT.2020
> gamma=ST2084
> max_sdr_nits=100
>
> Hardware wise you'll need a HDR capable display obviously, and
> you'll need an Intel Geminilake GPU. Older Intel platforms 

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

[Kristian Høgsberg]

On Wed, Dec 20, 2017 at 11:51 AM, Daniel Vetter  wrote:
> Since this also involves the kernel let's add dri-devel ...
>
> On Wed, Dec 20, 2017 at 5:51 PM, Miguel Angel Vico  
> wrote:
>> Hi all,
>>
>> As many of you already know, I've been working with James Jones on the
>> Generic Device Allocator project lately. He started a discussion thread
>> some weeks ago seeking feedback on the current prototype of the library
>> and advice on how to move all this forward, from a prototype stage to
>> production. For further reference, see:
>>
>>https://lists.freedesktop.org/archives/mesa-dev/2017-November/177632.html
>>
>> From the thread above, we came up with very interesting high level
>> design ideas for one of the currently missing parts in the library:
>> Usage transitions. That's something I'll personally work on during the
>> following weeks.
>>
>>
>> In the meantime, I've been working on putting together an open source
>> implementation of the allocator mechanisms using the Nouveau driver for
>> all to be able to play with.
>>
>> Below I'm seeking feedback on a bunch of changes I had to make to
>> different components of the graphics stack:
>>
>> ** Allocator **
>>
>>   An allocator driver implementation on top of Nouveau. The current
>>   implementation only handles pitch linear layouts, but that's enough
>>   to have the kmscube port working using the allocator and Nouveau
>>   drivers.
>>
>>   You can pull these changes from
>>
>>   
>> https://github.com/mvicomoya/allocator/tree/wip/mvicomoya/nouveau-driver
>>
>> ** Mesa **
>>
>>   James's kmscube port to use the allocator relies on the
>>   EXT_external_objects extension to import allocator allocations to
>>   OpenGL as a texture object. However, the Nouveau implementation of
>>   these mechanisms is missing in Mesa, so I went ahead and added them.
>>
>>   You can pull these changes from
>>
>>   
>> https://github.com/mvicomoya/mesa/tree/wip/mvicomoya/EXT_external_objects-nouveau
>>
>>   Also, James's kmscube port uses the NVX_unix_allocator_import
>>   extension to attach allocator metadata to texture objects so the
>>   driver knows how to deal with the imported memory.
>>
>>   Note that there isn't a formal spec for this extension yet. For now,
>>   it just serves as an experimental mechanism to import allocator
>>   memory in OpenGL, and attach metadata to texture objects.
>>
>>   You can pull these changes (written on top of the above) from:
>>
>>   
>> https://github.com/mvicomoya/mesa/tree/wip/mvicomoya/NVX_unix_allocator_import
>>
>> ** kmscube **
>>
>>   Mostly minor fixes and improvements on top of James's port to use the
>>   allocator. Main thing is the allocator initialization path will use
>>   EGL_MESA_platform_surfaceless if EGLDevice platform isn't supported
>>   by the underlying EGL implementation.
>>
>>   You can pull these changes from:
>>
>>   
>> https://github.com/mvicomoya/kmscube/tree/wip/mvicomoya/allocator-nouveau
>>
>>
>> With all the above you should be able to get kmscube working using the
>> allocator on top of the Nouveau driver.
>>
>>
>> Another of the missing pieces before we can move this to production is
>> importing allocations to DRM FB objects. This is probably one of the
>> most sensitive parts of the project as it requires modification/addition
>> of kernel driver interfaces.
>>
>> At XDC2017, James had several hallway conversations with several people
>> about this, all having different opinions. I'd like to take this
>> opportunity to also start a discussion about what's the best option to
>> create a path to get allocator allocations added as DRM FB objects.
>>
>> These are the few options we've considered to start with:
>>
>>   A) Have vendor-private ioctls to set properties on GEM objects that
>>  are inherited by the FB objects. This is how our (NVIDIA) desktop
>>  DRM driver currently works. This would require every vendor to add
>>  their own ioctl to process allocator metadata, but the metadata is
>>  actually a vendor-agnostic object more like DRM modifiers. We'd
>>  like to come up with a vendor-agnostic solutions that can be
>>  integrated to core DRM.
>>
>>   B) Add a new drmModeAddFBWithMetadata() command that takes allocator
>>  metadata blobs for each plane of the FB. Some people in the
>>  community have mentioned this is their preferred design. This,
>>  however, means we'd have to go through the exercise of adding
>>  another metadata mechanism to the whole graphics stack.
>>
>>   C) Shove allocator metadata into DRM by defining it to be a separate
>>  plane in the image, and using the existing DRM modifiers mechanism
>>  to indicate there is another plane for each "real" plane added. It
>>  isn't clear how this scales to surfaces that already need several
>>  planes, but there are some people that see this as the only way
>>  forward. Also, we would have to create a 

Re: [Mesa-dev] [PATCH 3/3] spirv: Allow OpPtrAccessChain for block indices

[Kristian Høgsberg]

On Thu, Nov 30, 2017 at 9:15 PM, Jason Ekstrand  wrote:
> After talking with Kristian a bit on IRC, I think there is a bit more
> explanation needed.  I would be happy to add something like this to the
> commit message or as a comment upon request.
>
> There is an interesting edge case in the variable pointers extension when
> you do an OpPtrAccessChain on a pointer to a struct decorated block.  In
> this case there is not entirely clear if you should look for an array stride
> and treat it as an implicit array of such structs or if you should treat it
> as a single block in an array of blocks which would imply incrementing the
> index portion of the descriptor tuple.  We choose the later approach and
> assume that it's an array of blocks and therefore an array of SSBOs.  This
> has two advantages:
>
>  1) The SPIR-V spec for the OpPtrAccessChain instruction says "Base is
> treated as the address of the first element of an array, and the Element
> element’s address is computed to be the base for the Indexes, as per
> OpAccessChain."  Taken literally, that would mean that your struct type is
> supposed to be treated as an array of such a struct and, since it's
> decorated block, that means an array of blocks which corresponds to an array
> descriptor.
>
>  2) Taking this approach ensures that any array dereference in an
> OpAccessChain can be replaced with an OpAccessChain that selects element 0
> of the array together with an OpPtrAccessChain taking that result and adding
> to the index.  In particular, it ensures that this works when the array
> dereference is on an array of SSBOs.
>
> The downside (there always is one) is that this might be somewhat surprising
> behavior to apps.  I can easily see an app slapping an ArrayStride on the
> pointer and expecting that struct to implicitly turn into an array of
> structs and being a bit shocked when they get GPU hangs because of trying to
> access some random texture as an SSBO.  We could attempt to be a bit
> "smarter" and go looking for an ArrayStride decoration and, if we find one,
> use that instead of incrementing the block index.  However, that seems like
> a recipe for disaster because the behavior suddenly depends on adding a
> decoration.
>
> Really, this whole mess is an unfortunate complication arising from
> attempting to add variable pointers onto a description of resource
> descriptors that's based on GLSL syntax.  I'm in the process of trying to
> get things clarified within the SPIR-V working group in Khronos.  In the
> mean time, I believe this to be the best and most reasonable interpretation
> of the spec as-written today.

Series

Reviewed-by: Kristian H. Kristensen 

with the caveat that the behavior is still up in the air, but the
series looks like it does what it's intended to do, and it seems that
this is what the Khronos discussion and CTS is converging on.

> --Jason
>
>
> On Thu, Nov 30, 2017 at 7:06 PM, Jason Ekstrand 
> wrote:
>>
>> The SPIR-V spec is a bit underspecified when it comes to exactly how
>> you're allowed to use OpPtrAccessChain and what it means in certain edge
>> cases.  In particular, what if the base pointer of the OpPtrAccessChain
>> points to the base struct of an SSBO instead of an element in that SSBO.
>> The original variable pointers implementation in mesa assumed that you
>> weren't allowed to do an OpPtrAccessChain that adjusted the block index
>> and asserted such.  However, there are some CTS tests that do this and,
>> if the CTS does it, someone will do it in the wild so we should probably
>> handle it.  With this commit, we significantly reduce our assumptions
>> and should be able to handle more-or-less anything.
>>
>> The one assumption we still make for correctness is that if we see an
>> OpPtrAccessChain on a pointer to a struct decorated block that the block
>> index should be adjusted.  In theory, someone could try to put an array
>> stride on such a pointer and try to make the SSBO an implicit array of
>> the base struct and we would not give them what they want.  That said,
>> any index other than 0 would count as an out-of-bounds access which is
>> invalid.
>> ---
>>  src/compiler/spirv/vtn_variables.c | 128
>> -
>>  1 file changed, 83 insertions(+), 45 deletions(-)
>>
>> diff --git a/src/compiler/spirv/vtn_variables.c
>> b/src/compiler/spirv/vtn_variables.c
>> index 09b3d35..89ce939 100644
>> --- a/src/compiler/spirv/vtn_variables.c
>> +++ b/src/compiler/spirv/vtn_variables.c
>> @@ -157,6 +157,22 @@ vtn_variable_resource_index(struct vtn_builder *b,
>> struct vtn_variable *var,
>> return >dest.ssa;
>>  }
>>
>> +static nir_ssa_def *
>> +vtn_resource_reindex(struct vtn_builder *b, nir_ssa_def *base_index,
>> + nir_ssa_def *offset_index)
>> +{
>> +   nir_intrinsic_instr *instr =
>> +  nir_intrinsic_instr_create(b->nb.shader,
>> + 

Re: [Mesa-dev] [PATCH 2/2] i965/miptree: Use the tiling from the modifier instead of the BO

[Kristian Høgsberg]

On Tue, Dec 5, 2017 at 9:43 AM, Kristian Høgsberg <hoegsb...@gmail.com> wrote:
> On Tue, Dec 5, 2017 at 8:49 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
>> On Tue, Dec 5, 2017 at 8:23 AM, Kristian Høgsberg <hoegsb...@gmail.com>
>> wrote:
>>>
>>> On Tue, Dec 5, 2017 at 7:57 AM, Jason Ekstrand <ja...@jlekstrand.net>
>>> wrote:
>>> > On Tue, Dec 5, 2017 at 1:22 AM, Daniel Stone <dan...@fooishbar.org>
>>> > wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> On 18 November 2017 at 00:10, Jason Ekstrand <ja...@jlekstrand.net>
>>> >> wrote:
>>> >> > This fixes a bug where we were taking the tiling from the BO
>>> >> > regardless
>>> >> > of what the modifier said.  When we got images in from Vulkan where
>>> >> > it
>>> >> > doesn't set the tiling on the BO, we would treat them as linear even
>>> >> > though the modifier expressly said to treat it as Y-tiled.
>>> >>
>>> >> For some reason I thought Ken had already reviewed this and it landed,
>>> >> until Kristian mentioned last night.
>>> >
>>> >
>>> > There's been some discussion about what the right thing to do is here.
>>> > I've
>>> > got a patch (which is now landed) which will make us set the tiling from
>>> > Vulkan just like GL does.  It's rather annoying but I think that's
>>> > marginally better.
>>>
>>> I don't know that it's better - it reinforces the notion that you have
>>> to make the kernel-side tiling match for the dma-buf import extension
>>> to work. I think it'd be better to land these patches (btw, Rb: me
>>> (can you even do parenthetical Rbs?))
>>
>>
>> I'll allow it. :)
>>
>>>
>>> and call set-tiling in mesa.
>>
>>
>> Yeah, I think that's reasonable.  Really, this should only be a problem if
>> we have a bunch of users trying to use the same BO with different modifiers.
>> It can happen in theory (immagine two images in the same BO, one X and one
>> Y) but it's a pretty crazy case.
>
> It's not a complete solution, of course, but at least we're kicking
> the can down the road of increasingly esoteric use cases.
>
>>>
>>> The
>>> assumption being that if the tiling doesn't match the modifier, then
>>> maybe the producer didn't care about kernel tiling? Alternatively,
>>> could we set bo->tiling = INCONSISTENT or such in mesa and then use
>>> that to avoid the gtt map paths?

Actually, for compressed textures, you already must have a way to deal
with glTexSubImage2D and similar without falling back to GTT maps. Can
you just handle miptrees with mismatched modifiers (or perhaps just
any valid modifier) the same way?

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

Re: [Mesa-dev] [PATCH 2/2] i965/miptree: Use the tiling from the modifier instead of the BO

[Kristian Høgsberg]

On Tue, Dec 5, 2017 at 8:49 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> On Tue, Dec 5, 2017 at 8:23 AM, Kristian Høgsberg <hoegsb...@gmail.com>
> wrote:
>>
>> On Tue, Dec 5, 2017 at 7:57 AM, Jason Ekstrand <ja...@jlekstrand.net>
>> wrote:
>> > On Tue, Dec 5, 2017 at 1:22 AM, Daniel Stone <dan...@fooishbar.org>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> On 18 November 2017 at 00:10, Jason Ekstrand <ja...@jlekstrand.net>
>> >> wrote:
>> >> > This fixes a bug where we were taking the tiling from the BO
>> >> > regardless
>> >> > of what the modifier said.  When we got images in from Vulkan where
>> >> > it
>> >> > doesn't set the tiling on the BO, we would treat them as linear even
>> >> > though the modifier expressly said to treat it as Y-tiled.
>> >>
>> >> For some reason I thought Ken had already reviewed this and it landed,
>> >> until Kristian mentioned last night.
>> >
>> >
>> > There's been some discussion about what the right thing to do is here.
>> > I've
>> > got a patch (which is now landed) which will make us set the tiling from
>> > Vulkan just like GL does.  It's rather annoying but I think that's
>> > marginally better.
>>
>> I don't know that it's better - it reinforces the notion that you have
>> to make the kernel-side tiling match for the dma-buf import extension
>> to work. I think it'd be better to land these patches (btw, Rb: me
>> (can you even do parenthetical Rbs?))
>
>
> I'll allow it. :)
>
>>
>> and call set-tiling in mesa.
>
>
> Yeah, I think that's reasonable.  Really, this should only be a problem if
> we have a bunch of users trying to use the same BO with different modifiers.
> It can happen in theory (immagine two images in the same BO, one X and one
> Y) but it's a pretty crazy case.

It's not a complete solution, of course, but at least we're kicking
the can down the road of increasingly esoteric use cases.

>>
>> The
>> assumption being that if the tiling doesn't match the modifier, then
>> maybe the producer didn't care about kernel tiling? Alternatively,
>> could we set bo->tiling = INCONSISTENT or such in mesa and then use
>> that to avoid the gtt map paths?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965/miptree: Use the tiling from the modifier instead of the BO

[Kristian Høgsberg]

On Tue, Dec 5, 2017 at 7:57 AM, Jason Ekstrand  wrote:
> On Tue, Dec 5, 2017 at 1:22 AM, Daniel Stone  wrote:
>>
>> Hi,
>>
>> On 18 November 2017 at 00:10, Jason Ekstrand  wrote:
>> > This fixes a bug where we were taking the tiling from the BO regardless
>> > of what the modifier said.  When we got images in from Vulkan where it
>> > doesn't set the tiling on the BO, we would treat them as linear even
>> > though the modifier expressly said to treat it as Y-tiled.
>>
>> For some reason I thought Ken had already reviewed this and it landed,
>> until Kristian mentioned last night.
>
>
> There's been some discussion about what the right thing to do is here.  I've
> got a patch (which is now landed) which will make us set the tiling from
> Vulkan just like GL does.  It's rather annoying but I think that's
> marginally better.

I don't know that it's better - it reinforces the notion that you have
to make the kernel-side tiling match for the dma-buf import extension
to work. I think it'd be better to land these patches (btw, Rb: me
(can you even do parenthetical Rbs?)) and call set-tiling in mesa. The
assumption being that if the tiling doesn't match the modifier, then
maybe the producer didn't care about kernel tiling? Alternatively,
could we set bo->tiling = INCONSISTENT or such in mesa and then use
that to avoid the gtt map paths?

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] [PATCH 00/12] anv: Add support for the variablePointers feature

[Kristian Høgsberg]

On Thu, Oct 19, 2017 at 11:04 AM, Jason Ekstrand  wrote:
> Not to be confused with variablePointersStorageBuffer which is the
> subset of VK_KHR_variable_pointers required to enable the extension.
> This gives us "full" support for variable pointers.
>
> The approach chosen here was to do the lowering to _shared intrinsics
> directly in spirv_to_nir instead of using the _var intrinsics and using
> nir_lower_io.  Pointers with a storage class of Workgroup are given an
> implicit std430 layout and now go through the same offset pointer paths as
> UBO and SSBO access.  The whole thing really ended up working out rather
> cleanly.
>
> There are some downsides to this approach.  One, is that we can't delete
> unused shared variables post-optimization.  Also, the driver may be able to
> handle better than std430.  Both of these can lead to some waisted SLM
> space.  This also means that we can't do any deref-based load/store
> elimination optimizations on SLM but we didn't really before so that's no
> great loss; SLM is now exactly as hard to optimize as SSBOs.

I was going to take a quick look at this and ended up doing a proper
review. Very readable and clean series. I thought it was a little odd
(unmotivated) to add the struct vtn_builder argument to
vtn_pointer_uses_ssa_offset in "spirv: Refactor a couple of pointer
query helpers"  when it isn't used until "spirv: Add support for
lowering workgroup access to offsets", but whatevs. I'm curious how
much better you think a backend should be able to pack? What kind of
improvements over std430 can you realistically expect? Also,what kind
of unused shared variables wouldn't nir itself be able to remove?

Reviewed-by: Kristian H. Kristensen 


> Connor, Yes, I know that this is not quite the approach you were suggesting
> on IRC.  I considered how we might add some sort of deref intrinsic and I
> don't see a good way of doing so without rewriting large chunks of NIR.  I
> think that rewrite is probably worth it some day but that day is not today.
> We people asking for this feature so I really don't want to delay on a
> major NIR rewrite.
>
> Cc: Connor Abbott 
> Cc: Chad Versace 
> Cc: Dave Airlie 
>
> Jason Ekstrand (12):
>   spirv: Drop the impl field from vtn_builder
>   spirv: Only emit functions which are actually used
>   spirv: Use a dereference instead of vtn_variable_resource_index
>   spirv: Add a switch statement for the block store opcode
>   spirv: Refactor the base case of offset_pointer_dereference
>   spirv: Convert the supported_extensions struct to spirv_options
>   spirv: Refactor a couple of pointer query helpers
>   spirv: Use offset_pointer_dereference to instead of
> get_vulkan_resource_index
>   spirv: Add theoretical support for single component pointers
>   spirv: Rename get_shared_nir_atomic_op to get_var_nir_atomic_op
>   spirv: Add support for lowering workgroup access to offsets
>   anv: Add support for the variablePointers feature
>
>  src/amd/vulkan/radv_shader.c   |  23 ++--
>  src/compiler/spirv/nir_spirv.h |  34 --
>  src/compiler/spirv/spirv_to_nir.c  | 180 -
>  src/compiler/spirv/vtn_cfg.c   |   4 +-
>  src/compiler/spirv/vtn_private.h   |  30 +++--
>  src/compiler/spirv/vtn_variables.c | 229 
> -
>  src/intel/vulkan/anv_device.c  |   2 +-
>  src/intel/vulkan/anv_pipeline.c|  25 ++--
>  8 files changed, 372 insertions(+), 155 deletions(-)
>
> --
> 2.5.0.400.gff86faf
>
> ___
> 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 2/2] anv: flag batch & instruction BOs for capture

[Kristian Høgsberg]

On Fri, Nov 17, 2017 at 9:48 AM, Lionel Landwerlin
 wrote:
> When the kernel support flagging our BO, let's mark batch &
> instruction BOs for capture so then can be included in the error
> state.
>
> Signed-off-by: Lionel Landwerlin 
> ---
>  src/intel/vulkan/anv_device.c  | 6 --
>  src/intel/vulkan/anv_private.h | 1 +
>  2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 35bccaee6d2..28e2b1923be 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -362,6 +362,7 @@ anv_physical_device_init(struct anv_physical_device 
> *device,
>goto fail;
>
> device->has_exec_async = anv_gem_get_param(fd, I915_PARAM_HAS_EXEC_ASYNC);
> +   device->has_exec_capture = anv_gem_get_param(fd, 
> I915_PARAM_HAS_EXEC_CAPTURE);
> device->has_exec_fence = anv_gem_get_param(fd, I915_PARAM_HAS_EXEC_FENCE);
> device->has_syncobj = anv_gem_get_param(fd, 
> I915_PARAM_HAS_EXEC_FENCE_ARRAY);
> device->has_syncobj_wait = device->has_syncobj &&
> @@ -1213,7 +1214,8 @@ VkResult anv_CreateDevice(
>
> uint64_t bo_flags =
>physical_device->supports_48bit_addresses ? 
> EXEC_OBJECT_SUPPORTS_48B_ADDRESS : 0 |
> -  physical_device->has_exec_async ? EXEC_OBJECT_ASYNC : 0;
> +  physical_device->has_exec_async ? EXEC_OBJECT_ASYNC : 0 |
> +  physical_device->has_exec_capture ? EXEC_OBJECT_CAPTURE : 0;
>
> anv_bo_pool_init(>batch_bo_pool, device, bo_flags);
>
> @@ -1230,7 +1232,7 @@ VkResult anv_CreateDevice(
>goto fail_bo_cache;
>
> result = anv_state_pool_init(>instruction_state_pool, device, 
> 16384,
> -bo_flags);
> +bo_flags | EXEC_OBJECT_CAPTURE);

Should this be conditional on physical_device->has_exec_capture?

> if (result != VK_SUCCESS)
>goto fail_dynamic_state_pool;
>
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
> index f9770788a6d..6d4e43f2e68 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -773,6 +773,7 @@ struct anv_physical_device {
>  struct isl_device   isl_dev;
>  int cmd_parser_version;
>  boolhas_exec_async;
> +boolhas_exec_capture;
>  boolhas_exec_fence;
>  boolhas_syncobj;
>  boolhas_syncobj_wait;
> --
> 2.15.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 33/33] intel: add aubinator ui

[Kristian Høgsberg]

On Wed, Nov 1, 2017 at 2:25 PM, Lionel Landwerlin
 wrote:
> On 01/11/17 20:30, Dylan Baker wrote:
>>
>> Quoting Scott D Phillips (2017-11-01 10:30:09)
>>>
>>> Lionel Landwerlin  writes:
>>>
 On 31/10/17 21:11, Scott D Phillips wrote:
>>
>> +}
>
> [snip imgui]
>
> imgui seems to be the first instance of someone pasting a sizeable
> third
> party library into the repo.  I'm not sure how everyone feels about
> that. Unfortunately it seems like imgui isn't packaged by any distros
> that I can see either.
>
> Maybe we could do some meson wrap magic or something to pull it in
> without having to commit the code.
>
 Copying seems to be the main way anybody is using it. Are you suggesting
 a submodule?
>>>
>>> Right, something like making a 'wrap' for imgui that can go download and
>>> build the source:
>>>
>>> http://mesonbuild.com/Wrap-dependency-system-manual.html
>>>
>>> Really no idea if this is a great or terrible idea though. Dylan might
>>> have a better idea.
>>>
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>> I'm really not thrilled with the idea of pulling such a large fast moving
>> project into the tree either, though there is president, we have gtest in
>> tree
>> already.
>>
>> A wrap might be a good way to build it it, especially for an optional tool
>> that
>> distros aren't expected to package. I wonder if upstream would take a
>> meson build
>> specifically for this purpose? Would you like me to follow up with them
>> and see
>> if that would be an option (meson feels [rightly] that it's preferable to
>> try to
>> get a meson build into the upstream project before adding it to wrapdb)?
>>
>> Dylan
>
>
> I'll ask but it seems the ImGui project is really not meant to be packaged
> like most software we find in Linux distros.
> There are a few glue example to work on various versions window systems and
> OpenGL/Vulkan, but these are just meant as examples.
> It's expected whoever uses it will embedded it in its project and tweak the
> few things it needs (either event plumbing or adding new
> colors-scheme/widgets).

Also, let me add that the fact that the upstream project moves fast
isn't a problem here. The usage model for Imgui is that you include a
snapshot in repo your that has the features you need and write the ui
you need with that. There's no need to update that snapshot at any
time, except if you decide you need a new feature or fixes from
upstream.

Kristian

> In our case, I wrote the Gtk3 backend, I'm pretty sure there is little
> interest in having it upstream.
>
> -
> Lionel
>
> ___
> 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] i965: Revert absolute mode for constant buffer pointers.

[Kristian Høgsberg]

On Thu, Oct 19, 2017 at 4:18 PM, Kenneth Graunke  wrote:
> The kernel doesn't initialize the value of the INSTPM or CS_DEBUG_MODE2
> registers at context initialization time.  Instead, they're inherited
> from whatever happened to be running on the GPU prior to first run of a
> new context.  So, when we started setting these, other contexts in the
> system started inheriting our values.  Since this controls whether
> 3DSTATE_CONSTANT_* takes a pointer or an offset, getting the wrong
> setting is fatal for almost any process which isn't expecting this.
>
> Unfortunately, VA-API and Beignet don't initialize this (nor does older
> Mesa), so they will die horribly if we start doing this.  UXA and SNA
> don't use any push constants, so they are unaffected.
>
> The kernel developers are apparently uninterested in making the proto-
> context initialize these registers to guarantee deterministic behavior.

Could somebody from the kernel team elaborate here? This is obviously
broken and undermines the security and containerization that hw
contexts are supposed to provide. I'm really curious what the thinking
is here...

Kristian

> Apparently, the "Default Value" of registers in the documentation is a
> total lie, and cannot be relied upon by userspace.  So, we need to find
> a new solution.  One would be to patch VA-API and Beignet to initialize
> these, then get every distributor to ship those in tandem with the newer
> Mesa version.  I'm unclear when va-intel-driver releases might happen.
> Another option would be to hack Mesa to restore the register back to the
> historical default (relative mode) at the end of each batch.  This is
> also gross, as it has non-zero cost, and is also relying on userspace to
> be "polite" to other broken userspace.  A large part of the motivation
> for contexts was to provide proper process isolation, so we should not
> have to do this.  But, we're already doing it in some cases, because
> our kernel fixes to enforce isolation were reverted.
>
> In the meantime, I guess we'll just revert this patch and abandon using
> the feature.  It will lead to fewer pushed UBOs on Broadwell+, which may
> lead to lower performance, but I don't have any data on the impact.
>
> Cc: "17.2" 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102774
> ---
>  src/mesa/drivers/dri/i965/brw_state_upload.c | 24 
>  src/mesa/drivers/dri/i965/intel_screen.c |  2 +-
>  2 files changed, 1 insertion(+), 25 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
> b/src/mesa/drivers/dri/i965/brw_state_upload.c
> index 16f44d03bbe..23e4ebda259 100644
> --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
> @@ -101,30 +101,6 @@ brw_upload_initial_gpu_state(struct brw_context *brw)
>OUT_BATCH(0);
>ADVANCE_BATCH();
> }
> -
> -   /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so
> -* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address.
> -*
> -* On Gen6-7.5, we use an execbuf parameter to do this for us.
> -* However, the kernel ignores that when execlists are in use.
> -* Fortunately, we can just write the registers from userspace
> -* on Gen8+, and they're context saved/restored.
> -*/
> -   if (devinfo->gen >= 9) {
> -  BEGIN_BATCH(3);
> -  OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
> -  OUT_BATCH(CS_DEBUG_MODE2);
> -  OUT_BATCH(REG_MASK(CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) |
> -CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE);
> -  ADVANCE_BATCH();
> -   } else if (devinfo->gen == 8) {
> -  BEGIN_BATCH(3);
> -  OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
> -  OUT_BATCH(INSTPM);
> -  OUT_BATCH(REG_MASK(INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) |
> -INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE);
> -  ADVANCE_BATCH();
> -   }
>  }
>
>  static inline const struct brw_tracked_state *
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index ea04a72e860..776c2898d5b 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -2510,7 +2510,7 @@ __DRIconfig **intelInitScreen2(__DRIscreen *dri_screen)
> screen->compiler = brw_compiler_create(screen, devinfo);
> screen->compiler->shader_debug_log = shader_debug_log_mesa;
> screen->compiler->shader_perf_log = shader_perf_log_mesa;
> -   screen->compiler->constant_buffer_0_is_relative = devinfo->gen < 8;
> +   screen->compiler->constant_buffer_0_is_relative = true;
> screen->compiler->supports_pull_constants = true;
>
> screen->has_exec_fence =
> --
> 2.14.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] anv: Implement VK_ANDROID_native_buffer (v9)

[Kristian Høgsberg]

On Mon, Oct 16, 2017 at 11:55 AM, Chad Versace  wrote:
> This implementation is correct (afaict), but takes two shortcuts
> regarding the import/export of Android sync fds.
>
>   Shortcut 1. When Android calls vkAcquireImageANDROID to import a sync
>   fd into a VkSemaphore or VkFence, the driver instead simply blocks on
>   the sync fd, then puts the VkSemaphore or VkFence into the signalled
>   state. Thanks to implicit sync, this produces correct behavior (with
>   extra latency overhead, perhaps) despite its ugliness.
>
>   Shortcut 2. When Android calls vkQueueSignalReleaseImageANDROID to export
>   a collection of wait semaphores as a sync fd, the driver instead
>   submits the semaphores to the queue, then returns sync fd -1, which
>   informs the caller that no additional synchronization is needed.
>   Again, thanks to implicit sync, this produces correct behavior (with
>   extra batch submission overhead) despite its ugliness.
>
> I chose to take the shortcuts instead of properly importing/exporting
> the sync fds for two reasons:
>
>   Reason 1. I've already tested this patch with dEQP and with demos
>   apps. It works. I wanted to get the tested patches into the tree now,
>   and polish the implementation afterwards.
>
>   Reason 2. I want to run this on a 3.18 kernel (gasp!). In 3.18, i915
>   supports neither Android's sync_fence, nor upstream's sync_file, nor
>   drm_syncobj. Again, I tested these patches on Android with a 3.18
>   kernel and they work.
>
> I plan to quickly follow-up with patches that remove the shortcuts and
> properly import/export the sync fds.
>
> Non-Testing
> ===
> I did not test at all using the Android.mk buildsystem. I probably
> broke it. Please test and review that.
>
> Testing
> ===
> I tested with 64-bit ARC++ on a Skylake Chromebook and a 3.18 kernel.
> The following pass (as of patchset v9):
>
>   - a little spinning cube demo APK
>   - several Sascha demos
>   - dEQP-VK.info.*
>   - dEQP-VK.api.wsi.android.*
>   (except dEQP-VK.api.wsi.android.swapchain.*.image_usage, because
>   dEQP wants to create swapchains with VK_IMAGE_USAGE_STORAGE_BIT)
>   - dEQP-VK.api.smoke.*
>   - dEQP-VK.api.info.instance.*
>   - dEQP-VK.api.info.device.*
>
> v2:
>   - Reject VkNativeBufferANDROID if the dma-buf's size is too small for
> the VkImage.
>   - Stop abusing VkNativeBufferANDROID by passing it to vkAllocateMemory
> during vkCreateImage. Instead, directly import its dma-buf during
> vkCreateImage with anv_bo_cache_import(). [for jekstrand]
>   - Rebase onto Tapani's VK_EXT_debug_report changes.
>   - Drop `CPPFLAGS += $(top_srcdir)/include/android`. The dir does not
> exist.
>
> v3:
>   - Delete duplicate #include "anv_private.h". [per Tapani]
>   - Try to fix the Android-IA build in Android.vulkan.mk by following
> Tapani's example.
>
> v4:
>   - Unset EXEC_OBJECT_ASYNC and set EXEC_OBJECT_WRITE on the imported
> gralloc buffer, just as we do for all other winsys buffers in
> anv_wsi.c. [found by Tapani]
>
> v5:
>   - Really fix the Android-IA build by ensuring that Android.vulkan.mk
> uses Mesa' vulkan.h and not Android's.  Insert -I$(MESA_TOP)/include
> before -Iframeworks/native/vulkan/include. [for Tapani]
>   - In vkAcquireImageANDROID, submit signal operations to the
> VkSemaphore and VkFence. [for zhou]
>
> v6:
>   - Drop copy-paste duplication in vkGetSwapchainGrallocUsageANDROID().
> [found by zhou]
>   - Improve comments in vkGetSwapchainGrallocUsageANDROID().
>
> v7:
>   - Fix vkGetSwapchainGrallocUsageANDROID() to inspect its
> VkImageUsageFlags parameter. [for tfiga]
>   - This fix regresses dEQP-VK.api.wsi.android.swapchain.*.image_usage
> because dEQP wants to create swapchains with
> VK_IMAGE_USAGE_STORAGE_BIT.
>
> v8:
>   - Drop unneeded goto in vkAcquireImageANDROID. [for tfiga]
>
> v8.1: (minor changes)
>   - Drop errant hunks added by rerere in anv_device.c.
>   - Drop explicit mention of VK_ANDROID_native_buffer in
> anv_entrypoints_gen.py. [for jekstrand]
>
> v9:
>   - Isolate as much Android code as possible, moving it from anv_image.c
> to anv_android.c. Connect the files with anv_image_from_gralloc().
> Remove VkNativeBufferANDROID params from all anv_image.c
> funcs. [for krh]

Looks great now, very clean.

>   - Replace some intel_loge() with vk_errorf() in anv_android.c.
>   - Use © in copyright line. [for krh]

Last nit-pick: It's "Google, Inc."

With that,

Reviewed-by: Kristian H. Kristensen 

> Reviewed-by: Tapani Pälli  (v5)
> Cc: Jason Ekstrand 
> Cc: zhoucm1 
> Cc: Tomasz Figa 
> Cc: Kristian H. Kristensen 
> ---
>  src/intel/Android.vulkan.mk |   7 +-
>  src/intel/Makefile.sources  |   3 +
>  src/intel/Makefile.vulkan.am|   2 +
>  

Re: [Mesa-dev] Testing out Kristian's fast mtx patch

[Kristian Høgsberg]

On Mon, Oct 9, 2017 at 7:45 PM, Timothy Arceri  wrote:
> After a recent discussion about this code from 2015 I was curious
> to give it a try. The outstanding review item was that we shouldn't
> be replacing the C11 mtx type/functions with our own, so I've renamed
> the fast path to simple_mtx* and added a couple of patches to make use
> of it.
>
> The idea is this fast mtx can be used in place of the full mtx
> implementation when its of type mtx_plain.
>
> I though if anywhere we might see a change in the drawoverhead piglit
> test but I didn't see any real change.
>
> Anyway since I've made the updates I thought I'd send it out. Maybe
> someone else might find some better results. Kristian reported a 10%
> increase in some internal Intel benchmarks, I wonder if thats still the
> case.

Hi Tim, thanks for reviving this. The one case where I saw that big
win was one of Intels internal micro-benchmarks (SynMark). It was
bottlenecking on bind/unbind of various objects and much of the
overhead was in the locking there. Any real world usecase without
excessive bind/unbind probably won't see any improvement.

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

Re: [Mesa-dev] Why are we using server-side GLX fbconfigs?

[Kristian Høgsberg]

On Fri, Jun 30, 2017 at 2:49 AM, Thomas Hellstrom <thellst...@vmware.com> wrote:
> On 06/29/2017 07:30 PM, Kristian Høgsberg wrote:
>>
>> On Thu, Jun 29, 2017 at 7:36 AM, Thomas Hellstrom <thellst...@vmware.com>
>> wrote:
>>>
>>> Hi!
>>>
>>> I was spending some time going through the GLX code to try to fix up the
>>> GLX_OML_swap_method extension implementation.
>>>
>>> I then stumbled across the fact that when we, for direct rendering
>>> connections, construct the list of fbconfigs, we start out with the
>>> server
>>> provided fbconfigs from the AIGLX driver and then try to match each
>>> fbconfig
>>> with a corresponding client driver driconfig. Effectively making us use
>>> the
>>> intersection of the server AIGLX capabilities and the client Direct
>>> rendering capabilities.
>>>
>>> Wouldn't it be more correct, or at least "better" if we, for direct
>>> rendering, took a list of client driver driconfigs, matched each with a
>>> server provided visual and if we have a match, built an fbconfig from
>>> that
>>> driconfig? That would make us essentialy exposing all client driver
>>> capabilities regardless of what the server is using, as long as we have a
>>> matching visual?
>>>
>>> Any insights into this would be greatly appreciated.
>>
>> I'm largely to blame for that. Historically it was part me trying to
>> keep things working they did before as well as having to pay more
>> attention to server side configs as DRI2 tried to share aux buffers
>> (not just color) between clients. I think mesa today only shares color
>> buffers with DRI2 and DRI3 is obviously fine, so what you're proposing
>> sounds like a nice simplification of the code as well as something
>> that might expose more configs to the client.
>>
>> Kristian
>
>
> OK. Thanks Kristian.
>
> FWIW, from what I can tell, dri3 only shares the real front. Has dri2 been
> modified to also allocate local buffers?

No, DRI2 still uses DRI2GetBuffers or DRI2GetBuffersWithFormat to ask
the X server to allocate buffers, which then shares the buffers with
the client by sending the gem name back in the reply.

Kristian

> Thanks,
> Thomas
>
>
>
>
>
>>> Thanks,
>>>
>>> Thomas
>>>
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev=DwIBaQ=uilaK90D4TOVoH58JNXRgQ=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ=ggEEtfO2kSccqTNeC7ze2E2-hHxAbEJifKAeknMDbyY=9vJcxYsmdV4CXmI7ENFECWzNxM_fQwf4ft83ZlKcWuo=
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel: genxml: make a couple of enums show up in aubinator

[Kristian Høgsberg]

On Fri, Jun 30, 2017 at 9:25 AM, Lionel Landwerlin
 wrote:
> In particular Shader Channel Select & Texture Address Control Mode.
>
> Signed-off-by: Lionel Landwerlin 

Nice,

Reviewed-by: Kristian H. Kristensen 

> ---
>  src/intel/genxml/gen10.xml | 14 +++---
>  src/intel/genxml/gen6.xml  |  6 +++---
>  src/intel/genxml/gen7.xml  |  6 +++---
>  src/intel/genxml/gen75.xml | 30 --
>  src/intel/genxml/gen8.xml  | 22 +++---
>  src/intel/genxml/gen9.xml  | 14 +++---
>  6 files changed, 47 insertions(+), 45 deletions(-)
>
> diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml
> index a19674a435f..23c2adb9951 100644
> --- a/src/intel/genxml/gen10.xml
> +++ b/src/intel/genxml/gen10.xml
> @@ -787,10 +787,10 @@
>
>  
>   type="bool"/>
> - type="uint"/>
> - type="uint"/>
> - type="uint"/>
> - type="uint"/>
> + type="Shader Channel Select"/>
> + type="Shader Channel Select"/>
> + type="Shader Channel Select"/>
> + type="Shader Channel Select"/>
>  
>  
>  
> @@ -936,9 +936,9 @@
>  
>   type="bool"/>
>  
> - type="uint"/>
> -
> -
> + type="Texture Coordinate Mode"/>
> + type="Texture Coordinate Mode"/>
> +
>
>
>
> diff --git a/src/intel/genxml/gen6.xml b/src/intel/genxml/gen6.xml
> index 04986bef0d1..8aa03355055 100644
> --- a/src/intel/genxml/gen6.xml
> +++ b/src/intel/genxml/gen6.xml
> @@ -684,9 +684,9 @@
>
>
>  
> -
> -
> -
> +
> +
> +
>  
>   type="uint"/>
>  
> diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
> index 2c297f3b95b..993d10264fa 100644
> --- a/src/intel/genxml/gen7.xml
> +++ b/src/intel/genxml/gen7.xml
> @@ -784,9 +784,9 @@
>
>  
>   type="bool"/>
> - type="uint"/>
> -
> -
> + type="Texture Coordinate Mode"/>
> + type="Texture Coordinate Mode"/>
> +
>
>
>
> diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
> index e7c06dc5819..105effa8cef 100644
> --- a/src/intel/genxml/gen75.xml
> +++ b/src/intel/genxml/gen75.xml
> @@ -362,6 +362,15 @@
>  
>
>
> +  
> +
> +
> +
> +
> +
> +
> +  
> +
>
>  
>  
> @@ -691,17 +700,10 @@
>  
>  
>  
> - type="uint">
> -  
> -  
> -  
> -  
> -  
> -  
> -
> - type="uint"/>
> - type="uint"/>
> - type="uint"/>
> + type="Shader Channel Select"/>
> + type="Shader Channel Select"/>
> + type="Shader Channel Select"/>
> + type="Shader Channel Select"/>
>  
>
>
> @@ -805,9 +807,9 @@
>
>  
>   type="bool"/>
> - type="uint"/>
> -
> -
> + type="Texture Coordinate Mode"/>
> + type="Texture Coordinate Mode"/>
> +
>
>
>
> diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
> index 2fd796a2e24..99c4aca8fb4 100644
> --- a/src/intel/genxml/gen8.xml
> +++ b/src/intel/genxml/gen8.xml
> @@ -732,14 +732,14 @@
>   type="bool"/>
>   type="uint"/>
>   type="uint"/>
> -
> -
> -
> -
> - type="uint"/>
> - type="uint"/>
> - type="uint"/>
> - type="uint"/>
> +
> +
> +
> +
> + type="Shader Channel Select"/>
> + type="Shader Channel Select"/>
> + type="Shader Channel Select"/>
> + type="Shader Channel Select"/>
>  
>  
>  
> @@ -847,9 +847,9 @@
>
>  
>   type="bool"/>
> - type="uint"/>
> -
> -
> + type="Texture Coordinate Mode"/>
> + type="Texture Coordinate Mode"/>
> +
>
>
>
> diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
> index af40e660771..1422463693d 100644
> --- a/src/intel/genxml/gen9.xml
> +++ b/src/intel/genxml/gen9.xml
> @@ -780,10 +780,10 @@
>
>  
>   type="bool"/>
> - type="uint"/>
> - type="uint"/>
> - type="uint"/>
> - type="uint"/>
> + type="Shader Channel Select"/>
> + type="Shader Channel Select"/>
> + type="Shader Channel Select"/>
> + type="Shader Channel Select"/>
>  
>  
>  
> @@ -905,9 +905,9 @@
>  
>   type="bool"/>
>  
> - type="uint"/>
> -
> -
> + type="Texture Coordinate Mode"/>
> + type="Texture Coordinate Mode"/>
> +
>
>
>
> --
> 2.13.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] Why are we using server-side GLX fbconfigs?

[Kristian Høgsberg]

On Thu, Jun 29, 2017 at 7:36 AM, Thomas Hellstrom  wrote:
> Hi!
>
> I was spending some time going through the GLX code to try to fix up the
> GLX_OML_swap_method extension implementation.
>
> I then stumbled across the fact that when we, for direct rendering
> connections, construct the list of fbconfigs, we start out with the server
> provided fbconfigs from the AIGLX driver and then try to match each fbconfig
> with a corresponding client driver driconfig. Effectively making us use the
> intersection of the server AIGLX capabilities and the client Direct
> rendering capabilities.
>
> Wouldn't it be more correct, or at least "better" if we, for direct
> rendering, took a list of client driver driconfigs, matched each with a
> server provided visual and if we have a match, built an fbconfig from that
> driconfig? That would make us essentialy exposing all client driver
> capabilities regardless of what the server is using, as long as we have a
> matching visual?
>
> Any insights into this would be greatly appreciated.

I'm largely to blame for that. Historically it was part me trying to
keep things working they did before as well as having to pay more
attention to server side configs as DRI2 tried to share aux buffers
(not just color) between clients. I think mesa today only shares color
buffers with DRI2 and DRI3 is obviously fine, so what you're proposing
sounds like a nice simplification of the code as well as something
that might expose more configs to the client.

Kristian

> Thanks,
>
> Thomas
>
>
> ___
> 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] i965: Remove spurious mutex frobbing around call to intel_miptree_blit

[Kristian Høgsberg]

On Mon, Jun 19, 2017 at 2:33 PM, Ian Romanick <i...@freedesktop.org> wrote:
> From: Ian Romanick <ian.d.roman...@intel.com>
>
> These locks were added in 2f28a0dc, but I don't see anything in the
> intel_miptree_blit path that should make this necessary.

I doubt it's needed now with the new blorp. If I remember correctly, I
had to drop the lock there since intel_miptree_blit() could hit the XY
blit path that requires a fast clear resolve. The fast resolve being
meta, would then try to lock the texture again.

Kristian

> Signed-off-by: Ian Romanick <ian.d.roman...@intel.com>
> Cc: Kristian Høgsberg <k...@bitplanet.net>
> ---
>  src/mesa/drivers/dri/i965/intel_tex_copy.c | 19 ++-
>  1 file changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_tex_copy.c 
> b/src/mesa/drivers/dri/i965/intel_tex_copy.c
> index 9c255ae..e0d5cad 100644
> --- a/src/mesa/drivers/dri/i965/intel_tex_copy.c
> +++ b/src/mesa/drivers/dri/i965/intel_tex_copy.c
> @@ -51,7 +51,6 @@ intel_copy_texsubimage(struct brw_context *brw,
> GLint x, GLint y, GLsizei width, GLsizei height)
>  {
> const GLenum internalFormat = intelImage->base.Base.InternalFormat;
> -   bool ret;
>
> /* No pixel transfer operations (zoom, bias, mapping), just a blit */
> if (brw->ctx._ImageTransferState)
> @@ -83,19 +82,13 @@ intel_copy_texsubimage(struct brw_context *brw,
> int dst_slice = slice + intelImage->base.Base.Face +
> intelImage->base.Base.TexObject->MinLayer;
>
> -   _mesa_unlock_texture(>ctx, intelImage->base.Base.TexObject);
> -
> /* blit from src buffer to texture */
> -   ret = intel_miptree_blit(brw,
> -irb->mt, irb->mt_level, irb->mt_layer,
> -x, y, irb->Base.Base.Name == 0,
> -intelImage->mt, dst_level, dst_slice,
> -dstx, dsty, false,
> -width, height, GL_COPY);
> -
> -   _mesa_lock_texture(>ctx, intelImage->base.Base.TexObject);
> -
> -   return ret;
> +   return intel_miptree_blit(brw,
> + irb->mt, irb->mt_level, irb->mt_layer,
> + x, y, irb->Base.Base.Name == 0,
> + intelImage->mt, dst_level, dst_slice,
> + dstx, dsty, false,
> + width, height, GL_COPY);
>  }
>
>
> --
> 2.9.4
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/3] nir: Add a lowering pass for UYVY textures

[Kristian Høgsberg]

On Mon, Jun 19, 2017 at 7:07 PM, Lin, Johnson  wrote:
> Kristian,
>
> Thanks for the review comments. By my tests, UYVY buffer can be sampled and 
> rendered correctly. So there is no swap of U/V channel here.

Just saying "the test pass, all is fine" isn't good enough. See below.

>
> -Original Message-
> From: Lin, Johnson
> Sent: Tuesday, June 20, 2017 9:43 AM
> To: mesa-dev@lists.freedesktop.org
> Cc: Lin, Johnson 
> Subject: [PATCH v2 2/3] nir: Add a lowering pass for UYVY textures
>
> Similar with support for YUYV but with byte order difference in sampler
> ---
>  src/compiler/nir/nir.h   |  1 +
>  src/compiler/nir/nir_lower_tex.c | 16 
>  2 files changed, 17 insertions(+)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h index 
> ab7ba14303b7..1b4e47058d4d 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -2449,6 +2449,7 @@ typedef struct nir_lower_tex_options {
> unsigned lower_y_uv_external;
> unsigned lower_y_u_v_external;
> unsigned lower_yx_xuxv_external;
> +   unsigned lower_xy_uxvx_external;
>
> /**
>  * To emulate certain texture wrap modes, this can be used diff --git 
> a/src/compiler/nir/nir_lower_tex.c b/src/compiler/nir/nir_lower_tex.c
> index 4ef81955513e..5593f9890b28 100644
> --- a/src/compiler/nir/nir_lower_tex.c
> +++ b/src/compiler/nir/nir_lower_tex.c
> @@ -301,6 +301,18 @@ lower_yx_xuxv_external(nir_builder *b, nir_tex_instr 
> *tex)
>nir_channel(b, xuxv, 3));  }
>
> +static void lower_xy_uxvx_external(nir_builder *b, nir_tex_instr *tex)
> +{
> +  b->cursor = nir_after_instr(>instr);
> +
> +  nir_ssa_def *y = sample_plane(b, tex, 0);  nir_ssa_def *uxvx =
> + sample_plane(b, tex, 1);
> +
> +  convert_yuv_to_rgb(b, tex,
> + nir_channel(b, y, 1),
> + nir_channel(b, uxvx, 2),
> + nir_channel(b, uxvx, 0)); }

Let's look at convert_yuv_to_rgb:

static void
convert_yuv_to_rgb(nir_builder *b, nir_tex_instr *tex,
   nir_ssa_def *y, nir_ssa_def *u, nir_ssa_def *v)

Notice how it takes the channels in y, u and v order. But you're
passing in y, then nir_channel(b, uxvx, 2), which extracts the second
channels, which is v and then nir_channel(b, uxvx, 0) which is u. If
the tests pass you probably have another swap somewhere else in the
patch that cancels out this problem. You need to fix this.

Kristian

> +
>  /*
>   * Emits a textureLod operation used to replace an existing
>   * textureGrad instruction.
> @@ -760,6 +772,10 @@ nir_lower_tex_block(nir_block *block, nir_builder *b,
>   progress = true;
>}
>
> +  if ((1 << tex->texture_index) & options->lower_xy_uxvx_external) {
> + lower_xy_uxvx_external(b, tex);
> + progress = true;
> +  }
>
>if (sat_mask) {
>   saturate_src(b, tex, sat_mask);
> --
> 1.9.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 18/18] i965: Convert WM_STATE to genxml on gen4-5.

[Kristian Høgsberg]

On Mon, Jun 19, 2017 at 11:17 AM, Rafael Antognolli
<rafael.antogno...@intel.com> wrote:
> On Mon, Jun 19, 2017 at 09:46:30AM -0700, Kristian Høgsberg wrote:
>> On Fri, Jun 16, 2017 at 4:31 PM, Rafael Antognolli
>> <rafael.antogno...@intel.com> wrote:
>> > The code doesn't get exactly a lot simpler but at least it is in a single
>> > place, and we delete more than we add.
>>
>> Another good point is that you get rid of struct brw_wm_unit_state
>> which was a third mechanism for encoding GEN state. We used to have
>> GENXML, manual packing and these bitfield structs. Now we're down to
>> just GENXML and some manual packing.
>
> Nice, I think I can add this to the commit message if you don't mind :)

Please do, that's why I brought it up ;-)

>> Kristian
>>
>> >
>> > Signed-off-by: Rafael Antognolli <rafael.antogno...@intel.com>
>> > ---
>> >  src/mesa/drivers/dri/i965/Makefile.sources|   1 -
>> >  src/mesa/drivers/dri/i965/brw_state.h |   1 -
>> >  src/mesa/drivers/dri/i965/brw_structs.h   | 121 
>> >  src/mesa/drivers/dri/i965/brw_wm.h|   2 -
>> >  src/mesa/drivers/dri/i965/brw_wm_state.c  | 274 
>> > --
>> >  src/mesa/drivers/dri/i965/genX_state_upload.c | 191 ++
>> >  6 files changed, 153 insertions(+), 437 deletions(-)
>> >  delete mode 100644 src/mesa/drivers/dri/i965/brw_wm_state.c
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
>> > b/src/mesa/drivers/dri/i965/Makefile.sources
>> > index 89be92e..c15b3ef 100644
>> > --- a/src/mesa/drivers/dri/i965/Makefile.sources
>> > +++ b/src/mesa/drivers/dri/i965/Makefile.sources
>> > @@ -61,7 +61,6 @@ i965_FILES = \
>> > brw_vs_surface_state.c \
>> > brw_wm.c \
>> > brw_wm.h \
>> > -   brw_wm_state.c \
>> > brw_wm_surface_state.c \
>> > gen4_blorp_exec.h \
>> > gen6_clip_state.c \
>> > diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
>> > b/src/mesa/drivers/dri/i965/brw_state.h
>> > index 8f3bd7f..9588a51 100644
>> > --- a/src/mesa/drivers/dri/i965/brw_state.h
>> > +++ b/src/mesa/drivers/dri/i965/brw_state.h
>> > @@ -89,7 +89,6 @@ extern const struct brw_tracked_state 
>> > brw_wm_image_surfaces;
>> >  extern const struct brw_tracked_state brw_cs_ubo_surfaces;
>> >  extern const struct brw_tracked_state brw_cs_abo_surfaces;
>> >  extern const struct brw_tracked_state brw_cs_image_surfaces;
>> > -extern const struct brw_tracked_state brw_wm_unit;
>> >
>> >  extern const struct brw_tracked_state brw_psp_urb_cbs;
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/brw_structs.h 
>> > b/src/mesa/drivers/dri/i965/brw_structs.h
>> > index 5a0d91d..fb592be 100644
>> > --- a/src/mesa/drivers/dri/i965/brw_structs.h
>> > +++ b/src/mesa/drivers/dri/i965/brw_structs.h
>> > @@ -65,127 +65,6 @@ struct brw_urb_fence
>> > } bits1;
>> >  };
>> >
>> > -/* State structs for the various fixed function units:
>> > - */
>> > -
>> > -
>> > -struct thread0
>> > -{
>> > -   unsigned pad0:1;
>> > -   unsigned grf_reg_count:3;
>> > -   unsigned pad1:2;
>> > -   unsigned kernel_start_pointer:26; /* Offset from GENERAL_STATE_BASE */
>> > -};
>> > -
>> > -struct thread1
>> > -{
>> > -   unsigned ext_halt_exception_enable:1;
>> > -   unsigned sw_exception_enable:1;
>> > -   unsigned mask_stack_exception_enable:1;
>> > -   unsigned timeout_exception_enable:1;
>> > -   unsigned illegal_op_exception_enable:1;
>> > -   unsigned pad0:3;
>> > -   unsigned depth_coef_urb_read_offset:6;  /* WM only */
>> > -   unsigned pad1:2;
>> > -   unsigned floating_point_mode:1;
>> > -   unsigned thread_priority:1;
>> > -   unsigned binding_table_entry_count:8;
>> > -   unsigned pad3:5;
>> > -   unsigned single_program_flow:1;
>> > -};
>> > -
>> > -struct thread2
>> > -{
>> > -   unsigned per_thread_scratch_space:4;
>> > -   unsigned pad0:6;
>> > -   unsigned scratch_space_base_pointer:22;
>> > -};
>> > -
>> > -
>> > -struct thread3
>> > -{
>> > -   unsigned dispatch_grf_start_reg:4;
>> > -   unsigned urb_entry_read_offset:6;
>> > -   unsigned pad0

Re: [Mesa-dev] [PATCH 18/18] i965: Convert WM_STATE to genxml on gen4-5.

[Kristian Høgsberg]

On Fri, Jun 16, 2017 at 4:31 PM, Rafael Antognolli
 wrote:
> The code doesn't get exactly a lot simpler but at least it is in a single
> place, and we delete more than we add.

Another good point is that you get rid of struct brw_wm_unit_state
which was a third mechanism for encoding GEN state. We used to have
GENXML, manual packing and these bitfield structs. Now we're down to
just GENXML and some manual packing.

Kristian

>
> Signed-off-by: Rafael Antognolli 
> ---
>  src/mesa/drivers/dri/i965/Makefile.sources|   1 -
>  src/mesa/drivers/dri/i965/brw_state.h |   1 -
>  src/mesa/drivers/dri/i965/brw_structs.h   | 121 
>  src/mesa/drivers/dri/i965/brw_wm.h|   2 -
>  src/mesa/drivers/dri/i965/brw_wm_state.c  | 274 
> --
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 191 ++
>  6 files changed, 153 insertions(+), 437 deletions(-)
>  delete mode 100644 src/mesa/drivers/dri/i965/brw_wm_state.c
>
> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
> b/src/mesa/drivers/dri/i965/Makefile.sources
> index 89be92e..c15b3ef 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.sources
> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> @@ -61,7 +61,6 @@ i965_FILES = \
> brw_vs_surface_state.c \
> brw_wm.c \
> brw_wm.h \
> -   brw_wm_state.c \
> brw_wm_surface_state.c \
> gen4_blorp_exec.h \
> gen6_clip_state.c \
> diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
> b/src/mesa/drivers/dri/i965/brw_state.h
> index 8f3bd7f..9588a51 100644
> --- a/src/mesa/drivers/dri/i965/brw_state.h
> +++ b/src/mesa/drivers/dri/i965/brw_state.h
> @@ -89,7 +89,6 @@ extern const struct brw_tracked_state brw_wm_image_surfaces;
>  extern const struct brw_tracked_state brw_cs_ubo_surfaces;
>  extern const struct brw_tracked_state brw_cs_abo_surfaces;
>  extern const struct brw_tracked_state brw_cs_image_surfaces;
> -extern const struct brw_tracked_state brw_wm_unit;
>
>  extern const struct brw_tracked_state brw_psp_urb_cbs;
>
> diff --git a/src/mesa/drivers/dri/i965/brw_structs.h 
> b/src/mesa/drivers/dri/i965/brw_structs.h
> index 5a0d91d..fb592be 100644
> --- a/src/mesa/drivers/dri/i965/brw_structs.h
> +++ b/src/mesa/drivers/dri/i965/brw_structs.h
> @@ -65,127 +65,6 @@ struct brw_urb_fence
> } bits1;
>  };
>
> -/* State structs for the various fixed function units:
> - */
> -
> -
> -struct thread0
> -{
> -   unsigned pad0:1;
> -   unsigned grf_reg_count:3;
> -   unsigned pad1:2;
> -   unsigned kernel_start_pointer:26; /* Offset from GENERAL_STATE_BASE */
> -};
> -
> -struct thread1
> -{
> -   unsigned ext_halt_exception_enable:1;
> -   unsigned sw_exception_enable:1;
> -   unsigned mask_stack_exception_enable:1;
> -   unsigned timeout_exception_enable:1;
> -   unsigned illegal_op_exception_enable:1;
> -   unsigned pad0:3;
> -   unsigned depth_coef_urb_read_offset:6;  /* WM only */
> -   unsigned pad1:2;
> -   unsigned floating_point_mode:1;
> -   unsigned thread_priority:1;
> -   unsigned binding_table_entry_count:8;
> -   unsigned pad3:5;
> -   unsigned single_program_flow:1;
> -};
> -
> -struct thread2
> -{
> -   unsigned per_thread_scratch_space:4;
> -   unsigned pad0:6;
> -   unsigned scratch_space_base_pointer:22;
> -};
> -
> -
> -struct thread3
> -{
> -   unsigned dispatch_grf_start_reg:4;
> -   unsigned urb_entry_read_offset:6;
> -   unsigned pad0:1;
> -   unsigned urb_entry_read_length:6;
> -   unsigned pad1:1;
> -   unsigned const_urb_entry_read_offset:6;
> -   unsigned pad2:1;
> -   unsigned const_urb_entry_read_length:6;
> -   unsigned pad3:1;
> -};
> -
> -struct brw_wm_unit_state
> -{
> -   struct thread0 thread0;
> -   struct thread1 thread1;
> -   struct thread2 thread2;
> -   struct thread3 thread3;
> -
> -   struct {
> -  unsigned stats_enable:1;
> -  unsigned depth_buffer_clear:1;
> -  unsigned sampler_count:3;
> -  unsigned sampler_state_pointer:27;
> -   } wm4;
> -
> -   struct
> -   {
> -  unsigned enable_8_pix:1;
> -  unsigned enable_16_pix:1;
> -  unsigned enable_32_pix:1;
> -  unsigned enable_con_32_pix:1;
> -  unsigned enable_con_64_pix:1;
> -  unsigned pad0:1;
> -
> -  /* These next four bits are for Ironlake+ */
> -  unsigned fast_span_coverage_enable:1;
> -  unsigned depth_buffer_clear:1;
> -  unsigned depth_buffer_resolve_enable:1;
> -  unsigned hierarchical_depth_buffer_resolve_enable:1;
> -
> -  unsigned legacy_global_depth_bias:1;
> -  unsigned line_stipple:1;
> -  unsigned depth_offset:1;
> -  unsigned polygon_stipple:1;
> -  unsigned line_aa_region_width:2;
> -  unsigned line_endcap_aa_region_width:2;
> -  unsigned early_depth_test:1;
> -  unsigned thread_dispatch_enable:1;
> -  unsigned program_uses_depth:1;
> -  unsigned program_computes_depth:1;
> -  unsigned program_uses_killpixel:1;
> - 

Re: [Mesa-dev] [PATCH 11/11] intel/aubinator_error_decode: Disassemble shader programs

[Kristian Høgsberg]

On Mon, May 1, 2017 at 1:54 PM, Matt Turner  wrote:
> ---
>  src/intel/Makefile.tools.am  |   6 +-
>  src/intel/tools/aubinator_error_decode.c | 178 
> ++-
>  2 files changed, 180 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/Makefile.tools.am b/src/intel/Makefile.tools.am
> index 576beea..1175118 100644
> --- a/src/intel/Makefile.tools.am
> +++ b/src/intel/Makefile.tools.am
> @@ -47,11 +47,15 @@ tools_aubinator_LDADD = \
>
>
>  tools_aubinator_error_decode_SOURCES = \
> -   tools/aubinator_error_decode.c
> +   tools/aubinator_error_decode.c \
> +   tools/disasm.c \
> +   tools/gen_disasm.h
>
>  tools_aubinator_error_decode_LDADD = \
> common/libintel_common.la \
> +   compiler/libintel_compiler.la \
> $(top_builddir)/src/util/libmesautil.la \
> +   $(PTHREAD_LIBS) \
> $(EXPAT_LIBS) \
> $(ZLIB_LIBS)
>
> diff --git a/src/intel/tools/aubinator_error_decode.c 
> b/src/intel/tools/aubinator_error_decode.c
> index 244bef8..ef77c01 100644
> --- a/src/intel/tools/aubinator_error_decode.c
> +++ b/src/intel/tools/aubinator_error_decode.c
> @@ -40,6 +40,7 @@
>
>  #include "common/gen_decoder.h"
>  #include "util/macros.h"
> +#include "gen_disasm.h"
>
>  #define CSI "\e["
>  #define BLUE_HEADER  CSI "0;44m"
> @@ -209,6 +210,17 @@ print_fault_data(struct gen_device_info *devinfo, 
> uint32_t data1, uint32_t data0
>  #define CSI "\e["
>  #define NORMAL   CSI "0m"
>
> +struct program {
> +   const char *type;
> +   const char *command;
> +   uint64_t command_offset;
> +   uint64_t instruction_base_address;
> +   uint64_t ksp;
> +};
> +
> +static struct program programs[4096];
> +static int num_programs = 0;
> +
>  static void decode(struct gen_spec *spec,
> const char *buffer_name,
> const char *ring_name,
> @@ -219,6 +231,7 @@ static void decode(struct gen_spec *spec,
> uint32_t *p, *end = (data + *count);
> int length;
> struct gen_group *inst;
> +   uint64_t current_instruction_base_address = 0;
>
> for (p = data; p < end; p += length) {
>const char *color = option_full_decode ? BLUE_HEADER : NORMAL,
> @@ -246,6 +259,127 @@ static void decode(struct gen_spec *spec,
>
>if (strcmp(inst->name, "MI_BATCH_BUFFER_END") == 0)
>   break;
> +
> +  if (strcmp(inst->name, "STATE_BASE_ADDRESS") == 0) {
> + struct gen_field_iterator iter;
> + gen_field_iterator_init(, inst, p, false);
> +
> + while (gen_field_iterator_next()) {
> +if (strcmp(iter.name, "Instruction Base Address") == 0) {
> +   current_instruction_base_address = strtol(iter.value, NULL, 
> 16);
> +}
> + }
> +  } else if (strcmp(inst->name,   "WM_STATE") == 0 ||
> + strcmp(inst->name, "3DSTATE_PS") == 0 ||
> + strcmp(inst->name, "3DSTATE_WM") == 0) {
> + struct gen_field_iterator iter;
> + gen_field_iterator_init(, inst, p, false);
> + uint64_t ksp[3] = {0, 0, 0};
> + bool enabled[3] = {false, false, false};
> +
> + while (gen_field_iterator_next()) {
> +if (strncmp(iter.name, "Kernel Start Pointer ",
> +strlen("Kernel Start Pointer ")) == 0) {
> +   int idx = iter.name[strlen("Kernel Start Pointer ")] - '0';
> +   ksp[idx] = strtol(iter.value, NULL, 16);
> +} else if (strcmp(iter.name, "8 Pixel Dispatch Enable") == 0) {
> +   enabled[0] = strcmp(iter.value, "true") == 0;
> +} else if (strcmp(iter.name, "16 Pixel Dispatch Enable") == 0) {
> +   enabled[1] = strcmp(iter.value, "true") == 0;
> +} else if (strcmp(iter.name, "32 Pixel Dispatch Enable") == 0) {
> +   enabled[2] = strcmp(iter.value, "true") == 0;
> +}
> + }

Just a reminder that this exists:
https://lists.freedesktop.org/archives/mesa-dev/2016-November/136881.html

Of course, it's not a great fit here, since that generates per-gen
structs and decode functions and this code here is not gen specific.

Kristian

> +
> + /* FINISHME: Broken for multi-program WM_STATE,
> +  * which Mesa does not use
> +  */
> + if (enabled[0] + enabled[1] + enabled[2] == 1) {
> +const char *type = enabled[0] ? "SIMD8 fragment shader" :
> +   enabled[1] ? "SIMD16 fragment shader" :
> +   enabled[2] ? "SIMD32 fragment shader" : NULL;
> +
> +programs[num_programs++] = (struct program) {
> +   .type = type,
> +   .command = inst->name,
> +   .command_offset = offset,
> +   .instruction_base_address = current_instruction_base_address,
> +   .ksp = ksp[0],
> +};
> + } else {
> +if (enabled[0]) /* SIMD8 */ {
> +   

Re: [Mesa-dev] [PATCH] i965: Drop brw_context::viewport_transform_enable.

[Kristian Høgsberg]

Reviewed-by: Kristian H. Kristensen 

On Wed, May 10, 2017 at 12:01 PM, Kenneth Graunke  wrote:
> This was used by the meta fast clear code.  Now that we've switched
> back to BLORP, it's always true.
>
> We might want it back when we add a RECTLIST extension to GL, but
> that's someday in the future...
> ---
>  src/mesa/drivers/dri/i965/brw_context.c   | 1 -
>  src/mesa/drivers/dri/i965/brw_context.h   | 1 -
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
>  3 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 1247d0355f6..5055dd76a84 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -1126,7 +1126,6 @@ brwCreateContext(gl_api api,
> brw->prim_restart.in_progress = false;
> brw->prim_restart.enable_cut_index = false;
> brw->gs.enabled = false;
> -   brw->sf.viewport_transform_enable = true;
> brw->clip.viewport_count = 1;
>
> brw->predicate.state = BRW_PREDICATE_STATE_RENDER;
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 100bd74f214..1fac63225f8 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -1061,7 +1061,6 @@ struct brw_context
>uint32_t prog_offset;
>uint32_t state_offset;
>uint32_t vp_offset;
> -  bool viewport_transform_enable;
> } sf;
>
> struct {
> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> index b949d5b448d..bc7f068d5bb 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -1345,7 +1345,7 @@ genX(upload_sf)(struct brw_context *brw)
>
> brw_batch_emit(brw, GENX(3DSTATE_SF), sf) {
>sf.StatisticsEnable = true;
> -  sf.ViewportTransformEnable = brw->sf.viewport_transform_enable;
> +  sf.ViewportTransformEnable = true;
>
>  #if GEN_GEN == 7
>/* _NEW_BUFFERS */
> --
> 2.12.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 0/2] anv/i965: drop libdrm dependency completely

[Kristian Høgsberg]

On Thu, May 4, 2017 at 11:43 AM, Lionel Landwerlin
 wrote:
> On 04/05/17 07:52, Emil Velikov wrote:
>>
>> On 4 May 2017 at 14:46, Daniel Vetter  wrote:
>>>
>>> On Thu, Apr 27, 2017 at 10:58:42AM -0700, Lionel Landwerlin wrote:

 On 27/04/17 08:20, Eric Anholt wrote:
>
> Emil Velikov  writes:
>
>> On 25 April 2017 at 23:56, Lionel Landwerlin
>>  wrote:
>>>
>>> Hi,
>>>
>>> While working with changes that span from kernel to user space, I've
>>> been wondering whether we need to depend on libdrm at all for the anv
>>> & i965 drivers. Indeed with Ken's recent changes, we only depend on
>>> libdrm for its kernel header files which we could just embed
>>> ourselves.
>>>
>>> I've only included the minimal set of header files we need from the
>>> kernel for anv & i965. Maybe other drivers would be interested and
>>> maybe we should put all the kernel drm uapi headers into include?
>>>
>> AFAICT the goal behind the libdrm_intel fold was to allow rapid and
>> seamless rework of the interface.
>> With a potential goal to make it a shared one, as it gets stabilised.
>>
>> Currently ANV uses more than just the UAPI headers. But if we ignore
>> that, coping them is a bad idea.

 What else is anv using from libdrm? (maybe I missed something)

>> Lionel, I stand corrected, we have instances in anv, wsi/x11, loader
>> and dri/i965 (the dri/common ones are just comments).
>> In total they seem to be over three dozen instances. Experiment with
>> the following:
>>
>> for i in `nm -CD --defined-only /lib/libdrm.so | cut -c 20-| grep -v
>> "^_" `; do git grep -w --name-only $i -- src ; done
>
>
> Thanks for the code snippet.
>
> For anv :
> drmGetDevices2

anv was designed to not rely on libdrm or libdrm_intel. I see the
commit that added the libdrm dependency is from you and was not
Reviewed or acked by Jason or any other core anv developer. I suggest
we revert that, I don't see anything in the drmGetDevices2 code that
is better suited for anv than what was there before.

Kristian

> For i965 :
> drmCommandNone
> drmCommandWriteRead
> drmIoctl
> drmPrimeFDToHandle
> drmPrimeHandleToFD
>
> You're right, I'll update the patch to just drop libdrm_intel.
>
>>
>> Why - adds a, yet another, copy and making synchronisation more
>> annoying. First example - you blindly copied the files rather than
>> using `make headers_install' first ;-)
>> Not to mention that it makes the chicken and egg problem* even more
>> confusing and error prone.

 It doesn't feel like that to me. Actually instead of modifying 3
 different
 repos, you end up modifying just 2.
 Sounds less error prone.

>> Lionel, are you saying that we can ignore IGT? Or you're suggesting
>> that IGT should depend on Mesa copy of the headers?
>
>
> If you look closely at IGT, you'll notice quite a few tests actually define
> their own version of the structures/ioctl of the various driver interfaces.
> So it's more or less already happening.
>
> git grep DRM_IO ./tests/ | grep define
> git grep local_drm
>
>
>> Seriously, your argument of "let's import because we can" is iffy. Why
>> stop with the DRM UAPI - let's import headers from glibc ;-)
>
>
> I think you have to look at what we're doing here. i965 & anv are graphics
> drivers tightly coupled with the kernel driver.
> libdrm_intel isn't, it's mostly generic enough code that is shared across
> some of our drivers.
> And since we drop that dependency, why bother with it at all?
>
> We don't really have the same relationship to other components (like glibc).
>
>>
>> If pulling new libdrm is that much of a nuisance to your workflow -
>> just copy the blob we have for the Travis instance.
>> It automatically tracks the libdrm version, builds and installs it as
>> needed.
>
>
> It's not about pulling, it's about maintaining.
>
>>
>> Emil
>> *  Which patches land first - kernel or userspace
>
> I don't see how it does that at all.  It simplifies the process: Now
> you
> send out your proposed new userspace to one repo, instead of two.
>
> And, after the first commit, it'll be obvious when you screw up using
> make headers_install because there will be surprising diff.

 Right now we have to update libdrm, then update the mesa to depend on
 the
 right libdrm to actually get the header files we want.
 If you depend on libdrm from more than just uapi headers, it might now
 be
 too much of a burden. But it seems we're clearly moving away from that
 in
 anv/i965.
 As a developer it feels a lot easier to have just the update mesa with
 both
 the new kernel API you depend on & the changes to the user space driver
 using that API.
>>>
>>> As long as the headers are 

Re: [Mesa-dev] [PATCH 0/2] anv/i965: drop libdrm dependency completely

[Kristian Høgsberg]

On Thu, May 4, 2017 at 7:26 AM, Emil Velikov  wrote:
> On 27 April 2017 at 16:20, Eric Anholt  wrote:
>> Emil Velikov  writes:
>>
>>> On 25 April 2017 at 23:56, Lionel Landwerlin
>>>  wrote:
 Hi,

 While working with changes that span from kernel to user space, I've
 been wondering whether we need to depend on libdrm at all for the anv
 & i965 drivers. Indeed with Ken's recent changes, we only depend on
 libdrm for its kernel header files which we could just embed
 ourselves.

 I've only included the minimal set of header files we need from the
 kernel for anv & i965. Maybe other drivers would be interested and
 maybe we should put all the kernel drm uapi headers into include?

>>> AFAICT the goal behind the libdrm_intel fold was to allow rapid and
>>> seamless rework of the interface.
>>> With a potential goal to make it a shared one, as it gets stabilised.
>>>
>>> Currently ANV uses more than just the UAPI headers. But if we ignore
>>> that, coping them is a bad idea.
>>>
>>> Why - adds a, yet another, copy and making synchronisation more
>>> annoying. First example - you blindly copied the files rather than
>>> using `make headers_install' first ;-)
>>> Not to mention that it makes the chicken and egg problem* even more
>>> confusing and error prone.
>>>
>>> Emil
>>> *  Which patches land first - kernel or userspace
>>
>> I don't see how it does that at all.  It simplifies the process: Now you
>> send out your proposed new userspace to one repo, instead of two.
>>
> Funny that you should say that. On my count there's 4 instances of the
> VC4 headers - one in kernel and 3 in different userspace components.
> With each one subtly different from the rest.

You're making this seem a lot worse than it is. It's not like these
header files are actively developed in 4 different projects. There's
exactly one canonical source for these headers with a well established
development process: the kernel. The fact that the headers are
different just means that the various userspace components have copied
the kernel headers at different times as they implemented new features
on different schedules. I'm sure you understand this.

I think it's pretty simple: requiring i965 or anv to link to libdrm
just for the ioctl wrapper and the header file which comes from the
kernel makes little sense.

Kristian

> Now consider what will happen if you throw a dozen+ developers.
>
>> And, after the first commit, it'll be obvious when you screw up using
>> make headers_install because there will be surprising diff.
>
> People rarely look at these. Bu even ignoring that for a moment:
> Developers simply don't reference (hint hint [1]) the kernel commit
> thus it's impossible to verify the patch.
>
> -Emil
> [1] See your libdrm commits 2212a6465d1597fbc4d4ee0ea5ff87816bfa336e
> and 2212a6465d1597fbc4d4ee0ea5ff87816bfa336e
> ___
> 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 00/53] i965: Eat libdrm_intel for breakfast

[Kristian Høgsberg]

On Wed, Apr 5, 2017 at 11:11 AM, Jason Ekstrand  wrote:
> On Wed, Apr 5, 2017 at 11:03 AM, Emil Velikov 
> wrote:
>>
>> On 5 April 2017 at 18:55, Daniel Vetter  wrote:
>> > On Wed, Apr 05, 2017 at 04:38:25PM +0100, Emil Velikov wrote:
>> >> Hi Ken,
>> >>
>> >> On 5 April 2017 at 01:09, Kenneth Graunke 
>> >> wrote:
>> >> > Hello,
>> >> >
>> >> > This series imports libdrm_intel into the i965 driver, hacks and
>> >> > slashes it down to size, and greatly simplifies our relocation
>> >> > handling.
>> >> >
>> >> > Some of the patches may be held for moderation.  You can find the
>> >> > series in git here:
>> >> >
>> >> > https://cgit.freedesktop.org/~kwg/mesa/log/?h=bacondrm
>> >> >
>> >> > A couple of us have been talking about this in person and IRC for
>> >> > a while, but I realize I haven't mentioned anything about it on the
>> >> > mailing list yet, so this may come as a bit of a surprise.
>> >> >
>> >> > libdrm_intel is about 15 source files and almost 13,000 lines of
>> >> > code.
>> >> > This series adds 3 files (one .c, two .h) and only 2,137 lines of
>> >> > code:
>> >> >
>> >> > 60 files changed, 2784 insertions(+), 647 deletions(-)
>> >> >
>> >> > The rest of the library is basically useless to us.  It contains a
>> >> > lot
>> >> > of legacy cruft from the pre-GEM, DRI1, or 8xx/9xx era.  But even the
>> >> > parts we do use are in bad shape.  BO offset tracking is
>> >> > non-threadsafe.
>> >> > Relocation handling is way too complicated.  These things waste
>> >> > memory,
>> >> > burn CPU time, and make it difficult for us to take advantage of new
>> >> > kernel features like I915_EXEC_NO_RELOC which would reduce overhead
>> >> > further.  The unsynchronized mapping API performs a synchronized
>> >> > mapping
>> >> > on non-LLC platforms, which can massively hurt performance on Atoms.
>> >> > Mesa is also using uncached GTT mappings for almost everything on
>> >> > Atoms,
>> >> > rather than fast CPU or WC maps where possible.
>> >> >
>> >> > Evolving this code in libdrm is very painful, as we aren't allowed to
>> >> > break the ABI.  All the legacy cruft and design mistakes (in
>> >> > hindsight)
>> >> > make it difficult to follow what's going on.  We could keep piling
>> >> > new
>> >> > layers on top, but that only makes it worse.  Furthermore, there's a
>> >> > bunch of complexity that comes from defending against or supporting
>> >> > broken or badly designed callers.
>> >> >
>> >> I believe I mentioned it a few days ago - there is no need to worry
>> >> about API or ABI stability.
>> >>
>> >> Need new API - add it. Things getting fragile or too many layers - sed
>> >> /libdrm_intel$(N)/libdrm_intel$(N+1)/ and rework as needed.
>> >>
>> >> I fear that Importing libdrm_intel will be detrimental to libva's
>> >> intel-driver, Beignet and xf86-video-intel
>
>
> I wouldn't worry about xf86-video-intel.  Chris has already copy+pasted half
> of the X server, what's libdrm? :-)
>
> The others, yeah, they could possibly benefit from drm_intel3.  That said, I
> think you significantly over-estimate how much a driver actually gets from
> libdrm.  We chose to not use libdrm in Vulkan and it really hasn't caused us
> all that much pain.
>
>>
>> >> development.
>> >> Those teams seem to be more resource contained than Mesa, thus they
>> >> will trail behind even more.
>> >>
>> >> As an example - the intel-driver is missing some trivial winsys
>> >> optimisations that landed in Mesa 3+ years ago. That could have been
>> >> avoided if the helpers were shared with the help of
>> >> libdrm_intel/other.
>
>
> libdrm should *never* touch winsys.  Please, no.
>
>>
>> >
>> > That is kinda the longer-term goal with this. There's a lot more that
>> > needs to be done besides Ken's series here, this is just the first step,
>> > but in the end we'll probably move brw_batch back into libdrm_intel2 or
>> > so, for consumption by beignet and libva.
>> >
>> > But for rewriting the world and getting rid of 10+ years of compat
>> > garbage, having a split between libdrm and mesa isn't great.
>> >
>> So the goal is to have the code in mesa as a form of incubator until
>> it reaches maturity.
>> This way one will have a more rapid development and greater
>> flexibility during that stage.
>
>
> Yes, I think we'd eventually like to have some shared code again.  However,
> at the moment, that code sharing is costing us dearly and it's time for a
> step back and a complete re-evaluation of how we do things.  Once we've
> settled on something we like then maybe we can consider sharing again.
> Ideally, I'd like the Vulkan driver to be able to share at least some bits
> with i965.  At the moment, however, we don't know what the new API should
> look like or what bets we even want to share, so pulling the whole thing in
> is the right next step.

The concern about code quality of libva is valid, but there's much
more code inside mesa 

Re: [Mesa-dev] [PATCH 2/2] gallium/util: libunwind support

[Kristian Høgsberg]

On Mon, Apr 3, 2017 at 10:13 AM, Rob Clark  wrote:
> On Mon, Apr 3, 2017 at 12:56 PM, Thomas Hellstrom  
> wrote:
>> Hi, Rob,
>>
>> On 03/24/2017 10:21 PM, Rob Clark wrote:
>>> It's kinda sad that (a) we don't have debug_backtrace support on !X86
>>> and that (b) we re-invent our own crude backtrace support in the first
>>> place.  If available, use libunwind instead.  The backtrace format is
>>> based on what xserver and weston use, since it is nice not to have to
>>> figure out a different format.
>>>
>>> Signed-off-by: Rob Clark 
>>
>> Did you consider glibc "backtrace()", I think it's also available on ARM...
>
> I had not.. although xserver and weston are already using libunwind.
> I'm not sure about portability of libunwind to other libc
> implementations (but I guess it is at least not worse than using a
> glibc specific API).

We did use glibc backtrace initially in weston, but switched to
libbacktrace to get better support for symbols in dlopened modules.
Here's the commit message:

compositor: Use libunwind if available for better backtraces

libunwind has a dwarf parser and automatically queries the dlinfo
for location of dlopened modules.  The resulting backtrace is much
better and includes stack frames in dynamically loaded modules.

krh: Originally submitted for Xorg, adapted for weston:

  http://lists.x.org/archives/xorg-devel/2013-February/035493.html

Note this require libunwind at least 1.1 to get the pkg-config files.

Signed-off-by: Marcin Slusarz 

See 
https://cgit.freedesktop.org/wayland/weston/commit/?id=554a0da74a3f6fc945503a3eb1bfcc9038441b39

Kristian

> I suppose we could always add a fallback to backtrace().
>
>> Also is the output format the same as before, or at least compatible with
>> gallium/tools/addr2line.sh?
>
> quite possibly not.. I chose to align to the format that xserver and
> weston was already using.  Otoh, not sure if you would need to use
> addr2line.sh since it already decodes things to human readable
> fxn/file names.
>
> BR,
> -R
>
>> Thanks,
>> Thomas
>>
> ___
> 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 v2] anv: add support for allocating more than 1 block of memory

[Kristian Høgsberg]

On Wed, Mar 29, 2017 at 12:06 PM, Jason Ekstrand  wrote:
> Looking over the patch, I think I've convinced myself that it's correct.  (I
> honestly wasn't expecting to come to that conclusion without more
> iteration.)  That said, this raises some interesting questions.  I added
> Kristian to the Cc in case he has any input.

I haven't looked closely, and I agree it's increasingly tricky code to
review. I'd be careful about making this a fully generic any-block
size allocator. The premise, when we first designed this, was that for
something like a fixed-size, power-of-two pool, we could write a fast,
lock-less and fragmentation free allocator without getting in over our
heads. However, if this evolves (devolves?) into "malloc, but for
bos", it may be time to take a step back and look if something like
jemalloc with bo backing is a better choice.

Kristian

>
>  1. Should we do powers of two or linear.  I'm still a fan of powers of two.
>
>  2. Should block pools even have a block size at all? We could just make
> every block pool allow any power-of-two size from 4 KiB up to. say, 1 MiB
> and then make the block size part of the state pool or stream that's
> allocating from it.  At the moment, I like this idea, but I've given it very
> little thought.
>
>  3. If we go with the idea in 2. should we still call it block_pool?  I
> think we can keep the name but it doesn't it as well as it once did.
>
> Thanks for working on this!  I'm sorry it's taken so long to respond.  Every
> time I've looked at it, my brain hasn't been in the right state to think
> about lock-free code. :-/
>
> On Wed, Mar 15, 2017 at 5:05 AM, Juan A. Suarez Romero 
> wrote:
>>
>> Current Anv allocator assign memory in terms of a fixed block size.
>>
>> But there can be cases where this block is not enough for a memory
>> request, and thus several blocks must be assigned in a row.
>>
>> This commit adds support for specifying how many blocks of memory must
>> be assigned.
>>
>> This fixes a number dEQP-VK.pipeline.render_to_image.* tests that crash.
>>
>> v2: lock-free free-list is not handled correctly (Jason)
>> ---
>>  src/intel/vulkan/anv_allocator.c   | 81
>> +++---
>>  src/intel/vulkan/anv_batch_chain.c |  4 +-
>>  src/intel/vulkan/anv_private.h |  7 +++-
>>  3 files changed, 66 insertions(+), 26 deletions(-)
>>
>> diff --git a/src/intel/vulkan/anv_allocator.c
>> b/src/intel/vulkan/anv_allocator.c
>> index 45c663b..3924551 100644
>> --- a/src/intel/vulkan/anv_allocator.c
>> +++ b/src/intel/vulkan/anv_allocator.c
>> @@ -257,7 +257,8 @@ anv_block_pool_init(struct anv_block_pool *pool,
>> pool->device = device;
>> anv_bo_init(>bo, 0, 0);
>> pool->block_size = block_size;
>> -   pool->free_list = ANV_FREE_LIST_EMPTY;
>> +   for (uint32_t i = 0; i < ANV_MAX_BLOCKS; i++)
>> +  pool->free_list[i] = ANV_FREE_LIST_EMPTY;
>> pool->back_free_list = ANV_FREE_LIST_EMPTY;
>>
>> pool->fd = memfd_create("block pool", MFD_CLOEXEC);
>> @@ -500,30 +501,35 @@ fail:
>>
>>  static uint32_t
>>  anv_block_pool_alloc_new(struct anv_block_pool *pool,
>> - struct anv_block_state *pool_state)
>> + struct anv_block_state *pool_state,
>> + uint32_t n_blocks)
>
>
> Maybe have this take a size rather than n_blocks?  It's only ever called by
> stuff in the block pool so the caller can do the multiplication.  It would
> certainly make some of the math below easier.
>
>>
>>  {
>> struct anv_block_state state, old, new;
>>
>> while (1) {
>> -  state.u64 = __sync_fetch_and_add(_state->u64,
>> pool->block_size);
>> -  if (state.next < state.end) {
>> +  state.u64 = __sync_fetch_and_add(_state->u64, n_blocks *
>> pool->block_size);
>> +  if (state.next > state.end) {
>> + futex_wait(_state->end, state.end);
>> + continue;
>> +  } else if ((state.next + (n_blocks - 1) * pool->block_size) <
>> state.end) {
>
>
> First off, please keep the if's in the same order unless we have a reason to
> re-arrange them.  It would make this way easier to review. :-)
>
> Second, I think this would be much easier to read as:
>
> if (state.next + size <= state.end) {
>/* Success */
> } else if (state.next <= state.end) {
>/* Our block is the one that crosses the line */
> } else {
>/* Wait like everyone else */
> }
>
>>
>>   assert(pool->map);
>>   return state.next;
>> -  } else if (state.next == state.end) {
>> - /* We allocated the first block outside the pool, we have to
>> grow it.
>> -  * pool_state->next acts a mutex: threads who try to allocate
>> now will
>> -  * get block indexes above the current limit and hit futex_wait
>> -  * below. */
>> - new.next = state.next + pool->block_size;
>> +  } else {
>> + /* We allocated the firsts blocks outside the pool, we have to
>> grow
>> + 

Re: [Mesa-dev] [PATCH 7/7] intel: tools: add aubinator_error_decode tool

[Kristian Høgsberg]

On Thu, Mar 30, 2017 at 1:38 PM, Lionel Landwerlin
 wrote:
> On 30/03/17 20:09, Chris Wilson wrote:
>>
>> On Thu, Mar 30, 2017 at 11:27:26AM -0700, Matt Turner wrote:
>>>
>>> I think we should figure out how to make this not just a fork of
>>> intel_error_decode. Should intel_error_decode do away?
>>>
>>> There are various tools in i-g-t that I'm definitely in favor of
>>> moving into Mesa (like the assembler and disassembler, and aubdump).
>>> Should this one move too? Do we have buy-in from Chris?
>>
>> Sure, if it means that we do get an actively maintained decoder - just
>> hope that gen2-3 is forthcoming, and perhaps some inferred type
>> decoding.
>
>
> I guess that depends on whether we can get somebody to write genxml for
> them.
> Not sure it's a big priority for us :/
> Maybe a rainy weekend project?
>
>>
>> What's more important is that it is fairly flexible in error-state file
>> format - mostly the lists and order of registers change, different
>> amount of detail in the kernel state trackers etc. I was thinking that
>> maybe we wanted a more parseable format like json (error.json),
>> something a bit more flexible?
>
>
> That would be great.
>
>> What I also want is a use-case for EXEC_OBJECT_CAPTURE. Aside from
>> plain listing in the error state, it would be nice if the decoder could
>> parse 3DSTATE_BASE to work out which buffer was, for example, the
>> instruction buffer and then decode the relevant kernels from 3DSTATE_PS.
>
>
> If I understood things right, I think that's what Matt's working on.

aubinator already does this.

>> Decoding vertex buffers is perhaps less interesting in general that it
>> was for me, but similarly if they could be found within the error state,
>> dumping the vertices for each PRIMITIVE -- though with GS/HS/TS that
>> again is probably useless -- so really just an example of being
>> flexible, if the data is there in the error state, decode it inline.
>
>
> That's something I'm also interested in.
> I would really like to be able to inspect the state of the GPU for each draw
> call in aubinator for example.
> Lines of text aren't the best way to inspect though.
>
> A few months back, I started to write an aubinator.py script in the hope of
> having some UI on top.
> I think we need a slightly better genxml description to have that completely
> automatic though, as it stands we miss a some relationships between
> offsets/address & STATE_BASE_ADDRESS for example.

Be careful, before you know it you'll be writing a simulator. It happened to me.

Kristian

>>
>> I was won over at having pager support. I was getting close to moving
>> the decoder to mesa myself, though it would have been a much less
>> refined effort!
>> -Chris
>>
>
> ___
> 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 libdrm 0/2] Replace the build system with meson

[Kristian Høgsberg]

On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca <jfons...@vmware.com> wrote:
> On 24/03/17 19:10, Kristian Høgsberg wrote:
>>
>> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca <jfons...@vmware.com> wrote:
>>>
>>> On 23/03/17 01:38, Rob Clark wrote:
>>>>
>>>>
>>>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray <j...@jsg.id.au> wrote:
>>>>>
>>>>>
>>>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeuc...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> I guess I'm a little late to the party here, but I haven't had time
>>>>>>> to
>>>>>>> really let all of this sink in and actually look at meson.  It
>>>>>>> doesn't
>>>>>>> seem so bad with a quick look and I think I could probably sort it
>>>>>>> out
>>>>>>> when the time came, but there would still be a bit of a learning
>>>>>>> curve.  While that may not be a big deal at the micro level, I have
>>>>>>> concerns at the macro level.
>>>>>>>
>>>>>>> First, I'm concerned it may discourage casual developers and
>>>>>>> packagers.  autotools isn't great, but most people are familiar
>>>>>>> enough
>>>>>>> with it that they can get by.  Most people have enough knowledge of
>>>>>>> autotools that they can pretty easily diagnose a configuration based
>>>>>>> failure. There are a lot of resources for autotools.  I'm not sure
>>>>>>> that would be the case for meson.  Do we as a community feel we have
>>>>>>> enough meson experience to get people over the hump?  Anything that
>>>>>>> makes it harder for someone to try a new build or do a bisect is a
>>>>>>> big
>>>>>>> problem in my opinion.
>>>>>>
>>>>>>
>>>>>>
>>>>>> One of the things that's prompted this on our side (I've talked this
>>>>>> over with
>>>>>> other people at Intel before starting), was that clearly we *don't*
>>>>>> know
>>>>>> autotools well enough to get it right. Emil almost always finds cases
>>>>>> were we've
>>>>>> done things *almost*, but not quite right.
>>>>>>
>>>>>> For my part, it took me about 3 or 4 days of reading through the docs
>>>>>> and
>>>>>> writing the libdrm port to get it right, and a lot of that is just the
>>>>>> boilerplate of having ~8 drivers that all need basically the same
>>>>>> logic.
>>>>>>
>>>>>>> Next, my bigger concern is for distro and casual packagers and people
>>>>>>> that maintain large build systems with lots of existing custom
>>>>>>> configurations.  Changing from autotools would basically require many
>>>>>>> of these existing tools and systems to be rewritten and then deal
>>>>>>> with
>>>>>>> the debugging and fall out from that.  The potential decreased build
>>>>>>> time is a nice bonus, but frankly a lot of people/companies have
>>>>>>> years
>>>>>>> of investment in existing tools.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sure, but we're also not the only ones investigating meson. Gnome is
>>>>>> using it
>>>>>> already, libepoxy is using it, gstreamer is using it. There are
>>>>>> patches
>>>>>> for
>>>>>> weston (written by Daniel Stone) and libinput (written by Peter
>>>>>> Hutterer), there
>>>>>> are some other projects in the graphics sphere that people are working
>>>>>> on. So
>>>>>> even if we as a community decide that meson isn't for us, it's not
>>>>>> going
>>>>>> away.
>>>>>
>>>>>
>>>>>
>>>>> It is worth pointing out that it is currently required by no component
>>>>> of an x.org stack.  In the case of libepoxy it was added by a new
>>>>> main

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Kristian Høgsberg]

On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca  wrote:
> On 23/03/17 01:38, Rob Clark wrote:
>>
>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:
>>>
>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:

 On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher 
 wrote:
>
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson.  It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.


 One of the things that's prompted this on our side (I've talked this
 over with
 other people at Intel before starting), was that clearly we *don't* know
 autotools well enough to get it right. Emil almost always finds cases
 were we've
 done things *almost*, but not quite right.

 For my part, it took me about 3 or 4 days of reading through the docs
 and
 writing the libdrm port to get it right, and a lot of that is just the
 boilerplate of having ~8 drivers that all need basically the same logic.

> Next, my bigger concern is for distro and casual packagers and people
> that maintain large build systems with lots of existing custom
> configurations.  Changing from autotools would basically require many
> of these existing tools and systems to be rewritten and then deal with
> the debugging and fall out from that.  The potential decreased build
> time is a nice bonus, but frankly a lot of people/companies have years
> of investment in existing tools.


 Sure, but we're also not the only ones investigating meson. Gnome is
 using it
 already, libepoxy is using it, gstreamer is using it. There are patches
 for
 weston (written by Daniel Stone) and libinput (written by Peter
 Hutterer), there
 are some other projects in the graphics sphere that people are working
 on. So
 even if we as a community decide that meson isn't for us, it's not going
 away.
>>>
>>>
>>> It is worth pointing out that it is currently required by no component
>>> of an x.org stack.  In the case of libepoxy it was added by a new
>>> maintainer
>>> on a new release and even then autoconf remains.
>>>
>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>> currently requires meson to build including gnome and gstreamer.
>>>
>>
>> but I guess that is conflating two completely different topics..
>> addition of meson and removal of autotools.  It is probably better
>> that we treat the topics separately.  I don't see any way that the two
>> can happen at the same time.
>>
>> The autotools build probably needs to remain for at least a couple
>> releases, and I certainly wouldn't mind if some of the other desktop
>> projects took the leap of dropping autotools first (at least then
>> various different "distro" consumers will have already dealt with how
>> to build meson packages)
>>
>> None of that blocks addition of a meson build system (or what various
>> developers use day to day)
>>
>> BR,
>> -R
>
>
> I tend to disagree.  While we can't avoid a transitory period, when we
> embark on another build system (Meson or something else) I think we should
> aim at 1) ensure such tool can indeed _completely_ replace at least _one_
> existing build system, 2) and aim at migration quickly.
>
> Otherwise we'll just end up with yet another build system, yet another way
> builds can fail, with some developers stuck on old build systems because it
> works, or because the new build system quite doesn't work.
>
> And this is from (painful) experience.

I agree, adding a meson build system should aim to phase out one of
the other build systems within one or two release cycles. But (and
maybe that was Robs point) that doesn't have be autotools. What if we
phase out scons? It doesn't seem like anybody is really attached to it
and if meson is as good as scons on windows, then if nothing else
happens we end up with the same number of build systems. What's more
likely to happen is that a lot of Linux developers (and CI systems)
will also start 

Re: [Mesa-dev] [PATCH 3/5] anv: Add support for the PMA fix on Broadwell

[Kristian Høgsberg]

On Wed, Feb 1, 2017 at 5:44 PM Jason Ekstrand  wrote:

> In order to get good performance numbers for this, I had to hack up the
> driver to whack wm_prog_data::uses_kill to true to emulate a discard and
> used the Sascha "shadowmapping" demo.  Setting uses_kill to true dropped
> the framerate on the demo by 25-30%.  Enabling the PMA fix brought it
> back up to around 90% of the original framerate.  This doesn't seem to
> really impact Dota 2;  probably because it doesn't use 16-bit depth.
>

Nice to see this done - there's a FIXME in cmd_buffer_emit_depth_stencil()
you can delete.

Kristian


> ---
>  src/intel/vulkan/TODO  |   1 -
>  src/intel/vulkan/anv_cmd_buffer.c  |   1 +
>  src/intel/vulkan/anv_genX.h|   3 +
>  src/intel/vulkan/anv_private.h |  10 +++
>  src/intel/vulkan/gen7_cmd_buffer.c |   7 ++
>  src/intel/vulkan/gen8_cmd_buffer.c | 139
> +
>  src/intel/vulkan/genX_blorp_exec.c |   5 ++
>  src/intel/vulkan/genX_cmd_buffer.c |  10 +++
>  src/intel/vulkan/genX_pipeline.c   |  36 ++
>  9 files changed, 211 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/TODO b/src/intel/vulkan/TODO
> index 38acc0d..f8b73a1 100644
> --- a/src/intel/vulkan/TODO
> +++ b/src/intel/vulkan/TODO
> @@ -12,5 +12,4 @@ Performance:
>   - Compressed multisample support
>   - Pushing pieces of UBOs?
>   - Enable guardband clipping
> - - pma stall workaround
>   - Use soft-pin to avoid relocations
> diff --git a/src/intel/vulkan/anv_cmd_buffer.c
> b/src/intel/vulkan/anv_cmd_buffer.c
> index 5886fa6..a762476 100644
> --- a/src/intel/vulkan/anv_cmd_buffer.c
> +++ b/src/intel/vulkan/anv_cmd_buffer.c
> @@ -135,6 +135,7 @@ anv_cmd_state_reset(struct anv_cmd_buffer *cmd_buffer)
> state->restart_index = UINT32_MAX;
> state->dynamic = default_dynamic_state;
> state->need_query_wa = true;
> +   state->pma_fix_enabled = false;
>
> if (state->attachments != NULL) {
>vk_free(_buffer->pool->alloc, state->attachments);
> diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
> index d04fe38..67147b0 100644
> --- a/src/intel/vulkan/anv_genX.h
> +++ b/src/intel/vulkan/anv_genX.h
> @@ -55,6 +55,9 @@ void genX(cmd_buffer_flush_dynamic_state)(struct
> anv_cmd_buffer *cmd_buffer);
>
>  void genX(cmd_buffer_flush_compute_state)(struct anv_cmd_buffer
> *cmd_buffer);
>
> +void genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer *cmd_buffer,
> + bool enable);
> +
>  void
>  genX(emit_urb_setup)(struct anv_device *device, struct anv_batch *batch,
>   const struct gen_l3_config *l3_config,
> diff --git a/src/intel/vulkan/anv_private.h
> b/src/intel/vulkan/anv_private.h
> index 4fe3ebc..5fe4dd8 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -1163,6 +1163,13 @@ struct anv_cmd_state {
> bool need_query_wa;
>
> /**
> +* Whether or not the gen8 PMA fix is enabled.  We ensure that, at the
> top
> +* of any command buffer it disabled by disabling it in
> EndCommandBuffer
> +* and before invoking the secondary in ExecuteCommands.
> +*/
> +   bool pma_fix_enabled;
> +
> +   /**
>  * Array length is anv_cmd_state::pass::attachment_count. Array
> content is
>  * valid only when recording a render pass instance.
>  */
> @@ -1465,8 +1472,11 @@ struct anv_pipeline {
>
> uint32_t cs_right_mask;
>
> +   bool writes_depth;
> +   bool depth_test_enable;
> bool writes_stencil;
> bool depth_clamp_enable;
> +   bool kill_pixel;
>
> struct {
>uint32_t  sf[7];
> diff --git a/src/intel/vulkan/gen7_cmd_buffer.c
> b/src/intel/vulkan/gen7_cmd_buffer.c
> index 013ed87..c1a25e8 100644
> --- a/src/intel/vulkan/gen7_cmd_buffer.c
> +++ b/src/intel/vulkan/gen7_cmd_buffer.c
> @@ -260,6 +260,13 @@ genX(cmd_buffer_flush_dynamic_state)(struct
> anv_cmd_buffer *cmd_buffer)
> cmd_buffer->state.dirty = 0;
>  }
>
> +void
> +genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer *cmd_buffer,
> +bool enable)
> +{
> +   /* The NP PMA fix doesn't exist on gen7 */
> +}
> +
>  void genX(CmdSetEvent)(
>  VkCommandBuffer commandBuffer,
>  VkEvent event,
> diff --git a/src/intel/vulkan/gen8_cmd_buffer.c
> b/src/intel/vulkan/gen8_cmd_buffer.c
> index 8c8de62..b877e27 100644
> --- a/src/intel/vulkan/gen8_cmd_buffer.c
> +++ b/src/intel/vulkan/gen8_cmd_buffer.c
> @@ -155,6 +155,141 @@ __emit_sf_state(struct anv_cmd_buffer *cmd_buffer)
>  #endif
>
>  void
> 

Re: [Mesa-dev] [PATCH 0/18] Misc genxml patches

[Kristian Høgsberg]

Thanks! I'll keep 15 and 17 out. I'd still like to have tile mode as an
enum, but maybe I'll make the generator split inline values out as enums -
or maybe just when you've specified an enum name as the type. That is,


  
  
  
  


generates

enum GEN9_TILE_MODE {
   LINEAR = 0,
   WMAJOR = 1,
   XMAJOR = 2,
   YMAJOR = 3,
};

and

struct GEN9_SURFACE_STATE {
   ...
   enum GEN9_TILE_MODE TileMode;
   ...
};

Kristian

On Tue, Nov 29, 2016 at 4:19 PM Jason Ekstrand <ja...@jlekstrand.net> wrote:

> I'm a bit inclined to drop patch 15 because I think tile mode deserves to
> remain inline.  I don't care about 17.  I didn't really review it for not
> breaking things though.  The rest are
>
> Reviewed-by: Jason Ekstrand <ja...@jlekstrand.net>
>
> Don't push until you get Jenkins' ok though!
>
> --Jason
>
> On Tue, Nov 29, 2016 at 12:55 PM, Kristian Høgsberg <hoegsb...@gmail.com>
> wrote:
>
> On Tue, Nov 29, 2016 at 12:48 PM Kristian H. Kristensen <
> hoegsb...@gmail.com> wrote:
>
> Hi,
>
> Here's a few patches to the genxml files that I've been sitting on. The
> main part of the series is about emitting C enums for genxml enums, so
> it looks nice and pretty in gdb. It also adds support to aubinator so
> it knows how to decode enums as well as the inline values Lionel added
> support for:
>
> Surface Array: true
> Surface Format: 2 (R32G32B32A32_UINT)
> Surface Vertical Alignment: 1 (VALIGN 4)
>
> Look at that surface format being decoded! Patch 17 is "take it or
> leave it". I know nothing in mesa needs unpack functions, but I wouldn't
> mind having it upstream so I don't lose it (again).
>
>
> Oh, and true to form, I forgot the most important point: patch 16 is a
> legitimate
> fix for the compute shader KSP being split across a innocuous looking
> KernelStartPointer
> 32 bit field and a 16 bit "Kernel Start Pointer High" field. The driver
> doesn't know this
> and only sets KernelStartPointer. As long as anv uses instruction base
> offset, it's unlikely to
> cause a problem, but should be fixed.
>
> 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] [PATCH 15/18] intel/genxml: Add and use enum for tile mode

[Kristian Høgsberg]

On Tue, Nov 29, 2016 at 4:03 PM Jason Ekstrand  wrote:

> On Tue, Nov 29, 2016 at 12:48 PM, Kristian H. Kristensen <
> hoegsb...@gmail.com> wrote:
>
> Signed-off-by: Kristian H. Kristensen 
> ---
>  src/intel/genxml/gen8.xml |  9 -
>  src/intel/genxml/gen9.xml | 14 --
>  2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
> index 165ff25..17234f6 100644
> --- a/src/intel/genxml/gen8.xml
> +++ b/src/intel/genxml/gen8.xml
> @@ -401,6 +401,13 @@
>  
>
>
> +  
> +
> +
> +
> +
> +  
> +
>
>   type="uint"/>
>   type="uint"/>
> @@ -670,7 +677,7 @@
>
>
>  
> -
> +
>
>
>
>
>
> I don't think you want these anymore.
>

Right, thanks


> As a side-note, what's the purpose of pulling one-use things out into
> enums?  Tile Mode is not very general.
>

To let gen_pack_header.py use an enum in the packing struct. Maybe we
should just generate C enums for inline values instead, though that breaks
for the cases where inline values are duplicated. That works today because
the C preprocessor ignores duplicate but identical #defines.

Kristian


>
>
> diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
> index ec85494..c9fb770 100644
> --- a/src/intel/genxml/gen9.xml
> +++ b/src/intel/genxml/gen9.xml
> @@ -422,6 +422,13 @@
>  
>
>
> +  
> +
> +
> +
> +
> +  
> +
>
>   type="uint"/>
>   type="uint"/>
> @@ -696,12 +703,7 @@
>
>
>  
> -
> -  
> -  
> -  
> -  
> -
> +
>  
>   type="uint"/>
>   type="bool"/>
>
> --
> 2.9.3
>
> ___
> 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 11/18] intel/genxml: Use enum 3D_Stencil_Operation where applicable

[Kristian Høgsberg]

On Tue, Nov 29, 2016 at 3:37 PM Jason Ekstrand  wrote:

> On Tue, Nov 29, 2016 at 12:48 PM, Kristian H. Kristensen <
> hoegsb...@gmail.com> wrote:
>
> Signed-off-by: Kristian H. Kristensen 
> ---
>  src/intel/genxml/gen6.xml  | 39 ---
>  src/intel/genxml/gen7.xml  | 41 +
>  src/intel/genxml/gen75.xml | 41 +
>  src/intel/genxml/gen8.xml  | 12 ++--
>  src/intel/genxml/gen9.xml  | 12 ++--
>  5 files changed, 62 insertions(+), 83 deletions(-)
>
> diff --git a/src/intel/genxml/gen6.xml b/src/intel/genxml/gen6.xml
> index 732a76c..ae8978b 100644
> --- a/src/intel/genxml/gen6.xml
> +++ b/src/intel/genxml/gen6.xml
> @@ -45,6 +45,17 @@
>  
>
>
> +  
> +
> +
> +
> +
> +
> +
> +
> +
> +  
> +
>
>  
>  
> @@ -470,32 +481,14 @@
>
>  
>   type="3D_Compare_Function"/>
> -
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -
> - type="uint"/>
> - type="uint"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
>   type="bool"/>
>   type="bool"/>
>   type="3D_Compare_Function"/>
> -
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -
> - type="uint"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
>   type="uint"/>
>
>
> Need to fix this one too
>

Oh yea, nicely spotted. grepping for "Fail Op" and "Pass Op" it looks like
that's the only one I missed. Fixed locally.

Kristian


>
>
>  
>  
> diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
> index d18b02a..f650e76 100644
> --- a/src/intel/genxml/gen7.xml
> +++ b/src/intel/genxml/gen7.xml
> @@ -66,6 +66,17 @@
>  
>
>
> +  
> +
> +
> +
> +
> +
> +
> +
> +
> +  
> +
>
>  
>  
> @@ -525,33 +536,15 @@
>
>  
>   type="3D_Compare_Function"/>
> -
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -
> - type="uint"/>
> - type="uint"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
>   type="bool"/>
>   type="bool"/>
>   type="3D_Compare_Function"/>
> -
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -
> - type="uint"/>
> - type="uint"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
>  
>  
>   type="uint"/>
> diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
> index 123c9e3..4123fc5 100644
> --- a/src/intel/genxml/gen75.xml
> +++ b/src/intel/genxml/gen75.xml
> @@ -66,6 +66,17 @@
>  
>
>
> +  
> +
> +
> +
> +
> +
> +
> +
> +
> +  
> +
>
>  
>  
> @@ -535,33 +546,15 @@
>
>  
>   type="3D_Compare_Function"/>
> -
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -
> - type="uint"/>
> - type="uint"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
>   type="bool"/>
>   type="bool"/>
>   type="3D_Compare_Function"/>
> -
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -
> - type="uint"/>
> - type="uint"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
>  
>  
>   type="uint"/>
> diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
> index 58feef3..94a415b 100644
> --- a/src/intel/genxml/gen8.xml
> +++ b/src/intel/genxml/gen8.xml
> @@ -2370,13 +2370,13 @@
>   default="0"/>
>   default="78"/>
>  
> -
> - type="uint"/>
> - type="uint"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
>   type="3D_Compare_Function"/>
> - type="uint"/>
> - type="uint"/>
> - type="uint"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
>   type="3D_Compare_Function"/>
>   type="3D_Compare_Function"/>
>   type="bool"/>
> diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
> index b9dcc54..bda1c73 100644
> --- a/src/intel/genxml/gen9.xml
> +++ b/src/intel/genxml/gen9.xml
> @@ -2595,13 +2595,13 @@
>   default="0"/>
>   default="78"/>
>  
> -
> - type="uint"/>
> - type="uint"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
> + type="3D_Stencil_Operation"/>
>   type="3D_Compare_Function"/>
> - type="uint"/>
> - type="uint"/>
> - 

Re: [Mesa-dev] [PATCH 0/18] Misc genxml patches

[Kristian Høgsberg]

On Tue, Nov 29, 2016 at 12:48 PM Kristian H. Kristensen 
wrote:

> Hi,
>
> Here's a few patches to the genxml files that I've been sitting on. The
> main part of the series is about emitting C enums for genxml enums, so
> it looks nice and pretty in gdb. It also adds support to aubinator so
> it knows how to decode enums as well as the inline values Lionel added
> support for:
>
> Surface Array: true
> Surface Format: 2 (R32G32B32A32_UINT)
> Surface Vertical Alignment: 1 (VALIGN 4)
>
> Look at that surface format being decoded! Patch 17 is "take it or
> leave it". I know nothing in mesa needs unpack functions, but I wouldn't
> mind having it upstream so I don't lose it (again).
>

Oh, and true to form, I forgot the most important point: patch 16 is a
legitimate
fix for the compute shader KSP being split across a innocuous looking
KernelStartPointer
32 bit field and a 16 bit "Kernel Start Pointer High" field. The driver
doesn't know this
and only sets KernelStartPointer. As long as anv uses instruction base
offset, it's unlikely to
cause a problem, but should be fixed.

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

Re: [Mesa-dev] [PATCH 1/4] intel/aubinator: Properly handle batch buffer chaining

[Kristian Høgsberg]

On Fri, Nov 18, 2016 at 11:54 AM Jason Ekstrand 
wrote:

> From: Jason Ekstrand 
>
> The original aubinator that Kristian wrote had a bug in the handling of
> MI_BATCH_BUFFER_START that propagated into the version in upstream mesa.
> In particular, it ignored the "2nd level" bit which tells you whether this
> MI_BATCH_BUFFER_START is a subroutine call (2nd level) or a goto.  Since
> the Vulkan driver uses batch chaining, this can lead to a very confusing
> interpretation of the batches.  In some cases, depending on how things are
> laid out in the virtual GTT, you can even end up with infinite loops in
> batch processing.
>
>
All four:

Reviewed-by: Kristian H. Kristensen 


> Signed-off-by: Jason Ekstrand 
> ---
>  src/intel/tools/aubinator.c | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
> index 0d4b3f9..78682c5 100644
> --- a/src/intel/tools/aubinator.c
> +++ b/src/intel/tools/aubinator.c
> @@ -790,7 +790,25 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds,
> int size, int engine)
>   else
>  start = p[1];
>
> - parse_commands(spec, gtt + start, 1 << 20, engine);
> + if (p[0] & (1 << 22)) {
> +/* MI_BATCH_BUFFER_START with "2nd Level Batch Buffer" set
> acts
> + * like a subroutine call.  Commands that come afterwards get
> + * processed once the 2nd level batch buffer returns with
> + * MI_BATCH_BUFFER_END.
> + */
> +parse_commands(spec, gtt + start, gtt_end - start, engine);
> + } else {
> +/* MI_BATCH_BUFFER_START with "2nd Level Batch Buffer" unset
> acts
> + * like a goto.  Nothing after it will ever get processed.  In
> + * order to prevent the recursion from growing, we just reset
> the
> + * loop and continue;
> + */
> +p = gtt + start;
> +/* We don't know where secondaries end so use the GTT end */
> +end = gtt + gtt_end;
> +length = 0;
> +continue;
> + }
>} else if ((p[0] & 0x) == AUB_MI_BATCH_BUFFER_END) {
>   break;
>}
> --
> 2.5.0.400.gff86faf
>
> ___
> 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 00/20] anv: Unify pipeline setup across gens

[Kristian Høgsberg]

On Sat, Nov 12, 2016 at 1:35 PM Jason Ekstrand  wrote:

> This series started off as me thinking that we should set the correct
> sampler and binding table entry counts because maybe caching those things
> would improve performance.  Then it turned into spring cleaning.  The end
> result is that gen7_pipeline.c, gen8_pipeline.c, and genX_pipeline_util.h
> are all merged into genX_pipeline.c.  Every single packet in pipeline setup
> now has a common path.
>

This looks great, thanks for finally unifying things the way we always
meant to and getting rid of genX_pipeline_util.h.

For the series:

Reviewed-by: Kristian H. Kristensen 


> I still haven't tested the performance of cached sampler states.
>

I'd be interested to hear if you're able to measure anything one way or the
other.

Kristian


>
> Jason Ekstrand (20):
>   anv/pipeline: Set correct binding table and sampler counts
>   anv/pipeline: Get rid of the kernel pointer fields
>   intel/genxml: Make some VS/GS fields consistent across gens
>   anv/pipeline: Stop claiming to support running without a vertex shader
>   anv/pipeline/gen8: Enable VS statistics
>   anv/pipeline: Unify 3DSTATE_VS emission
>   intel/genxml: Make some 3DSTATE_GS fields more consistent
>   anv/pipeline: Unify 3DSTATE_GS emission
>   anv/pipeline: Make emit_3dstate_sbe safe to call without a FS
>   intel/genxml: Make some 3DSTATE_PS fields more consistent
>   anv/pipeline: Unify 3DSTATE_PS emission
>   intel/genxml: Make 3DSTATE_WM more consistent across gens
>   anv/pipeline: Unify 3DSTATE_WM emission
>   anv/pipeline: Move 3DSTATE_PS_EXTRA setup into a helper
>   anv/pipeline: Rework the 3DSTATE_VF_TOPOLOGY helper
>   anv/pipline: Re-order state emission and make it consistent
>   anv/pipeline: Unify graphics_pipeline_create
>   anv/pipeline: Roll genX_pipeline_util.h into genX_pipeline.c
>   anv: Move INTERFACE_DESCRIPTOR_DATA setup to the pipeline
>   anv/pipeline: Use get_scratch_space/address for compute shaders
>
>  src/intel/blorp/blorp_genX_exec.h |   12 +-
>  src/intel/genxml/gen6.xml |   32 +-
>  src/intel/genxml/gen7.xml |   32 +-
>  src/intel/genxml/gen75.xml|   32 +-
>  src/intel/genxml/gen8.xml |8 +-
>  src/intel/genxml/gen9.xml |8 +-
>  src/intel/vulkan/Makefile.sources |5 -
>  src/intel/vulkan/anv_genX.h   |7 -
>  src/intel/vulkan/anv_pipeline.c   |   22 -
>  src/intel/vulkan/anv_private.h|7 +-
>  src/intel/vulkan/gen7_pipeline.c  |  281 ---
>  src/intel/vulkan/gen8_pipeline.c  |  295 ---
>  src/intel/vulkan/genX_cmd_buffer.c|   35 +-
>  src/intel/vulkan/genX_pipeline.c  | 1393
> -
>  src/intel/vulkan/genX_pipeline_util.h |  959 ---
>  15 files changed, 1471 insertions(+), 1657 deletions(-)
>  delete mode 100644 src/intel/vulkan/gen7_pipeline.c
>  delete mode 100644 src/intel/vulkan/gen8_pipeline.c
>  delete mode 100644 src/intel/vulkan/genX_pipeline_util.h
>
> --
> 2.5.0.400.gff86faf
>
> ___
> 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 v4 00/10] anv: Rework relocation handling

[Kristian Høgsberg]

On Mon, Nov 7, 2016 at 2:27 PM Jason Ekstrand <ja...@jlekstrand.net> wrote:

> This is the fourth iteration of my attempt to rework relocation handling
> and do relocations in userspace.  I'm finally getting pretty happy with
> this and I think I'll probably merge this version if there are no further
> objections.
>
> Jason Ekstrand (9):
>   anv: Add a cmd_buffer_execbuf helper
>   anv: Don't presume to know what address is in a surface relocation
>   anv: Add a new bo_pool_init helper
>   anv/allocator: Simplify anv_scratch_pool
>   anv: Initialize anv_bo::offset to -1
>   anv/batch_chain: Improve write_reloc
>   anv: Add an anv_execbuf helper struct
>   anv/batch: Move last_ss_pool_bo_offset to the command buffer
>   anv: Move relocation handling from EndCommandBuffer to QueueSubmit
>
>
That all looks good, happy that you were able to get this idea working. I
would keep the execbuf bo list around in the VkCmdBuffer structure instead
of allocating and freeing the exact same amount on each execbuf, but I know
you like to malloc. For the series:

Reviewed-by: Kristian H. Kristensen <hoegsb...@google.com>


> Kristian Høgsberg (1):
>   anv: Do relocations in userspace before execbuf ioctl
>
>  src/intel/vulkan/anv_allocator.c   | 118 +---
>  src/intel/vulkan/anv_batch_chain.c | 386
> ++---
>  src/intel/vulkan/anv_device.c  |  49 +++--
>  src/intel/vulkan/anv_intel.c   |  11 +-
>  src/intel/vulkan/anv_private.h |  43 +++--
>  src/intel/vulkan/genX_cmd_buffer.c |  11 --
>  6 files changed, 384 insertions(+), 234 deletions(-)
>
> --
> 2.5.0.400.gff86faf
>
> ___
> 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] intel: aubinator: generate a standalone binary

[Kristian Høgsberg]

On Tue, Oct 4, 2016 at 9:26 AM Ben Widawsky  wrote:

> On 16-10-04 15:38:52, Lionel Landwerlin wrote:
> >Embed the xml files into the binary, so aubinator can be used from any
> >location.
> >
> >Signed-off-by: Lionel Landwerlin 
> >Cc: Sirisha Gandikota 
> >---
> > src/intel/Makefile.am   |  1 +
> > src/intel/Makefile.aubinator.am | 36 +++
> > src/intel/Makefile.sources  |  7 +++
> > src/intel/tools/.gitignore  |  5 +++
> > src/intel/tools/aubinator.c | 97
> +
> > src/intel/tools/decoder.c   | 82 --
> > src/intel/tools/decoder.h   |  4 +-
> > 7 files changed, 141 insertions(+), 91 deletions(-)
> > create mode 100644 src/intel/Makefile.aubinator.am
> >
> >diff --git a/src/intel/Makefile.am b/src/intel/Makefile.am
> >index 9186b5c..c3cb9fb 100644
> >--- a/src/intel/Makefile.am
> >+++ b/src/intel/Makefile.am
> >@@ -52,6 +52,7 @@ BUILT_SOURCES =
> > CLEANFILES =
> > EXTRA_DIST =
> >
> >+include Makefile.aubinator.am
> > include Makefile.blorp.am
> > include Makefile.common.am
> > include Makefile.genxml.am
> >diff --git a/src/intel/Makefile.aubinator.am b/src/intel/
> Makefile.aubinator.am
> >new file mode 100644
> >index 000..9772700
> >--- /dev/null
> >+++ b/src/intel/Makefile.aubinator.am
> >@@ -0,0 +1,36 @@
> >+# Copyright © 2016 Intel Corporation
> >+#
> >+# 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.
> >+
> >+BUILT_SOURCES += $(AUBINATOR_GENERATED_FILES)
> >+
> >+SUFFIXES = _aubinator_xml.h .xml
> >+
> >+tools/gen6_aubinator_xml.h: genxml/gen6.xml
> >+tools/gen7_aubinator_xml.h: genxml/gen7.xml
> >+tools/gen75_aubinator_xml.h: genxml/gen75.xml
> >+tools/gen8_aubinator_xml.h: genxml/gen8.xml
> >+tools/gen9_aubinator_xml.h: genxml/gen9.xml
> >+
> >+$(AUBINATOR_GENERATED_FILES): Makefile
> >+
> >+%_aubinator_xml.h:
> >+  $(MKDIR_GEN)
> >+  $(AM_V_GEN) xxd -i $< > $@
> >diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
> >index 94073d2..a5c2bf0 100644
> >--- a/src/intel/Makefile.sources
> >+++ b/src/intel/Makefile.sources
> >@@ -1,3 +1,10 @@
> >+AUBINATOR_GENERATED_FILES = \
> >+  tools/gen6_aubinator_xml.h \
> >+  tools/gen7_aubinator_xml.h \
> >+  tools/gen75_aubinator_xml.h \
> >+  tools/gen8_aubinator_xml.h \
> >+  tools/gen9_aubinator_xml.h
> >+
> > BLORP_FILES = \
> >   blorp/blorp.c \
> >   blorp/blorp.h \
> >diff --git a/src/intel/tools/.gitignore b/src/intel/tools/.gitignore
> >index 0c80a6f..c4eebde 100644
> >--- a/src/intel/tools/.gitignore
> >+++ b/src/intel/tools/.gitignore
> >@@ -1 +1,6 @@
> > /aubinator
> >+gen6_aubinator_xml.h
> >+gen75_aubinator_xml.h
> >+gen7_aubinator_xml.h
> >+gen8_aubinator_xml.h
> >+gen9_aubinator_xml.h
> >diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
> >index a31dcb2..83328b5 100644
> >--- a/src/intel/tools/aubinator.c
> >+++ b/src/intel/tools/aubinator.c
> >@@ -35,6 +35,8 @@
> > #include 
> > #include 
> >
> >+#include "util/macros.h"
> >+
> > #include "decoder.h"
> > #include "intel_aub.h"
> > #include "gen_disasm.h"
> >@@ -1059,11 +1061,24 @@ int main(int argc, char *argv[])
> > {
> >struct gen_spec *spec;
> >struct aub_file *file;
> >-   int i, pci_id = 0;
> >+   int i;
> >bool found_arg_gen = false, pager = true;
> >-   int gen_major, gen_minor;
> >-   const char *value;
> >-   char gen_file[256], gen_val[24];
> >+   const char *value, *input_file = NULL;
> >+   char gen_val[24];
> >+   const struct {
> >+  const char *name;
> >+  int pci_id;
> >+   } gens[] = {
> >+  { "ivb", 0x0166 }, /* Intel(R) Ivybridge Mobile GT2 */
> >+  { "hsw", 0x0416 }, /* Intel(R) Haswell Mobile GT2 */
> >+  { "byt", 0x0155 }, /* Intel(R) Bay Trail */
> >+  { "bdw", 

Re: [Mesa-dev] [Request for Testing] i965: import prime buffers in the current context, not screen

[Kristian Høgsberg]

On Thu, Sep 29, 2016 at 7:33 AM Martin Peres <martin.pe...@linux.intel.com>
wrote:

> On 02/09/16 10:08, Martin Peres wrote:
> >
> >
> > On 25/08/16 21:49, Kristian Høgsberg wrote:
> >> On Thu, Aug 25, 2016 at 11:38 AM, Chad Versace
> >> <chadvers...@chromium.org> wrote:
> >>> On Thu 25 Aug 2016, Martin Peres wrote:
> >>>> This mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and
> >>>> fixes many applications when using DRI3:
> >>>>  - Totem with libva on hw-accelerated decoding
> >>>>  - obs-studio, using Window Capture (Xcomposite) as a Source
> >>>>  - gstreamer with VAAPI
> >>>>
> >>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71759
> >>>> Signed-off-by: Martin Peres <martin.pe...@linux.intel.com>
> >>>> ---
> >>>>
> >>>> This patch supposedly prevents gnome from running for one Arch Linux
> >>>> maintainer. Kenneth Graunke  and I failed to reproduce it so I am
> >>>> asking for your help/comments on this.
> >>>>
> >>>>  src/mesa/drivers/dri/i965/intel_screen.c | 24
> ++--
> >>>>  1 file changed, 22 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> >>>> b/src/mesa/drivers/dri/i965/intel_screen.c
> >>>> index 7876652..5c0d300 100644
> >>>> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> >>>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> >>>> @@ -698,8 +698,11 @@ intel_create_image_from_fds(__DRIscreen *screen,
> >>>>  int *fds, int num_fds, int *strides,
> >>>> int *offsets,
> >>>>  void *loaderPrivate)
> >>>>  {
> >>>> +   GET_CURRENT_CONTEXT(ctx);
> >>>> struct intel_screen *intelScreen = screen->driverPrivate;
> >>>> +   struct brw_context *brw = brw_context(ctx);
> >>>> struct intel_image_format *f;
> >>>> +   dri_bufmgr *bufmgr;
> >>>> __DRIimage *image;
> >>>> int i, index;
> >>>>
> >>>> @@ -740,8 +743,25 @@ intel_create_image_from_fds(__DRIscreen *screen,
> >>>>   size = end;
> >>>> }
> >>>>
> >>>> -   image->bo =
> drm_intel_bo_gem_create_from_prime(intelScreen->bufmgr,
> >>>> -  fds[0], size);
> >>>> +   /* Let's import the buffer into the current context instead of
> >>>> the current
> >>>> +* screen as some applications like gstreamer, totem, or obs
> >>>> create multiple
> >>>> +* X connections which end up creating multiple screens and thus
> >>>> multiple
> >>>> +* buffer managers. They then proceed to use a different X
> >>>> connection to call
> >>>> +* GLXBindTexImageExt() which should import the buffer in the
> >>>> current thread
> >>>> +* bound and not the current screen. This is done properly
> >>>> upstairs for
> >>>> +* texture management so we need to mirror this behaviour if we
> >>>> don't want
> >>>> +* the kernel rejecting our pushbuffers as the buffers have not
> >>>> been imported
> >>>> +* by the same bufmgr that sent the pushbuffer.
> >>>> +*
> >>>> +* If there is no context currently bound, then revert to using
> >>>> the screen's
> >>>> +* buffer manager and hope for the best...
> >>>
> >>> Nope. This patch breaks EGL_EXT_image_dma_buf_import.
> >>>
> >>> When the user calls eglCreateImageKHR(EGLDisplay, EGLContext, ...) with
> >>> image type EGL_LINUX_DMA_BUF_EXT, then the spec requires that context
> be
> >>> NULL. The EGLDisplay parameter determines the namespace of the newly
> >>> created
> >>> EGLImage. By design, the currently bound context (and its display) DO
> >>> NOT affect
> >>> eglCreateImage.
> >>>
> >>>   Problem Example:
> >>> eglMakeCurrent(dpyA, ..., ctxA);
> >>> img = eglCreateImage(dpyB, EGL_NO_CONTEXT, ...);
> >
> > I see, that may explain the issue Ionut found with gnome. Thanks Chad!
> >

Re: [Mesa-dev] [PATCH 2/2] aubinator: print_help swap "FILE *file" with "bool critical"

[Kristian Høgsberg]

On Mon, Sep 12, 2016 at 4:59 AM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> Derive file locally and exit() accordingly based on the bool.
> Allows us to save a couple lines of code.
>

If we're nit-picking, I'd rather just pass the exit code than a bool parameter.

Kristian

> Signed-off-by: Emil Velikov 
> ---
> s/print_help/print_help_and_exit/ and/or too bike sheddy ?
> ---
>  src/intel/tools/aubinator.c | 22 ++
>  1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
> index 9d29b68..e48ab3e 100644
> --- a/src/intel/tools/aubinator.c
> +++ b/src/intel/tools/aubinator.c
> @@ -1011,8 +1011,10 @@ setup_pager(void)
>  }
>
>  static void
> -print_help(const char *progname, FILE *file)
> +print_help(const char *progname, bool critical)
>  {
> +   FILE *file = critical ? stderr : stdout;
> +
> fprintf(file,
> "Usage: %s [OPTION]... FILE\n"
> "Decode aub file contents.\n\n"
> @@ -1025,6 +1027,7 @@ print_help(const char *progname, FILE *file)
> "  --no-pager  don't launch pager\n"
> "  --no-offsetsdon't print instruction offsets\n",
> progname);
> +   exit(critical ? EXIT_FAILURE : EXIT_SUCCESS);
>  }
>
>  static bool
> @@ -1054,10 +1057,8 @@ int main(int argc, char *argv[])
> const char *value;
> char gen_file[256], gen_val[24];
>
> -   if (argc == 1) {
> -  print_help(argv[0], stderr);
> -  exit(EXIT_FAILURE);
> -   }
> +   if (argc == 1)
> +  print_help(argv[0], true);
>
> for (i = 1; i < argc; ++i) {
>if (strcmp(argv[i], "--no-pager") == 0) {
> @@ -1087,8 +1088,7 @@ int main(int argc, char *argv[])
>  exit(EXIT_FAILURE);
>   }
>} else if (strcmp(argv[i], "--help") == 0) {
> - print_help(argv[0], stdout);
> - exit(EXIT_SUCCESS);
> + print_help(argv[0], false);
>} else {
>   if (argv[i][0] == '-') {
>  fprintf(stderr, "unknown option %s\n", argv[i]);
> @@ -1166,12 +1166,10 @@ int main(int argc, char *argv[])
> spec = gen_spec_load(gen_file);
> disasm = gen_disasm_create(pci_id);
>
> -   if (argv[i] == NULL) {
> -   print_help(argv[0], stderr);
> -   exit(EXIT_FAILURE);
> -   } else {
> +   if (argv[i] == NULL)
> +   print_help(argv[0], true);
> +   else
> file = aub_file_open(argv[i]);
> -   }
>
> while (aub_file_more_stuff(file))
>aub_file_decode_batch(file, spec);
> --
> 2.9.3
>
> ___
> 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 0/3] Implement EGL_KHR_no_config_context

[Kristian Høgsberg]

On Fri, Sep 9, 2016 at 9:25 AM, Adam Jackson <a...@redhat.com> wrote:
> KHR_no_config_context is virtually identical to MESA_configless_context,
> where they differ is only where the Mesa spec is silent, and for the
> most part the code already did what the Khronos spec wants. Fix up the
> one corner case, and mark the Mesa extension as superseded.

Looks good to me:

Reviewed-by: Kristian Høgsberg <k...@bitplanet.net>

> - ajax
>
> ___
> 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 07/12] i965/blorp: Instruct vertex fetcher to provide prim instance id

[Kristian Høgsberg]

On Thu, Sep 1, 2016 at 8:43 AM, Jason Ekstrand  wrote:
> On Aug 31, 2016 9:06 AM, "Topi Pohjolainen" 
> wrote:
>>
>> This will indicate target layer (Render Target Array Index) needed
>> for layered clears.
>>
>> v2: Use 3DSTATE_VF_SGVS for gen8+
>>
>> Signed-off-by: Topi Pohjolainen 
>> ---
>>  src/intel/blorp/blorp_genX_exec.h | 26 ++
>>  1 file changed, 22 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/intel/blorp/blorp_genX_exec.h
>> b/src/intel/blorp/blorp_genX_exec.h
>> index f44076e..7312847 100644
>> --- a/src/intel/blorp/blorp_genX_exec.h
>> +++ b/src/intel/blorp/blorp_genX_exec.h
>> @@ -298,8 +298,10 @@ blorp_emit_vertex_elements(struct blorp_batch *batch,
>>  * the URB. This is controlled by the 3DSTATE_VERTEX_BUFFERS and
>>  * 3DSTATE_VERTEX_ELEMENTS packets below. The VUE contents are as
>> follows:
>>  *   dw0: Reserved, MBZ.
>> -*   dw1: Render Target Array Index. The HiZ op does not use indexed
>> -*vertices, so set the dword to 0.
>> +*   dw1: Render Target Array Index. Below vertex fetcher gets
>> programmed
>> +*to assign this with primitive instance identifier which will
>> be
>> +*used for layered clears. All other renders have only one
>> instance
>> +*and therefore the value will be effectively zero.
>>  *   dw2: Viewport Index. The HiZ op disables viewport mapping and
>>  *scissoring, so set the dword to 0.
>>  *   dw3: Point Width: The HiZ op does not emit the POINTLIST
>> primitive,
>> @@ -318,7 +320,7 @@ blorp_emit_vertex_elements(struct blorp_batch *batch,
>>  * "Vertex URB Entry (VUE) Formats".
>>  *
>>  * Only vertex position X and Y are going to be variable, Z is fixed
>> to
>> -* zero and W to one. Header words dw0-3 are all zero. There is no
>> need to
>> +* zero and W to one. Header words dw0,2,3 are zero. There is no need
>> to
>>  * include the fixed values in the vertex buffer. Vertex fetcher can
>> be
>>  * instructed to fill vertex elements with constant values of one and
>> zero
>>  * instead of reading them from the buffer.
>> @@ -332,7 +334,16 @@ blorp_emit_vertex_elements(struct blorp_batch *batch,
>> ve[0].SourceElementFormat = ISL_FORMAT_R32G32B32A32_FLOAT;
>> ve[0].SourceElementOffset = 0;
>> ve[0].Component0Control = VFCOMP_STORE_0;
>> +
>> +   /* From Gen8 onwards hardware is no more instructed to overwrite
>> components
>> +* using an element specifier. Instead one has separate
>> 3DSTATE_VF_SGVS
>> +* (System Generated Value Setup) state packet for it.
>> +*/
>> +#if GEN_GEN >= 8
>> ve[0].Component1Control = VFCOMP_STORE_0;
>> +#else
>> +   ve[0].Component1Control = VFCOMP_STORE_IID;
>> +#endif
>> ve[0].Component2Control = VFCOMP_STORE_0;
>> ve[0].Component3Control = VFCOMP_STORE_0;
>>
>> @@ -366,7 +377,14 @@ blorp_emit_vertex_elements(struct blorp_batch *batch,
>> }
>>
>>  #if GEN_GEN >= 8
>> -   blorp_emit(batch, GENX(3DSTATE_VF_SGVS), sgvs);
>> +   /* Overwrite Render Target Array Index (2nd dword) in the VUE header
>> with
>> +* primitive instance identifier. This is used for layered clears.
>> +*/
>> +   blorp_emit(batch, GENX(3DSTATE_VF_SGVS), sgvs) {
>> +  sgvs.InstanceIDEnable = true;
>> +  sgvs.InstanceIDComponentNumber = COMP_1;
>> +  sgvs.InstanceIDElementOffset = 0;
>> +   }
>
> I love the fact that we can use SVGS this way.  I cc'd Kristian so he can
> enjoy it too!
>
> Reviewed-by: Jason Ekstrand 

Yeah, nice - we already did that in meta though.

>> for (unsigned i = 0; i < num_elements; i++) {
>>blorp_emit(batch, GENX(3DSTATE_VF_INSTANCING), vf) {
>> --
>> 2.5.5
>>
>> ___
>> 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 3/3] aubinator: only use program_invocation_short_name with glibc/cygwin

[Kristian Høgsberg]

On Thu, Sep 1, 2016 at 10:12 AM, Jonathan Gray <j...@jsg.id.au> wrote:
> program_invocation_short_name is a gnu extension.  Limit use of it
> to glibc and cygwin and otherwise use getprogname() which is available
> on BSD and OS X.
>
> Signed-off-by: Jonathan Gray <j...@jsg.id.au>

For the series,
Reviewed-by: Kristian Høgsberg <k...@bitplanet.net>

> ---
>  src/intel/tools/aubinator.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
> index df84469..fe1f369 100644
> --- a/src/intel/tools/aubinator.c
> +++ b/src/intel/tools/aubinator.c
> @@ -1014,6 +1014,12 @@ setup_pager(void)
>  static void
>  print_help(FILE *file)
>  {
> +   const char *progname;
> +#if defined(__GLIBC__) || defined(__CYGWIN__)
> +   progname = program_invocation_short_name;
> +#else
> +   progname = getprogname();
> +#endif
> fprintf(file,
> "Usage: %s [OPTION]... FILE\n"
> "Decode aub file contents.\n\n"
> @@ -1025,7 +1031,7 @@ print_help(FILE *file)
> "if omitted), 'always', or 'never'\n"
> "  --no-pager  don't launch pager\n"
> "  --no-offsetsdon't print instruction offsets\n",
> -   basename(program_invocation_name));
> +   basename(progname));
>  }
>
>  static bool
> --
> 2.9.3
>
> ___
> 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