On Tue, 25 Jun 2019 at 11:08, Chih-Wei Huang wrote:
>
> There are several issues in the current Android makefiles. Though they
> may not affect the functionalities, it's ugly and unprofessional.
>
> * Add unnecessary LOCAL_EXPORT_C_INCLUDE_DIRS
> * Not export necessary include paths
> * Add dummy
There are several issues in the current Android makefiles. Though they
may not affect the functionalities, it's ugly and unprofessional.
* Add unnecessary LOCAL_EXPORT_C_INCLUDE_DIRS
* Not export necessary include paths
* Add dummy libraries to LOCAL_WHOLE_STATIC_LIBRARIES
* Use unnecessary dummy
Hi,
This series is a prerequisite before enabling DCC for mipmapped color textures.
It basically allocates more metadata space and it adds mipmap support for color
decompressions on graphics and compute.
DCC for mipmaps is still disabled by default but I should be able to
enable it soon for GFX8.
Exactly what it says on the tin. Decode them and implement them.
Alyssa Rosenzweig (8):
panfrost/midgard: Add swizzle_of/mask_of helpers
panfrost/midgard: Fix 3D texture masks/swizzles
panfrost: Specify 3D in texture descriptor
panfrost: Implement 3D texture resource management
panfrost:
Hi,
This series implements user sample locations during explicit and automatic
(subpass) layout transitions as defined by VK_EXT_sample_locations.
Previously, HTILE was disabled for depth/stencil images that might need
sample locations because it was a bit tricky to implement.
The last patch of
Hi folks,
this is a collection of assorted patches that should help with driver
debugging:
- add driconf-style debug options in a convenient way
- some minor ddebug cleanups
- allow dumping aux context command streams
- allow force-syncing of compile threads
Please review!
Thanks,
Nicolai
--
.
Reviewed-by: Bas Nieuwenhuizen
for the series.
On Tue, Mar 19, 2019 at 9:28 AM Samuel Pitoiset
wrote:
>
> Hi,
>
> This series implements VK_KHR_8bit_storage for RADV. Original work
> is from Rhys Perry, I did rebase, update some patches and test.
>
> Please review,
> thanks!
>
> Rhys Perry (5):
Hi,
This series implements VK_KHR_8bit_storage for RADV. Original work
is from Rhys Perry, I did rebase, update some patches and test.
Please review,
thanks!
Rhys Perry (5):
ac/nir: implement 8-bit push constant, ssbo and ubo loads
ac/nir: implement 8-bit ssbo stores
ac/nir: add 8-bit type
From: Mathias Fröhlich
Hi all,
The following series introduces functions to map and unmap all
vbos stored in a vao. Make use of those functions where possible.
On that way cleanup and fix what comes up along the way.
The series also already removes half of the state that is tracked
using the _NE
Hi,
These uploads should have lower CPU overhead.
There are also some cleanups around the WRITE_DATA packet.
Please review.
Thanks,
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, 19 Nov 2018 10:54:04 +0200
Eleni Maria Stea wrote:
> Intel Gen7 GPUs don't have native support for ETC2 formats. We store
> the ETC2 images as RGBA in order to render them. This is a problem for
> GetCompressed* functions that should return compressed pixel values
> but return instead RGB
Intel Gen7 GPUs don't have native support for ETC2 formats. We store the
ETC2 images as RGBA in order to render them. This is a problem for
GetCompressed* functions that should return compressed pixel values but
return instead RGBA.
With these patches, we store the compressed image data in the mai
On 14/11/2018 22:38, Jason Ekstrand wrote:
> I just sent one more, "nir/lower_io: Add shared to get_io_offset_src"
> that's required for the pass to apply properly to shared vairables.
>
I have reviewed it too.
> Do we have any testing of shared variables with anything other than 32
> bits? D
I just sent one more, "nir/lower_io: Add shared to get_io_offset_src"
that's required for the pass to apply properly to shared vairables.
Do we have any testing of shared variables with anything other than 32
bits? Do we even test 64 bits? I'm begining to think that there are
basically zero test
Thanks a lot for this work. Patches 1-7 are,
Reviewed-by: Samuel Iglesias Gonsálvez
I will review patch 8 later, probably tomorrow.
Sam
On 14/11/2018 00:23, Jason Ekstrand wrote:
> In order to properly do all the different kinds of SSBO and SLM writes that
> we have in GL and Vulkan, we have
In order to properly do all the different kinds of SSBO and SLM writes that
we have in GL and Vulkan, we have to do some lowering. The hardware
doesn't have instructions for writing a N-bit vecM with an arbitrary
write-mask. Instead, we have byte scattered messages which work on a
scalar byte, wo
On 2018-09-10 9:02 p.m., Marek Olšák wrote:
> On Mon, Sep 10, 2018 at 10:45 AM, Michel Dänzer wrote:
>> On 2018-09-07 9:01 p.m., Marek Olšák wrote:
>>> On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer wrote:
On 2018-09-07 4:31 p.m., Marek Olšák wrote:
> On Fri, Sep 7, 2018, 4:34 AM Michel
On Mon, Sep 10, 2018 at 10:45 AM, Michel Dänzer wrote:
> On 2018-09-07 9:01 p.m., Marek Olšák wrote:
>> On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer wrote:
>>> On 2018-09-07 4:31 p.m., Marek Olšák wrote:
On Fri, Sep 7, 2018, 4:34 AM Michel Dänzer wrote:
> On 2018-09-06 10:56 p.m., Axe
On 2018-09-07 9:01 p.m., Marek Olšák wrote:
> On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer wrote:
>> On 2018-09-07 4:31 p.m., Marek Olšák wrote:
>>> On Fri, Sep 7, 2018, 4:34 AM Michel Dänzer wrote:
On 2018-09-06 10:56 p.m., Axel Davy wrote:
> I fear if we begin to do the work man
On Fri, Sep 7, 2018 at 3:34 PM, Alan Swanson wrote:
> On Fri, 2018-09-07 at 15:01 -0400, Marek Olšák wrote:
>> On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer
>> wrote:
>> > On 2018-09-07 4:31 p.m., Marek Olšák wrote:
>> > >
>> > > I don't think the performance can be worse than it is right now.
>
On Fri, 2018-09-07 at 15:01 -0400, Marek Olšák wrote:
> On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer
> wrote:
> > On 2018-09-07 4:31 p.m., Marek Olšák wrote:
> > >
> > > I don't think the performance can be worse than it is right now.
> >
> > In the worst case, all processes using OpenGL (or a
I'm changing the initial L3 cache number to this:
+static unsigned L3_cache_number;
+static once_flag init_cache_number_flag = ONCE_FLAG_INIT;
+
+static void
+util_init_cache_number(void)
+{
+ /* Get a semi-random number. */
+ int64_t t = os_time_get_nano();
+ L3_cache_number = (t ^ (t >> 8)
On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer wrote:
> On 2018-09-07 4:31 p.m., Marek Olšák wrote:
>> On Fri, Sep 7, 2018, 4:34 AM Michel Dänzer wrote:
>>> On 2018-09-06 10:56 p.m., Axel Davy wrote:
>>>
I fear if we begin to do the work manually, there won't be interest to
do that in t
On 2018-09-07 4:31 p.m., Marek Olšák wrote:
> On Fri, Sep 7, 2018, 4:34 AM Michel Dänzer wrote:
>> On 2018-09-06 10:56 p.m., Axel Davy wrote:
>>
>>> I fear if we begin to do the work manually, there won't be interest to
>>> do that in the kernel,
>>> and thus all applications will need to include
On Fri, Sep 7, 2018, 4:34 AM Michel Dänzer wrote:
> On 2018-09-06 10:56 p.m., Axel Davy wrote:
> > Yeah by pinning to cores, I meant to group of cores.
> >
> > I think a reasonable policy would be for the kernel to put all threads
> > of a given process on the same L3
> > as long as the number of
On 2018-09-06 10:56 p.m., Axel Davy wrote:
> Yeah by pinning to cores, I meant to group of cores.
>
> I think a reasonable policy would be for the kernel to put all threads
> of a given process on the same L3
> as long as the number of threads is lower than the L3 group size.
> When there is more
On Thu, Sep 6, 2018 at 5:54 PM, Roland Scheidegger wrote:
> Am 06.09.2018 um 22:56 schrieb Axel Davy:
>> Yeah by pinning to cores, I meant to group of cores.
>>
>> I think a reasonable policy would be for the kernel to put all threads
>> of a given process on the same L3
>> as long as the number o
Am 06.09.2018 um 22:56 schrieb Axel Davy:
> Yeah by pinning to cores, I meant to group of cores.
>
> I think a reasonable policy would be for the kernel to put all threads
> of a given process on the same L3
> as long as the number of threads is lower than the L3 group size.
> When there is more t
Mesa/RadeonSI already has a lot of threads. My CPU has 8C/16T, but if
you debug glxgears, you'll see 21 threads in that process with
radeonsi. They are mostly shader compiler threads.
Games have a bunch of threads too.
Only a small number of threads really need be pinned to one L3 cache.
Those ar
Yeah by pinning to cores, I meant to group of cores.
I think a reasonable policy would be for the kernel to put all threads
of a given process on the same L3
as long as the number of threads is lower than the L3 group size.
When there is more threads I guess it'd need heuristics to pick which
Actually, you make a good point about the kernel, but the kernel has
no visibility into which threads need to be coupled together. So the
kernel can't do anything.
Marek
On Thu, Sep 6, 2018 at 2:24 PM, Marek Olšák wrote:
> I think you are missing the point. This series doesn't pin threads to
> c
I think you are missing the point. This series doesn't pin threads to
cores. It pins threads to one L3, which can have 4 or 8 cores.
Marek
On Thu, Sep 6, 2018 at 5:22 AM, Axel Davy wrote:
> Hi Marek,
>
> Shouldn't this core pinning be handled by the kernel ?
>
> Else all multithreaded games (or
Hi all,
Here are a number of fixes and slight rework dealing with the ring
buffer decoding. Found while trying to generate aub files that remap
all the buffers from the i915 error state.
A more complete state of this ongoing work is available there
(unfortunately not quite there for Gen9) :
h
Hi Marek,
Shouldn't this core pinning be handled by the kernel ?
Else all multithreaded games (or applications) need an update.
I also see a risk in applications handling the core pinning: several
intensive applications
may pin the same cores. The kernel would be able to switch automatically
Hi,
When the Ryzen CPUs were launched, they didn't perform very well in
games, and it took a while before games were patched. Guess what,
Mesa drivers have suffered from the same inefficincies until now.
The AMD Zen architecture has multiple core complexes (CCX) where each
CCX has e.g. 4C/8T and
Hi;
I finally got dEQP happy with this so not RFC anymore but I consider
this ready for proper review. It was mainly lacking proper handling
of usage flags in vkGetPhysicalDeviceImageFormatProperties2 and when
creating exportable memory in vkAllocateMemory.
Any comments appreciated!
// Tapani
T
Ah,
with 'latest' stuff only #8 choke.
Dieter
Am 15.08.2018 11:21, schrieb Dieter Nützel:
Hello Marek,
sadly this series didn't apply on top of current git master.
Dieter
Am 09.08.2018 04:12, schrieb Marek Olšák:
Hi,
This series adds these extensions:
- AMD_gpu_shader_int64
- AMD_multi_dr
Hello Marek,
sadly this series didn't apply on top of current git master.
Dieter
Am 09.08.2018 04:12, schrieb Marek Olšák:
Hi,
This series adds these extensions:
- AMD_gpu_shader_int64
- AMD_multi_draw_indirect
- AMD_query_buffer_object
- AMD_texture_texture4
- EXT_vertex_attrib_64bit
It als
Hi,
This series adds these extensions:
- AMD_gpu_shader_int64
- AMD_multi_draw_indirect
- AMD_query_buffer_object
- AMD_texture_texture4
- EXT_vertex_attrib_64bit
It also exposes these extensions for gallium (radeonsi):
- EXT_disjoint_timer_query
- KHR_texture_compression_astc_sliced_3d
It also
On 08/01/2018 05:25 PM, Marek Olšák wrote:
Hi,
This implements GL_AMD_framebuffer_multisample_advanced, which is
AMD EQAA.
I have also sent out a piglit test that tests the new API.
Please review.
I did a quick read-through and it looks OK to me.
Reviewed-by: Brian Paul
___
Hi,
This implements GL_AMD_framebuffer_multisample_advanced, which is
AMD EQAA.
I have also sent out a piglit test that tests the new API.
Please review.
Thanks,
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.
This time there are actually some OpenCL patches like adding support for
the OpenCL SPIR-V extensions or a few opcodes we don't hit with vulkan
or glsl.
Also some of the glsl builtins are moved into a new file so that we can
start sharing builtin implementations across multiple SPIR-V extensions.
Jason Ekstrand writes:
> On Mon, Jun 18, 2018 at 2:14 AM, Michel Dänzer wrote:
>
>> On 2018-06-16 08:23 AM, Jason Ekstrand wrote:
>> > On Fri, Jun 15, 2018 at 4:44 PM, Eric Anholt wrote:
>> >
>> >> Michel Dänzer writes:
>> >>
>> >>> On 2018-06-15 05:25 PM, Jason Ekstrand wrote:
>> On June
On Mon, Jun 18, 2018 at 2:14 AM, Michel Dänzer wrote:
> On 2018-06-16 08:23 AM, Jason Ekstrand wrote:
> > On Fri, Jun 15, 2018 at 4:44 PM, Eric Anholt wrote:
> >
> >> Michel Dänzer writes:
> >>
> >>> On 2018-06-15 05:25 PM, Jason Ekstrand wrote:
> On June 15, 2018 01:14:24 Michel Dänzer w
On 2018-06-16 08:23 AM, Jason Ekstrand wrote:
> On Fri, Jun 15, 2018 at 4:44 PM, Eric Anholt wrote:
>
>> Michel Dänzer writes:
>>
>>> On 2018-06-15 05:25 PM, Jason Ekstrand wrote:
On June 15, 2018 01:14:24 Michel Dänzer wrote:
> On 2018-06-15 07:31 AM, Jason Ekstrand wrote:
>>
On Fri, Jun 15, 2018 at 4:44 PM, Eric Anholt wrote:
> Michel Dänzer writes:
>
> > On 2018-06-15 05:25 PM, Jason Ekstrand wrote:
> >> On June 15, 2018 01:14:24 Michel Dänzer wrote:
> >>> On 2018-06-15 07:31 AM, Jason Ekstrand wrote:
>
> I did some testing and x11perf -copywinwin500 is.
Michel Dänzer writes:
> On 2018-06-15 05:25 PM, Jason Ekstrand wrote:
>> On June 15, 2018 01:14:24 Michel Dänzer wrote:
>>> On 2018-06-15 07:31 AM, Jason Ekstrand wrote:
I did some testing and x11perf -copywinwin500 is... exactly the same
with
or without my patches. If anyth
On Fri, Jun 15, 2018 at 8:31 AM, Michel Dänzer wrote:
> On 2018-06-15 05:25 PM, Jason Ekstrand wrote:
> > On June 15, 2018 01:14:24 Michel Dänzer wrote:
> >> On 2018-06-15 07:31 AM, Jason Ekstrand wrote:
> >>>
> >>> I did some testing and x11perf -copywinwin500 is... exactly the same
> >>> with
On 2018-06-15 05:25 PM, Jason Ekstrand wrote:
> On June 15, 2018 01:14:24 Michel Dänzer wrote:
>> On 2018-06-15 07:31 AM, Jason Ekstrand wrote:
>>>
>>> I did some testing and x11perf -copywinwin500 is... exactly the same
>>> with
>>> or without my patches. If anything they might improve it by jus
On June 15, 2018 01:14:24 Michel Dänzer wrote:
On 2018-06-15 07:31 AM, Jason Ekstrand wrote:
On Thu, Jun 14, 2018 at 10:55 AM, Jason Ekstrand
wrote:
On June 14, 2018 01:43:12 Michel Dänzer wrote:
On 2018-06-13 10:26 PM, Jason Ekstrand wrote:
The current BO cache puts BOs back into the re
On 2018-06-15 07:31 AM, Jason Ekstrand wrote:
> On Thu, Jun 14, 2018 at 10:55 AM, Jason Ekstrand
> wrote:
>> On June 14, 2018 01:43:12 Michel Dänzer wrote:
>> On 2018-06-13 10:26 PM, Jason Ekstrand wrote:
>>>
The current BO cache puts BOs back into the recycle bucket the moment the
refc
On Thu, Jun 14, 2018 at 10:55 AM, Jason Ekstrand
wrote:
> On June 14, 2018 01:43:12 Michel Dänzer wrote:
>
> On 2018-06-13 10:26 PM, Jason Ekstrand wrote:
>>
>>> The current BO cache puts BOs back into the recycle bucket the moment the
>>> refcount hits zero. If the BO is busy, we just don't re
On June 14, 2018 01:43:12 Michel Dänzer wrote:
On 2018-06-13 10:26 PM, Jason Ekstrand wrote:
The current BO cache puts BOs back into the recycle bucket the moment the
refcount hits zero. If the BO is busy, we just don't re-use it until it
isn't or we re-use it for a render target which we ass
On 2018-06-13 10:26 PM, Jason Ekstrand wrote:
> The current BO cache puts BOs back into the recycle bucket the moment the
> refcount hits zero. If the BO is busy, we just don't re-use it until it
> isn't or we re-use it for a render target which we assume will be used
> first for drawing. This pa
The current BO cache puts BOs back into the recycle bucket the moment the
refcount hits zero. If the BO is busy, we just don't re-use it until it
isn't or we re-use it for a render target which we assume will be used
first for drawing. This patch series reworks the way the BO cache works a
bit so
On Thu, May 24, 2018 at 4:32 PM, Ian Romanick wrote:
> On 05/23/2018 01:58 PM, Marek Olšák wrote:
> > Hi,
> >
> > This advances GL compatibility support a little bit. Geometry and
> > tessellation shaders should work if you don't combine them with
> > non-GLSL stages. All GLSL legacy variables sh
On 05/23/2018 01:58 PM, Marek Olšák wrote:
> Hi,
>
> This advances GL compatibility support a little bit. Geometry and
> tessellation shaders should work if you don't combine them with
> non-GLSL stages. All GLSL legacy variables should work.
What is the plan for mixing geometry shaders with fixe
All looks good to me :) Series:
Reviewed-by: Timothy Arceri
On 24/05/18 06:58, Marek Olšák wrote:
Hi,
This advances GL compatibility support a little bit. Geometry and
tessellation shaders should work if you don't combine them with
non-GLSL stages. All GLSL legacy variables should work.
All
Hi,
This advances GL compatibility support a little bit. Geometry and
tessellation shaders should work if you don't combine them with
non-GLSL stages. All GLSL legacy variables should work.
All GL compatibility piglit tests for geometry shaders pass on
radeonsi. (we have a lot of compiler tests a
Thanks. The series is
Reviewed-by: Bas Nieuwenhuizen
On Fri, Apr 6, 2018 at 7:34 PM, Samuel Pitoiset
wrote:
> Hi,
>
> This small series is a preliminary work before doing some
> improvements in the DCC/CMASK/FMASK codepaths. What I plan to do is:
>
> - implement DCC for MSAA textures (I have a
Hi,
This small series is a preliminary work before doing some
improvements in the DCC/CMASK/FMASK codepaths. What I plan to do is:
- implement DCC for MSAA textures (I have a WIP branch)
- implement TC-compatible CMASK
- implement DCC for mipmaps and arrays
And probably some other improvements/c
From: Mathias Fröhlich
Hi,
This series pushes the inputs array down into the driver backends.
Also the draw code paths get cleaned up to use the higher level
function entry points from the driver functions struct.
And finally vbo_split* can now be moved into the tnl module.
This step is meant o
On Thu, 2018-03-22 at 14:16 +, Emil Velikov wrote:
> Can we merge the series as-is, until we untangle the dist bits?
Just sent a V2 following Daniel proposal.
J.A.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.free
On 22 March 2018 at 12:32, Juan A. Suarez Romero wrote:
> On Thu, 2018-03-22 at 12:08 +, Daniel Stone wrote:
>> On 22 March 2018 at 11:16, Juan A. Suarez Romero wrote:
>> > On Thu, 2018-03-22 at 11:03 +, Emil Velikov wrote:
>> > > On 21 March 2018 at 13:36, Daniel Stone wrote:
>> > > > I
On Thu, 2018-03-22 at 13:32 +0100, Juan A. Suarez Romero wrote:
> On Thu, 2018-03-22 at 12:08 +, Daniel Stone wrote:
> > On 22 March 2018 at 11:16, Juan A. Suarez Romero
> > wrote:
> > > On Thu, 2018-03-22 at 11:03 +, Emil Velikov wrote:
> > > > On 21 March 2018 at 13:36, Daniel Stone wr
On Thu, 2018-03-22 at 12:08 +, Daniel Stone wrote:
> On 22 March 2018 at 11:16, Juan A. Suarez Romero wrote:
> > On Thu, 2018-03-22 at 11:03 +, Emil Velikov wrote:
> > > On 21 March 2018 at 13:36, Daniel Stone wrote:
> > > > I thought we had resolved earlier to _not_ ship files generated
On 22 March 2018 at 11:16, Juan A. Suarez Romero wrote:
> On Thu, 2018-03-22 at 11:03 +, Emil Velikov wrote:
>> On 21 March 2018 at 13:36, Daniel Stone wrote:
>> > I thought we had resolved earlier to _not_ ship files generated by
>> > wayland-scanner in dist after the last round of fixes.
>>
On Thu, 2018-03-22 at 11:03 +, Emil Velikov wrote:
> On 21 March 2018 at 13:36, Daniel Stone wrote:
> > Hi Juan,
> >
> > On 19 March 2018 at 17:49, Juan A. Suarez Romero
> > wrote:
> > > The first two patches in the series is a new fix for issue
> > > https://bugs.freedesktop.org/show_bug.c
On 21 March 2018 at 13:36, Daniel Stone wrote:
> Hi Juan,
>
> On 19 March 2018 at 17:49, Juan A. Suarez Romero wrote:
>> The first two patches in the series is a new fix for issue
>> https://bugs.freedesktop.org/show_bug.cgi?id=105211, as the current version
>> breaks when running the above comma
On Wed, 2018-03-21 at 13:36 +, Daniel Stone wrote:
> Hi Juan,
>
> On 19 March 2018 at 17:49, Juan A. Suarez Romero wrote:
> > The first two patches in the series is a new fix for issue
> > https://bugs.freedesktop.org/show_bug.cgi?id=105211, as the current version
> > breaks when running the
Hi Juan,
On 19 March 2018 at 17:49, Juan A. Suarez Romero wrote:
> The first two patches in the series is a new fix for issue
> https://bugs.freedesktop.org/show_bug.cgi?id=105211, as the current version
> breaks when running the above command, due "make dist/distcheck" tries to
> generate the th
On 19 March 2018 at 17:49, Juan A. Suarez Romero wrote:
> This series fix several issues that happen when running "./autogen.sh && make
> {dist, distcheck}".
>
Sigh, I should really send local patches as soon as I write them - 1-6
have been sitting locally for about a week :-\
1-7 are
Reviewed-by
This series fix several issues that happen when running "./autogen.sh && make
{dist, distcheck}".
The first two patches in the series is a new fix for issue
https://bugs.freedesktop.org/show_bug.cgi?id=105211, as the current version
breaks when running the above command, due "make dist/distcheck"
On 2018-02-09 — 11:50, Aaron Watry wrote:
> No worries. I've been rebasing this series every time I've pulled
> mesa for the last few months, and this week is the first time I've had
> any real conflicts that need addressing. I'll see if I can find some
> time to address your comments and re-orga
No worries. I've been rebasing this series every time I've pulled
mesa for the last few months, and this week is the first time I've had
any real conflicts that need addressing. I'll see if I can find some
time to address your comments and re-organize the commits as you
suggested.
Jan also had s
Hello Aaron,
Sorry for not having reviewed the updated series…
I will have a look at it over the weekend. If I understand correctly, patches 1
and 2 have been squashed together and upstreamed already, while patches 3
through 8 have not been merged yet. Is this series the latest version, or do
you
Hi Brian,
On Thursday, 1 February 2018 17:17:57 CET Brian Paul wrote:
> Looks good.
>
> Reviewed-by: Brian Paul
Thanks!!
> I don't remember, do you need me to push these for you?
I used to have an account for mesa. I have not used that for some time, but I
assume that it is still functional.
On 02/01/2018 12:32 AM, mathias.froehl...@gmx.net wrote:
From: Mathias Fröhlich
Hi,
Thanks for the review!
This is the starting point to a patch series that I intent to feed.
The aim is to get rid of some VERT_ATTRIB_MAX long loops that currently
happen at about any draw call.
The series tri
From: Mathias Fröhlich
Hi,
Thanks for the review!
This is the starting point to a patch series that I intent to feed.
The aim is to get rid of some VERT_ATTRIB_MAX long loops that currently
happen at about any draw call.
The series tries to separate out one of the depencies of the attribute
al
From: Mathias Fröhlich
This is the starting point to a patch series that I intent to feed.
The aim is to get rid of some VERT_ATTRIB_MAX long loops that currently
happen at about any draw call.
The series tries to separate out one of the depencies of the attribute
aliasing code as a preparation
From: Mathias Fröhlich
Hi all,
The following series applies some optimizations to fixed
function vertex shader hash key generation. Most is targeted
to get a smaller hash key to get a smaller cache footprint and
a shorter final key to compare.
Two of the changes avoid possible different shader h
On Tue, Jan 16, 2018 at 04:44:39PM -0800, Ian Romanick wrote:
> This is the first series to resurrect some work that I started as long
> as 2.5 years ago. A lot of that work produced mixed bag results, but
> that was before nir_opt_algebraic.py had the "is_used_once" modifier.
> Without this, the
Series is,
Reviewed-by: Samuel Iglesias Gonsálvez
On 17/01/18 01:44, Ian Romanick wrote:
> This is the first series to resurrect some work that I started as long
> as 2.5 years ago. A lot of that work produced mixed bag results, but
> that was before nir_opt_algebraic.py had the "is_used_once"
This is the first series to resurrect some work that I started as long
as 2.5 years ago. A lot of that work produced mixed bag results, but
that was before nir_opt_algebraic.py had the "is_used_once" modifier.
Without this, the last patch was more like 50 helped / 500 hurt on most
platforms.
All
This series is a collection of style cleanups, maintainability fixes,
and suggestions from reviewers of previous patches.
Other than the style changes (which are mostly about using consistent
whitespace and removing temporary variables that are useless), this adds
a new internal dependency for nir
When I started working on switching spirv_to_nir from having piles of
assert() to vtn_assert/fail, Ian and I both agreed that we should start
moving in a direction where we had vtn_fail with reasonable error messages
rather than vtn_assert() with some compiler-internal garbage message.
However some
Hi all,
this is just a bunch of random cleanups of things that I happened to
notice while passing by and that accumulated over time.
The one thing that perhaps ties into a kind of theme is cleaning up
sid.h, which I did while exploring some possibilities for moving to
fully auto-generating most p
There are two distinct set of problems this series addresses.
1) the meson build has never worked
2) the checks for this path have been broken in several different ways for a
long time.
Dylan Baker (8):
glapi: don't walk backwards for includes
meson: fix test source name for static glapi
On Monday, November 13, 2017 6:58:28 AM PST Lionel Landwerlin wrote:
> Hi,
>
> Although the main point of this series is to add performance queries
> for Coffeelake. This series also brings the following :
>
> 1. Fix a number of Media/VME counters
> 2. Rename some counter descriptions
> 3. Add
Some of the big patches got caught.
You can find this series here :
https://github.com/djdeath/mesa/tree/wip/djdeath/oa-userspace-configs
-
Lionel
On 13/11/17 14:58, Lionel Landwerlin wrote:
Hi,
Although the main point of this series is to add performance queries
for Coffeelake. This series
Hi,
Although the main point of this series is to add performance queries
for Coffeelake. This series also brings the following :
1. Fix a number of Media/VME counters
2. Rename some counter descriptions
3. Add userspace loading of config not already present
4. Add newer busyness configs (allo
Hi all,
a bunch of fixes for things that I observed while trying to run the CTS
with hang debugging enabled:
- after the rebase, futex-based fences weren't actually getting enabled
- fixes to timeout handling and calculations
- an unrelated ddebug use-after-free bug
- finally, avoid even more dri
This patch series adds support for half-float texture support. I have the
feeling that RS and PE formats differ but that needs more investigation.
The last patch in this series is a result of that assumption. Nevertheless
it passes piglit/bin/oes_texture_float half.
Christian Gmeiner (8):
mesa:
I'm busy until Sunday, but I'll see if I can find the time
to address Nicolai's comments on Sunday evening.
I've addressed the build issues with the tests, and the
comment about using util_vsnprintf, so it's getting there.
I've also done some general polishing on comments, etc.
6. sep. 2017 23.0
For the series:
Tested-by: Dieter Nützel
But do NOT apply on current git any longer.
With Nicolai's comments addressed new version underway? ;-)
Dieter
Am 29.08.2017 21:56, schrieb Thomas Helland:
This is a resend of the string buffer implementation and
related patches sent out back in May.
Reviewed-by: Bruce Cherniak
> On Sep 5, 2017, at 1:57 PM, Tim Rowley wrote:
>
> Highlight is starting to unify the simd/simd16 code, removing lots of
> temporary code duplication.
>
> No piglit or vtk test regressions.
>
> Tim Rowley (8):
> swr/rast: Allow gather of floats from fetch shader
Highlight is starting to unify the simd/simd16 code, removing lots of
temporary code duplication.
No piglit or vtk test regressions.
Tim Rowley (8):
swr/rast: Allow gather of floats from fetch shader with 2-4GB offsets
swr: set caps for VB 4-byte alignment
swr/rast: Removed some trailing wh
Hi Thomas,
On 29 August 2017 at 20:56, Thomas Helland wrote:
> This is a resend of the string buffer implementation and
> related patches sent out back in May. I've done one more
> change to the string buffer; using u_string.h for a compatible
> vsnprintf version to reduce the code even more. I'v
This is a resend of the string buffer implementation and
related patches sent out back in May. I've done one more
change to the string buffer; using u_string.h for a compatible
vsnprintf version to reduce the code even more. I've not been
able to test this due to two build breakages (xmlpool and dr
Hi,
I went through most of the series. I think the approach is OK. The
biggest issue I had is with the sequence:
1.) add an interface
2.) implement a feature
3.) change the interface
I gave my rb to 1 and 2, but you might want to consider changing them
as well, if returning int from the functions
1 - 100 of 381 matches
Mail list logo
