[Mesa-dev] [ANNOUNCE] mesa 21.1.5

2021-07-14 Thread Eric Engestrom
Hello everyone,

The fifth bugfix release for the 21.1 branch is now available.
The next one is scheduled for two weeks from now, on July 28.

Cheers,
Eric

---

Alyssa Rosenzweig (1):
  nir: Fix constant folding for irhadd/urhadd

Bas Nieuwenhuizen (1):
  ac/surface: Handle non-retiled displayable DCC correctly for modifiers.

Connor Abbott (1):
  ir3: Fix infinite loop in scheduler when splitting

Danylo Piliaiev (1):
  glsl: Prohibit implicit conversion of mem parameter in atomicOP functions

Dave Airlie (1):
  draw: fix tessellation output vertex size calculation

Eric Engestrom (6):
  .pick_status.json: Update to e4f762ac346f31fc1fd201aecdc375348be5075f
  zink: mark a bunch of zink-piglit-quick_gl tests as flakes
  .pick_status.json: Update to c704bb630d21e0a30500e9d8f42493ede3cc55ae
  .pick_status.json: Mark e5d158881b3e12270521d7081b4bba0ac2108d2e as 
denominated
  docs: add release notes for 21.1.5
  VERSION: bump for 21.1.5

Heinrich Fink (1):
  softpipe: add missing sentinel to debug option array

Jason Ekstrand (1):
  iris: Don't leak the surface if uncompressed re-interp fails

Lionel Landwerlin (1):
  intel/perf: use the right popcount for 64bits

Marek Olšák (2):
  ac/surface/tests: fix the ARM build
  radeonsi,radv: fix a late alloc deadlock with <= 6 CUs per SA

Michel Dänzer (3):
  Convert most remaining free-form fall-through comments to FALLTHROUGH
  osmesa: Replace default case FALLTHROUGH annotation by following return
  Fix up leftover "state_trackers" references to "frontends"

Pierre-Eric Pelloux-Prayer (4):
  radeonsi: fix fb_too_small condition
  radeonsi/gfx7: always sync pfp/me
  ac/surface: don't print stencil info if tex has no stencil
  radeonsi/driconf: add workaround for SpaceEngine

Qiang Yu (1):
  st/mesa: fix size miss match for some check

Rob Clark (2):
  freedreno: Consolidate needs_flush and clearing last_fence
  freedreno/a6xx: Fix framebuffer_barrier crash

Samuel Pitoiset (2):
  radv: disable DCC for DOOM 2016 and Wolfenstein II
  aco: fix shared_atomic_comp_swap if the second source isn't a VGPR

Thomas H.P. Andersen (3):
  nir: return progress from nir_lower_packing
  nir/ifind_msb_rev: fix input check
  broadcom/compiler: fix add vs. mul

Timothy Arceri (7):
  util/tests: initialise key in cache_test
  mesa: don't crash on incorrect texture use
  i965: don't crash on incorrect texture use
  util/driconf: add new ignore_write_to_readonly_var workaround
  util: add some workarounds for the game Luna Sky
  glsl: force_glsl_version to shaders with no defined version
  util/radeonsi: add radeonsi workaround for Nuclear Throne

Vinson Lee (1):
  st/xa: Mark default xa_get_pipe_format case unreachable.

Yevhenii Kolesnikov (1):
  intel: fix leaking memory on shader creation

git tag: mesa-21.1.5

https://mesa.freedesktop.org/archive/mesa-21.1.5.tar.xz
SHA256: 022c7293074aeeced2278c872db4fa693147c70f8595b076cf3f1ef81520766d  
mesa-21.1.5.tar.xz
SHA512: 
d9e0e1b6a1d717febee2aa67b06620c9a21e061ea7e594be5b4c382db1ed6f5acf5d13a75a9f2bba9c32621466ebc816708606e16e8b34700d987158fd8f0b7b
  mesa-21.1.5.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-21.1.5.tar.xz.sig

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


[Mesa-dev] Help needed for EVoC/GSoC/Outreachy

2021-07-14 Thread Lyude Paul
Hi! As some of you might already be aware, after helping out X.org
project the previous years with regards to student outreach, Trevor
decided to retire from this position in hopes that someone else will be
able to step up and take on these responsibilities. As such, we're
trying to find people who would be willing to volunteer their time to
help out with getting us involved once again in student outreach
programs.

