You should only see the MIT license for all Mesa contributions that
don't import external source code.
Marek
On Tue, Feb 13, 2024 at 5:23 AM George Karpathios wrote:
>
> Hi everyone,
>
> I'd like to bundle Lavapipe's binary that I've built (also contains LLVM
> thanks to static linking) with a
Gallium looks like it was just a copy of DX10, and likely many things were
known from DX10 in advance before anything started. Vulkanium doesn't have
anything to draw inspiration from. It's a completely unexplored idea.
AMD's PAL is the same idea as Gallium. It's used to implement Vulkan, DX,
Hi,
All Mesa libraries must come from the same build so as not to be
rejected at runtime.
Marek
On Mon, Dec 25, 2023 at 7:15 AM Mischa Baars wrote:
>
> Hello,
>
> I was going over MesaGL Blending when I discovered an issue that needs
> fixing. The problem is that when I compile and install a
There is a possibility to have robust contexts for all apps within a
window system when apps themselves are not robust.
If an app is robust, losing a context skips all following API calls.
The app must recreate its context and resources and continue.
When an app is not robust, losing a context
Please follow https://github.com/marekolsak/marek-build/
Marek
On Wed, Jul 12, 2023 at 11:55 AM Chen, Jinyi (Joey) wrote:
>
> [AMD Official Use Only - General]
>
>
> Hi,
>
>
> I have built and install mesa driver. I install it to system so xorg boots up
> with it. But I am encountering black
If there is a hash collision, it will cause a GPU hang. A cryptographic
hash function reduces that chance to practically zero.
Marek
On Thu, Jun 29, 2023, 07:04 mikolajlubiak1337
wrote:
> Hi,
> I have recently read Phoronix article[1] about you switching to BLAKE3
> instead of SHA1.
> If
I don't think u_format.csv can describe it. It only describes formats of
pixels in a single plane. All formats that have multiple planes where a
single pixel stores only a subset of its bits in each plane are handled as
special cases. Drivers also don't support such formats directly. For
example,
That's a good idea.
Marek
On Wed, Oct 5, 2022, 11:22 Erik Faye-Lund
wrote:
> On Wed, 2022-10-05 at 08:20 -0400, Alyssa Rosenzweig wrote:
> > + for not requiring rb/ab tags ...
>
> I think it's time to think about making this change all over Mesa as
> well. We're deeply in bed with GitLab by
Removing mainline drivers from the build system of Amber is a good idea.
Marek
On Fri, Sep 23, 2022, 06:33 Filip Gawin wrote:
> Hi, recently I've seen case of user been using Amber when hardware was
> supported by mainline mesa. This gave me a couple of thoughts.
>
> 1) Users don't correlate
Git stores all commits. Removing files at the top of main doesn't make the
repository smaller. It actually makes it bigger. Forking the repository
would also double the size on the server.
Marek
On Fri, Sep 23, 2022, 06:33 Filip Gawin wrote:
> Hi, recently I've seen case of user been using
ues?
>
> Timur
>
> On Thu, 2022-07-14 at 05:28 -0400, Marek Olšák wrote:
> > Hi,
> >
> > Gitlab emails are difficult to filter because issues and MRs are not
> > easy to distinguish. I know that Matt has a script which does this,
> > but since that was k
Hi,
Gitlab emails are difficult to filter because issues and MRs are not easy
to distinguish. I know that Matt has a script which does this, but since
that was kind of difficult for me to set up, I resorted to these filters
instead and they work pretty well.
Matches: from:gitlab ("created a
> I'd love to see Mesa used to bring Vulkan to consoles!
Ever heard of Steam Deck? ;)
Marek
On Mon, Jun 6, 2022 at 12:59 PM Jason Ekstrand wrote:
> On Mon, Jun 6, 2022 at 11:38 AM Jesse Natalie
> wrote:
>
>> (Hopefully this goes through and not to spam like last time I tried to
>> respond…)
> - Does it make sense to move to SPIR-V?
No, it doesn't make any sense whatsoever.
Marek
On Wed, Jan 19, 2022 at 8:17 PM Abel Bernabeu <
abel.berna...@esperantotech.com> wrote:
> Hi,
>
> My name Abel Bernabeu and I currently chair the Graphics and ML Special
> Interest Group within RISC-V.
>
Hi,
"is_used_once" within an inexact transformation in nir_opt_algebraic can
lead to geometry differences with multi-pass rendering, causing incorrect
output. Here's an example to proof this:
Let's assume there is a pass that writes out some intermediate value from
the position calculation as a
The ac_surface_meta_address_test timeout occurs rarely and it's because the
test is computationally demanding. It's also possible the machine got
slower for some reason.
Marek
On Fri, Jan 7, 2022 at 12:32 PM Emma Anholt wrote:
> On Fri, Jan 7, 2022 at 6:18 AM Connor Abbott wrote:
> >
> >
I remember that it wasn't unusual on Windows to define malloc, calloc,
strdup, and free macros to redirect those calls to custom wrappers. That
would eliminate the need to have non-standard names like MALLOC.
There is also the pipe_reference debug code. Is anybody using that?
Marek
On Sun.,
While the current directory structure is confusing, the new suggested
directory structure might not be helpful because GL is more spread out
anyway.
mapi is libglapi, so it seems to be its own thing, not a gallium thing
glx is libgl, same thing.
egl is libegl, same thing.
... unless we want to
Hi,
1. If this happens, let's call it src/gallium/frontends/gl.
3. The src directory already has too much stuff.
Marek
On Mon, Dec 6, 2021 at 6:51 PM Dylan Baker wrote:
> Classic is gone, and the cleanups have begun, obviously. There is
> another cleanup that I had in mind, which is moving
https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/222
On Fri, Oct 15, 2021 at 3:27 PM Marek Olšák wrote:
> Hi,
>
> I just enabled glvnd and noticed the performance is much lower.
>
> glxgears: 14% perf drop
> glvnd off: ~28000 FPS
> glvnd on: ~24000 FPS
>
> vi
Hi,
I just enabled glvnd and noticed the performance is much lower.
glxgears: 14% perf drop
glvnd off: ~28000 FPS
glvnd on: ~24000 FPS
viewperf13 (some subtest): 11% perf drop
glvnd off: 201 FPS
glvnd on: 179 FPS
glvnd spends a lot of time in libGL.so and some in libGLdispatch.so.
The "off"
I'd like gitlab macros :rb: and :ab: that put the tags into the comment.
Marek
On Tue, Oct 12, 2021 at 5:01 PM Jason Ekstrand wrote:
> On Tue, Oct 12, 2021 at 3:56 PM apinheiro wrote:
> >
> >
> > On 12/10/21 13:55, Alyssa Rosenzweig wrote:
> >
> > I would love to see this be the process
Despite all the time it takes to add the tags and force-push, I have no
objection to doing that. It captures per-commit reviews well.
Marek
On Thu, Oct 7, 2021 at 1:17 PM Eero Tamminen
wrote:
> Hi,
>
> On 7.10.2021 19.51, Daniel Stone wrote:
> > On Thu, 7 Oct 2021 at 09:38, Eero Tamminen
>
Yes, this would be useful.
Marek
On Fri, Sep 10, 2021 at 1:20 PM Timur Kristóf
wrote:
> Hi,
>
> We've been recently working on tracking down some "mysterious" crashes
> that some users experienced on distro builds of mesa but we couldn't
> reproduce locally, until we found out about
against such behavior because it will receive them too.
I don't know if that would work with dma_fence.
Marek
On Thu, Jun 17, 2021 at 3:04 PM Daniel Vetter wrote:
> On Thu, Jun 17, 2021 at 02:28:06PM -0400, Marek Olšák wrote:
> > The kernel will know who should touch the implicit-sync
; As long as we can figure out who touched to a certain sync object last
> that
> > would indeed work, yes.
>
> Don't you need to know who will touch it next, i.e. who is holding up your
> fence? Or maybe I'm just again totally confused.
> -Daniel
>
> >
> > Christia
that.
>
> If the hardware says that seq - 1 was written fine, but seq is missing
> then the kernel blames whoever was supposed to write seq.
>
> Just pieping the write through a privileged instance should be fine to
> make sure that we don't run into issues.
>
> Christian.
>
Hi Daniel,
We just talked about this whole topic internally and we came up to the
conclusion that the hardware needs to understand sync object handles and
have high-level wait and signal operations in the command stream. Sync
objects will be backed by memory, but they won't be readable or
On Thu., Jun. 3, 2021, 15:18 Daniel Vetter, wrote:
> On Thu, Jun 3, 2021 at 7:53 PM Marek Olšák wrote:
> >
> > Daniel, I think what you are suggesting is that we need to enable user
> queues with the drm scheduler and dma_fence first, and once that works, we
> can
it or the
hw does it. It's the same code, just in a different place.
Thanks,
Marek
On Thu, Jun 3, 2021 at 7:22 AM Daniel Vetter wrote:
> On Thu, Jun 3, 2021 at 12:55 PM Marek Olšák wrote:
> >
> > On Thu., Jun. 3, 2021, 06:03 Daniel Vetter, wrote:
> >>
> >> On Thu, Jun 03
On Thu., Jun. 3, 2021, 06:03 Daniel Vetter, wrote:
> On Thu, Jun 03, 2021 at 04:20:18AM -0400, Marek Olšák wrote:
> > On Thu, Jun 3, 2021 at 3:47 AM Daniel Vetter wrote:
> >
> > > On Wed, Jun 02, 2021 at 11:16:39PM -0400, Marek Olšák wrote:
> > > > On Wed,
On Thu, Jun 3, 2021 at 3:47 AM Daniel Vetter wrote:
> On Wed, Jun 02, 2021 at 11:16:39PM -0400, Marek Olšák wrote:
> > On Wed, Jun 2, 2021 at 2:48 PM Daniel Vetter wrote:
> >
> > > On Wed, Jun 02, 2021 at 05:38:51AM -0400, Marek Olšák wrote:
> > > > On Wed
On Wed, Jun 2, 2021 at 2:48 PM Daniel Vetter wrote:
> On Wed, Jun 02, 2021 at 05:38:51AM -0400, Marek Olšák wrote:
> > On Wed, Jun 2, 2021 at 5:34 AM Marek Olšák wrote:
> >
> > > Yes, we can't break anything because we don't want to complicate things
> > > f
On Wed, Jun 2, 2021 at 5:44 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am 02.06.21 um 10:57 schrieb Daniel Stone:
> > Hi Christian,
> >
> > On Tue, 1 Jun 2021 at 13:51, Christian König
> > wrote:
> >> Am 01.06.21 um 14:30 schrieb Daniel Vetter:
> >>> If you want to enable
On Wed, Jun 2, 2021 at 5:34 AM Marek Olšák wrote:
> Yes, we can't break anything because we don't want to complicate things
> for us. It's pretty much all NAK'd already. We are trying to gather more
> knowledge and then make better decisions.
>
> The idea we are considering is th
Yes, we can't break anything because we don't want to complicate things for
us. It's pretty much all NAK'd already. We are trying to gather more
knowledge and then make better decisions.
The idea we are considering is that we'll expose memory-based sync objects
to userspace for read only, and the
On 2021-06-01 12:21 p.m., Christian König wrote:
> >>>> Am 01.06.21 um 11:02 schrieb Michel Dänzer:
> >>>>> On 2021-05-27 11:51 p.m., Marek Olšák wrote:
> >>>>>> 3) Compositors (and other privileged processes, and display
> flipping
not possible to know which
process is guilty (all processes holding the buffer handle would be
suspects).
Marek
On Fri, May 28, 2021 at 6:25 PM Marek Olšák wrote:
> If both implicit and explicit synchronization are handled the same, then
> the kernel won't be able to identify the process that
blem are the sync_files for Android, since they are really
> not easy to support at all. If Android wants to support user queues we
> would probably have to do some changes there.
>
> Regards,
> Christian.
>
> Am 27.05.21 um 23:51 schrieb Marek Olšák:
>
> Hi,
>
> Sin
Hi,
Since Christian believes that we can't deadlock the kernel with some
changes there, we just need to make everything nice for userspace too.
Instead of explaining how it will work, I will explain the cases where
future hardware (and its kernel driver) will break existing userspace in
order to
I see some mentions of XNACK and recoverable page faults. Note that all
gaming AMD hw that has userspace queues doesn't have XNACK, so there is no
overhead in compute units. My understanding is that recoverable page faults
are still supported without XNACK, but instead of the compute unit
out
concurrency/preemption. Is this now safe enough for dma_fence?
Marek
On Mon, May 3, 2021 at 4:36 PM Marek Olšák wrote:
> What about direct submit from the kernel where the process still has write
> access to the GPU ring buffer but doesn't use it? I think that solves your
> preemp
e a dma_fence except for inside the ioctl which submits the work
> and only after any necessary memory has been allocated. That's a
> pretty stiff requirement. We may still be able to interact with
> userspace a bit more explicitly but I think it throws any notion of
> userspace direct s
On Wed, Apr 28, 2021 at 5:07 AM Michel Dänzer wrote:
> On 2021-04-28 8:59 a.m., Christian König wrote:
> > Hi Dave,
> >
> > Am 27.04.21 um 21:23 schrieb Marek Olšák:
> >> Supporting interop with any device is always possible. It depends on
> which drivers we nee
On Wed., Apr. 28, 2021, 00:01 Jason Ekstrand, wrote:
> On Tue, Apr 27, 2021 at 4:59 PM Marek Olšák wrote:
> >
> > Jason, both memory-based signalling as well as interrupt-based
> signalling to the CPU would be supported by amdgpu. External devices don't
> need to supp
the picture.
Marek
On Tue, Apr 27, 2021 at 3:41 PM Jason Ekstrand wrote:
> Trying to figure out which e-mail in this mess is the right one to reply
> to
>
> On Tue, Apr 27, 2021 at 12:31 PM Lucas Stach
> wrote:
> >
> > Hi,
> >
> > Am Dienstag, dem 27
Supporting interop with any device is always possible. It depends on which
drivers we need to interoperate with and update them. We've already found
the path forward for amdgpu. We just need to find out how many other
drivers need to be updated and evaluate the cost/benefit aspect.
Marek
On Tue,
same problem in the kernel.
>
> The good news is I think we can relatively easily convert i915 and older
> amdgpu device to something which is compatible with user fences.
>
> So yes, getting that fixed case by case should work.
>
> Christian
>
> Am 27.04.21 um 14:46 schr
ot;external -> amd" dependency too?
Marek
On Tue., Apr. 27, 2021, 08:15 Daniel Vetter, wrote:
> On Tue, Apr 27, 2021 at 2:11 PM Marek Olšák wrote:
> > Ok. I'll interpret this as "yes, it will work, let's do it".
>
> It works if all you care about is drm/
That could only be a problem for A+I Laptops.
>
> Memory management will just work with preemption fences which pause the
> user queues of a process before evicting something. That will be a
> dma_fence, but also a well known approach.
>
> Christian.
>
> Am 27.04.21 um 13:49 sc
Vetter, wrote:
> On Mon, Apr 26, 2021 at 04:59:28PM -0400, Marek Olšák wrote:
> > Thanks everybody. The initial proposal is dead. Here are some thoughts on
> > how to do it differently.
> >
> > I think we can have direct command submission from userspace via
> > m
Thanks everybody. The initial proposal is dead. Here are some thoughts on
how to do it differently.
I think we can have direct command submission from userspace via
memory-mapped queues ("user queues") without changing window systems.
The memory management doesn't have to use GPU page faults
On Tue, Apr 20, 2021 at 2:39 PM Daniel Vetter wrote:
> On Tue, Apr 20, 2021 at 6:25 PM Marek Olšák wrote:
> >
> > Daniel, imagine hardware that can only do what Windows does: future
> fences signalled by userspace whenever userspace wants, and no kernel
> queu
Daniel, imagine hardware that can only do what Windows does: future fences
signalled by userspace whenever userspace wants, and no kernel queues like
we have today.
The only reason why current AMD GPUs work is because they have a ring
buffer per queue with pointers to userspace command buffers
kstrand:
> > > Not going to comment on everything on the first pass...
> > >
> > > On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote:
> > >> Hi,
> > >>
> > >> This is our initial proposal for explicit fences everywhere and new
> memory m
ocesses and how
resilient they would be to segfaults.
Marek
On Mon, Apr 19, 2021 at 11:48 AM Jason Ekstrand
wrote:
> Not going to comment on everything on the first pass...
>
> On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote:
> >
> > Hi,
> >
> > This is o
Hi,
This is our initial proposal for explicit fences everywhere and new memory
management that doesn't use BO fences. It's a redesign of how Linux
graphics drivers work, and it can coexist with what we have now.
*1. Introduction*
(skip this if you are already sold on explicit fences)
The
; "lts" branch/tree/whatever? Some of the "fixes" will require large-ish
> changes to the driver...
>
> Cheers,
>
> -ilia
>
> On Mon, Mar 29, 2021 at 6:48 PM Marek Olšák wrote:
> >
> > Alright that's r300 and swr that are going to fi
Alright that's r300 and swr that are going to find a new home in the lts
branch. Do any other gallium drivers want to join them?
Marek
On Mon., Mar. 29, 2021, 13:51 Zielinski, Jan,
wrote:
> On Thursday, March 25, 2021 8:47 Marek Olšák wrote:
> > Same thinking could be applied to othe
On Thu., Mar. 25, 2021, 12:14 Dylan Baker, wrote:
> By delete I mean "remove -Dgallium-drivers and -Dvulkan-drivers" from
> Meson. Maybe it makes sense to keep gallium for r300? But how many r300
> breakages have we had in recent memory?
>
We don't have any recent information on the status of
+1
We still have some CPU overhead performance targets we haven't reached. One
of them is to decrease CPU overhead for one benchmark 4 times compared to
everything we already have in master. I don't know how we are going to do
that, but we'll try.
Marek
On Mon, Mar 22, 2021 at 6:15 PM Dylan
d
> corresponding sample pattern)
>
> None of this would be throwaway work: the SampleMaskIn are correct and could
> be used for full MSAA support in the future too, and the conservative
> rasterization could be a feature on its own right too eventually.
>
> Jose
>
> ----
Hi,
How do you apply the fixes?
Is it possible to pick a random commit in master and apply all fixes that
are newer than that commit?
Thanks,
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Hi,
llvmpipe could implement line and polygon smoothing by rasterizing in MSAA
and passing the coverage to SampleMaskIn in the fragment shader, but doing
Z/S tests and color writes and everything else single-sampled. Then,
FragColor.a *= bitcount(SampleMaskIn) / (float)num_samples. It's roughly
If CPU overhead is a problem, mesa_glthread=true is likely to give you a
large performance boost and it should be conformant.
Marek
Marek
On Fri., Oct. 16, 2020, 00:28 Jason Ekstrand, wrote:
> Generally, you need to be careful with forcing no_error. Some apps
> rely on gl errors to check for
I think it's just going to get more messy and complicated for people who
don't want to learn or use another language. Mesa already requires people
to know C, Python, and now newly Gitlab CI scripts just to get stuff done
and merged. Another language would only exacerbate the issue and steepen
the
Hi,
Does the issue happen with mesa/master?
Marek
On Mon, Sep 28, 2020 at 3:11 AM Zhu Yijun wrote:
> hi all,
>
> I use qemu/kvm to boot some android guests with virgl and run apks,
> the host kernel invokes oom after several hours.
>
> 1. From /proc/meminfo, I see the 'SUnreclaim' is the
ll check.
>>
>> On Sun, May 10, 2020 at 10:26 AM Dave Airlie wrote:
>>
>>> On Wed, 27 Jun 2018 at 06:36, Denis Pauk wrote:
>>> >
>>> > Reuse code shared with mesa/main/texcompress_bptc.
>>> >
>>> > v2: Use block decompress
Hi,
I don't know if you have been following gitlab, but there are a few
cleanups that I have been considering doing.
Rename PIPE_TRANSFER flags to PIPE_MAP, and pipe_transfer_usage to
pipe_map_flags:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5749
Other proposed renames:
No objections from me.
Marek
On Mon, Aug 3, 2020 at 6:07 AM Gert Wollny
wrote:
> Hi,
>
> has anybody any objection to adding a new cap
> PIPE_CAP_NIR_ATOMICS_AS_DEREF, see:
>
>
>
+ Leo
On Sat., Jun. 27, 2020, 06:30 Jahnvi Gupta, wrote:
> Greeting!
> I want to contribute to Project "Unit and performance tests for VA-API".
> Please update me on the status of the project. I would also like to know
> any Prerequisite for the project. Some pointers for getting started will
vectorized, so mediump is
a tough sell at the moment.
Marek
On Mon, May 4, 2020 at 7:03 PM Rob Clark wrote:
> On Mon, May 4, 2020 at 11:44 AM Marek Olšák wrote:
> >
> > Hi,
> >
> > This is the status of mediump support in Mesa. What I listed is what AMD
> GPU
Hi,
This is the status of mediump support in Mesa. What I listed is what AMD
GPUs can do. "Yes" means what Mesa supports.
*Feature* *FP16 support* *Int16 support*
ALU Yes No
Uniforms No No
VS in No No
VS out / FS in No No
FS out No No
TCS, TES, GS out / in No No
Sampler coordinates (only coord,
I don't think this was preventable given how many things went wrong.
Sometimes we have to accept that shit happens. We can fix that in the next
release.
Marek
On Thu., Apr. 23, 2020, 07:01 Danylo Piliaiev,
wrote:
> I want to sum up what happened from my perspective, I think it could be
>
The first milestone:
- make src/compiler a standalone lib
is done: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4400
Marek
On Mon, Mar 30, 2020 at 11:40 AM Kristian Høgsberg
wrote:
> On Mon, Mar 30, 2020, 7:59 AM Adam Jackson wrote:
>
>> On Sun, 2020-03-29 at 09:45 -0700,
Hi James,
We use gitlab for merge requests and pushing:
https://www.mesa3d.org/submittingpatches.html
Marek
On Mon, Apr 6, 2020 at 2:12 PM James Zhu wrote:
> Fix Segmentation fault duiring vaapi enc test on Arcturus.
>
> Signed-off-by: James Zhu
> ---
>
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 #in
- don't include src/mesa in other places
- split classic drivers into src/mesa_classic
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
&g
Hi Alexandros,
I recommend submitting more merge requests to have a bigger commit history.
Ultimately the virgl maintainers will have to decide this.
Marek
On Wed, Mar 25, 2020 at 10:00 AM Alexandros Frantzis <
alexandros.frant...@collabora.com> wrote:
> Hi everyone,
>
> I would like to
In the long term we should reduce the complexity of the project. scons is a
maintenance burden. Every time I break the scons build and the CI reports
it, can I politely ask you to fix my MR instead of me doing it? Then at
least the real maintenance cost would be known to scons supporters, instead
On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke
wrote:
> On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium
> > translation.
> >
> > 1) Move classic drive
Hi,
I think the problem is that src/mesa is linked using "link_with", while
gallium drivers are linked using "dependencies" in meson, but I might be
wrong.
It looks like meson only compiles the dependencies in "link_with" in
parallel, then waits for completion, and then meson looks at
On Thu., Mar. 19, 2020, 06:51 Daniel Vetter, wrote:
> On Tue, Mar 17, 2020 at 11:01:57AM +0100, Michel Dänzer wrote:
> > On 2020-03-16 7:33 p.m., Marek Olšák wrote:
> > > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer
> wrote:
> > >> On 2020-0
On Tue., Mar. 17, 2020, 06:02 Michel Dänzer, wrote:
> On 2020-03-16 7:33 p.m., Marek Olšák wrote:
> > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer
> wrote:
> >> On 2020-03-16 4:50 a.m., Marek Olšák wrote:
> >>> The synchronization works because the Mes
On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer wrote:
> On 2020-03-16 4:50 a.m., Marek Olšák wrote:
> > The synchronization works because the Mesa driver waits for idle (drains
> > the GFX pipeline) at the end of command buffers and there is only 1
> > graphics queue, so
o have it corrected. People continue
> claiming that AMD is somehow special but I have yet to grasp what makes it
> so. (Not that anyone has bothered to try all that hard to explain it.)
>
>
> --Jason
>
> On March 13, 2020 21:03:21 Marek Olšák wrote:
>
>> There is
There is no synchronization between processes (e.g. 3D app and compositor)
within X on AMD hw. It works because of some hacks in Mesa.
Marek
On Wed, Mar 11, 2020 at 1:31 PM Jason Ekstrand wrote:
> All,
>
> Sorry for casting such a broad net with this one. I'm sure most people
> who reply will
For Mesa, we could run CI only when Marge pushes, so that it's a strictly
pre-merge CI.
Marek
On Sat., Feb. 29, 2020, 17:20 Nicolas Dufresne,
wrote:
> Le samedi 29 février 2020 à 15:54 -0600, Jason Ekstrand a écrit :
> > On Sat, Feb 29, 2020 at 3:47 PM Timur Kristóf
> wrote:
> > > On Sat,
Rb. I'm on the phone.
M.
On Sat., Feb. 29, 2020, 22:53 Ilia Mirkin, wrote:
> The bitmask is _EffEnabledNonZeroDivisor, so no need to invert it before
> returning.
>
> Fixes: fd6636ebc06d (st/mesa: simplify determination whether a draw needs
> min/max index)
> Signed-off-by: Ilia Mirkin
> ---
Done. You now have the Developer status.
Marek
On Fri, Feb 14, 2020 at 3:52 AM Hyunjun Ko wrote:
> Hi,
>
> I'm Hyunjun Ko, working on Mesa actively nowadays.
> I've been working for over 1 year since I dived into this attractive
> project and mainly focusing on freedreno.
>
> Now I feel it's
Yeah I guess it reduces instruction cache misses, but then other codepaths
are likely to get more misses.
Does it do anything smarter?
Marek
On Thu., Feb. 13, 2020, 17:52 Dave Airlie, wrote:
> On Fri, 14 Feb 2020 at 08:22, Marek Olšák wrote:
> >
> > I wonder what PGO really
we found was
> that it
> made the specific workloads we threw at it much faster, but it made every
> real
> world use case I tried (playing a game, running piglit, gnome) slower,
> often
> significantly so.
>
> The hard part is not setting up pgo, it's getting the right training data.
>
>
, 13:16 Dylan Baker, wrote:
> meson has buildtins for both of these, -Db_lto=true turns on lto, for pgo
> you
> would run:
>
> meson build -Db_pgo=generate
> ninja -C build
>
> meson configure build -Db_pgo=use
> ninja -C build
>
> Quoting Marek Olšák (2020-02-12 10
m 12.02.2020 19:46, schrieb Marek Olšák:
> > How do you enable LTO+PGO? Is it something we could enable by default
> > for release builds?
> >
> > Marek
>
> I think we can achieve this.
>
> I'm running with LTO+PGO 'release' since late December (around
> Christm
How do you enable LTO+PGO? Is it something we could enable by default for
release builds?
Marek
On Wed, Feb 12, 2020 at 1:56 AM Dieter Nützel wrote:
> Hello Gert,
>
> your merge 'broke' LTO and then later on PGO compilation/linking.
>
> I do generally compiling with
Feel free to make the branchpoint now. We don't really need to wait for
anybody. Drivers that need fixing can have their fixes backported later.
The longer we wait, the greater the chance that somebody will introduce new
regressions in master.
Marek
On Wed, Jan 29, 2020 at 11:02 PM Jason
I've added the VBO & CSO optimizations into the list. Let me know if this
is something you would like in 20.0.
Marek
On Wed, Jan 22, 2020 at 1:27 PM Dylan Baker wrote:
> Hi list, due to some last minute changes in plan I'll be managing the 20.0
> release. The release calendar has been updated,
Pushed, thanks!
Marek
On Thu, Dec 19, 2019 at 2:22 PM Neha Bhende wrote:
> Since we are using st_common_variant while creating variant for vertext
> program, we can release tokens created in st_create_vp_variant which
> are already stored in respective states.
> This fix memory leak found with
Hi Eric,
Does it mean people no longer need push access, because Marge can merge
anything?
So any random person can create a merge request and immediately assign it
to Marge to merge it?
Marek
On Fri, Dec 13, 2019 at 4:35 PM Eric Anholt wrote:
> I finally got back around to experimenting
On Wed, Dec 11, 2019 at 7:47 PM Eric Engestrom wrote:
> On 2019-12-11 at 23:46, Timothy Arceri wrote:
> > On 12/12/19 10:38 am, Eric Engestrom wrote:
> > > On 2019-12-11 at 23:09, Eric Anholt wrote:
> > >> On Wed, Dec 11, 2019 at 2:35 PM Timothy Arceri
> wrote:
> > >>>
> > >>> Hi,
> > >>>
> >
1 - 100 of 12096 matches
Mail list logo