In the past, X.org has been active in the GSoC program, occasionally
Outreachy, and our own EVoC program. As of 2021 though, GSoC decided to
shorten the amount of time allocated for a student to work on their
project. This unfortunately posed some problems for
X.org/freedesktop.org as a lot of the potential work that would have
been good for us to have students working on wouldn't really fit within
the new GSoC timeframe. While it's certainly possible that there will be
projects that come up in the future which do fit into this new timeline,
we think it'd be a good idea to step up our involvement again with
Outreachy where the program is a good bit more flexible then GSoC. We've
also had pretty good experience working with the Outreachy candidates
we've had in the past.

The other main topic of discussion is around the fact that our own
program, EVoC, hasn't really had anyone available to volunteer to help
run it for a while now. For those who aren't aware, EVoC is a program
similar to Google Summer of Code that X.org started running with much
more relaxed requirements then GSoC/Outreachy in order to help fill the
gaps for any exceptional cases with students who would otherwise be left
out by the requirements for GSoC/Outreachy. Typically though, EVoC is
usually considered the last resort after a student has tried getting
into GSoC/Outreachy.

So, the two biggest things that we need are:
* Admin volunteer(s)
* Mentors, mentors, mentors! We really need these the most.

So, what responsibilities would being an admin for this entail?

* Fielding questions from potential GSoC/EVoC/Outreachy participants.
  Most of these students are just looking for simple details of how
  these programs work and are looking for project ideas. Responding to
  these inquiries is mostly just a matter of pointing students to
  various pages on our wiki or replying with form/stock replies. Most of
  the students at this phase expect to be handed a project and a mentor,
  and therefore end up learning that they will need to come up with
  their own project and mentor.
* For the small handful of students that make it to the next phase and
  figure out a project idea, they then need to find a mentor. Usually
  the admin will help out by taking a look at who proposed the project
  idea, and/or looking through commit messages and mailing list history
  to try to find someone who would be a good fit and willing to mentor
  the student. Sometimes this happens quickly, and sometimes it requires
  poking a lot of people - and occasionally, there might not always be a
  mentor to be found.
* If we have a student, project, and mentor then the next step is having
  the student write up a proposal. Many students start out with
  over-simplified proposals, so a lot of this work is just gently
  nudging students and getting them to refine their work items into a
  week-by-week synopsis. There's usually a good bit of back and forth
  with the student's proposal, and occasionally the mentor may be
  involved with this step.
* The admin then works with the student to come up with a timeline for
  their work, taking into account any vacation time the student may
  have, along with coordinating the frequency/type of meetings that
  will happen between the student and the mentor. If the mentor is
  unable to attend all of these meetings, it's usually up to the admin
  to check in with the student to see how they are progressing and
  potentially provide them tips if they get stuck.

As for being a mentor, it's pretty much as simple as it sounds: you work
with students who have projects to help familiarize them with the
project at hand, help them out wherever needed, check in on their
progress, and guide them along the way towards reaching their project
goal along with grading their work.

Please help spread the word on this, and contact anyone you know who
might be involved with this! We'll be happy to provide more information
on how you can get started. Remember, folks like myself wouldn't be in
this community without projects like GSoC :).

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

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


[Mesa-dev] [ANNOUNCE] mesa 21.2.0-rc1

2021-07-14 Thread Dylan Baker
Hi list,

It's that time again, Mesa 21.2.0-rc1 is now available for consumption.
This release is is packed with all of the good stuff that's been going
on for the last 3 months. As always, please report any issues you run
into and please test throughly.

Cheers,
Dylan

git tag: mesa-21.2.0-rc1

https://mesa.freedesktop.org/archive/mesa-21.2.0-rc1.tar.xz
SHA256: 1b03a79867e7fd352f32212a30af236ca4494e4aaa12e0e0be51a95803fc2667  
mesa-21.2.0-rc1.tar.xz
SHA512: 
0a06162ec46275f8b6db1ab35d3e3e0ed4e31f7efb01c3e5649c89a1b8f39edc600c619fb8b8ba30f55b9fea0408575e56223833f0a01735604ff255e2143f40
  mesa-21.2.0-rc1.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-21.2.0-rc1.tar.xz.sig

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