This patch could cause the i965 driver to not load if Mesa was built on a
system without libudev devel present. For example on Fedora one should
install systemd-devel before configuring and building Mesa drivers
subsequent to this change.
On Sun, Jan 26, 2014 at 4:02 PM, Keith Packard wrote:
>
cleanly and compiles successfully.
>
> Marek
>
> On Sun, Jan 26, 2014 at 10:27 PM, Brian Paul
> wrote:
> > On Sun, Jan 26, 2014 at 11:45 AM, Mark Mueller
> > wrote:
> >>
> >>
> >>
> >>
> >> On Fri, Jan 24, 2014 at 2:50 AM, Marek
were observed w/piglit tests on the i965 driver.
The format_unpack functions were used to verify component orders, except
with some _REV formats, which appeared to be incorrect, but not used in
normal testing.
V5 is can be applied to the current master and uses the _SRGB storage type
Mark Mueller
On Fri, Jan 24, 2014 at 2:50 AM, Marek Olšák wrote:
> On Thu, Jan 23, 2014 at 8:36 PM, Kenneth Graunke
> wrote:
> > On 01/23/2014 11:19 AM, Mark Mueller wrote:
> >> That works for sRGB, but what about other color spaces that may be
> added in
> >> the futu
Signed-off-by: Mark Mueller
---
src/mesa/main/format_pack.c | 7 ++-
src/mesa/main/format_unpack.c | 12
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/format_pack.c b/src/mesa/main/format_pack.c
index 39d767a..4c7ed58 100644
--- a/src/mesa/main
On Thu, Jan 23, 2014 at 2:24 AM, Marek Olšák wrote:
> On Thu, Jan 23, 2014 at 4:17 AM, Mark Mueller
> wrote:
> > Hi Merek,
>
> I'm Marek.
>
> >
> >
> >
> >
> >
> > On Wed, Jan 22, 2014 at 2:49 PM, Marek Olšák wrote:
> >>
&
Hi Merek,
On Wed, Jan 22, 2014 at 2:49 PM, Marek Olšák wrote:
> Hi Mark,
>
> Could you please mention or document somewhere in the code (e.g. in
> main/formats.h) which _REV formats are incorrect according to you?
> Sorry if you did so already, I haven't read your other patches yet.
>
>
Ther
On Fri, Jan 17, 2014 at 8:58 AM, Brian Paul wrote:
> On 01/16/2014 10:13 PM, Mark Mueller wrote:
>
>> This series encompases the much discussed specification and renaming of
>> MESA_FORMATs,
>> which now is packed into 8 patches
>>
>> Signed-off-by: Mark Mu
were observed w/piglit tests on the i965 driver.
The format_unpack functions were used to verify component orders, except
with some _REV formats, which appeared to be incorrect, but not used in
normal testing.
V4 rearranges a number of A and P types to match current use by format_unpack.c
Mark
On Sun, Jan 19, 2014 at 7:56 PM, Michel Dänzer wrote:
> On Fre, 2014-01-17 at 03:47 -0800, Mark Mueller wrote:
> >
> > diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
> > index 348d2f4..fb43c83 100644
> > --- a/src/mesa/main/formats.h
> &
se
# define MESA_FORMAT_RGBA_8 MESA_FORMAT_R8G8B8A8_UNORM
# define MESA_FORMAT_RG_16 MESA_FORMAT_R16G16_UNORM
# define MESA_FORMAT_RG_8 MESA_FORMAT_R8G8_UNORM
# define MESA_FORMAT_SIGNED_RGBA_8 MESA_FORMAT_R8G8B8A8_SNORM
# define MESA_FORMAT_SIGNED_RG_16 MESA_FORMAT_R16G16_SNORM
# define MESA_FORMAT_SIGNED_RG_8 MESA_FOR
On Fri, Jan 17, 2014 at 8:58 AM, Brian Paul wrote:
> On 01/17/2014 03:45 AM, Mark Mueller wrote:
>
>> Change all 4 color component unsigned byte formats to meet spec:
>> s/MESA_FORMAT_RGBA\b/MESA_FORMAT_ABGR_UNORM8/g
>> s/MESA_FORMAT_RGBA_REV\b/MESA_FOR
On Fri, Jan 17, 2014 at 2:43 AM, Erik Faye-Lund wrote:
> On Fri, Jan 17, 2014 at 9:22 AM, Christian König
> wrote:
> > But as a general note on writing patches: Please limit the subject line
> to a
> > sane length! Something between 60 and 80 chars should be ok.
>
> Indeed. The regex patterns ar
/MESA_FORMAT_RGBX_UINT32/g
s/\bMESA_FORMAT_XBGR32323232_SINT\b/MESA_FORMAT_RGBX_SINT32/g
Signed-off-by: Mark Mueller
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 24 +++---
src/mesa/main/format_pack.c | 60 +++---
src/mesa/main/format_unpack.c
were observed w/piglit tests on the i965 driver.
The format_unpack functions were used to verify component orders, except
with some _REV formats, which appeared to be incorrect, but not used in
normal testing.
Mark Mueller (8):
1 's/\bgl_format\b/mesa_format/g'. Use better name for Me
Signed-off-by: Mark Mueller
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 24 +++---
src/mesa/main/format_pack.c | 60 +++---
src/mesa/main/format_unpack.c | 36 -
src/mesa/main/formats.c | 100
_UNORM
#define PIPE_FORMAT_RGBX_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
#endif
There is more below the surface here too because the above macros
aren't employed consistently throughout the gallium drivers as best as
I can tell.
On Thu, Dec 26, 2013 at 7:48 PM, Mark Mueller wrote:
>
>
>
>
As a precautionary note, one using auto tools may want to remove
auto-generated source files with git clean -dxf when switching to or from
an old branch with this change to make sure the auto-generated source files
are regenerated. None of the existing make clean targets remove the
autogenerated so
On Thu, Dec 26, 2013 at 6:57 PM, Michel Dänzer wrote:
> On Mit, 2013-12-25 at 20:35 -0800, Mark Mueller wrote:
>
> > On Wed, Dec 25, 2013 at 7:25 PM, Michel Dänzer
> > wrote:
> > On Mit, 2013-12-25 at 15:19 -0800, Mark Mueller wrote:
> > >
> &
On Wed, Dec 25, 2013 at 7:25 PM, Michel Dänzer wrote:
> On Mit, 2013-12-25 at 15:19 -0800, Mark Mueller wrote:
> >
> > --Format Base Type P: Packed --
> > MESA_FORMAT_[[component list,bit width][storage type*][_]][_][storage
> > type**]
>
I'd like to propose a draft naming convention for MESA_FORMATs, which, if
we can agree on that, then other format systems can be brought to
conformance on their own time, after the MESA_FORMATS are fixed.
First, there shall be 3 naming format base types: those for component array
formats (type A);
v2: This patch was inserted into the series to correct build problems with
r200 and radeon drivers. The patch replaces macros that operate on the
MESA_FORMATs with their inline equivalent to facilitate search and replace.
Signed-off-by: Mark Mueller
---
src/mesa/drivers/dri/r200/r200_texstate.c
Signed-off-by: Mark Mueller
---
src/mesa/drivers/dri/r200/r200_texstate.c | 108 +++---
src/mesa/drivers/dri/radeon/radeon_texstate.c | 64 ++-
2 files changed, 70 insertions(+), 102 deletions(-)
diff --git a/src/mesa/drivers/dri/r200/r200_texstate.c
b/src
On Thu, Dec 19, 2013 at 5:47 PM, Michel Dänzer wrote:
> On Don, 2013-12-19 at 13:56 -0800, Mark Mueller wrote:
> > Adjust MESA_FORMAT color component ordering to match API docs, driver
> > specific formats (e.g. PIPE_FORMATs),
>
> Actually, there are a couple of exa
On Fri, Dec 20, 2013 at 7:38 AM, Brian Paul wrote:
> On 12/19/2013 06:47 PM, Michel Dänzer wrote:
>
>> On Don, 2013-12-19 at 13:56 -0800, Mark Mueller wrote:
>>
>>> Adjust MESA_FORMAT color component ordering to match API docs, driver
>>> specific formats (e.
No piglit regressions on i965, or autotools based build regressions
on ilo,nouveau,r300,r600 were observed as a result of these changes.
Mark
On Thu, Dec 19, 2013 at 1:56 PM, Mark Mueller wrote:
> Adjust MESA_FORMAT color component ordering to match API docs, driver
> specific format
Towards this end, I'd like to start by adding UNORM, or UINT, where
applicable, to all of the MESA_FORMATs listed in the "basic hardware
formats" section. Are there any objections?
Mark
On Wed, Dec 18, 2013 at 2:16 AM, Marek Olšák wrote:
> See Gallium PIPE_FORMATs. They all have consistent nam
On Wed, Dec 18, 2013 at 7:36 AM, Brian Paul wrote:
> On 12/17/2013 07:50 PM, Mark Mueller wrote:
>
>>
>>
>>
>> On Tue, Dec 17, 2013 at 12:19 PM, Mark Mueller > <mailto:markkmuel...@gmail.com>> wrote:
>>
>>
>>
>>
>> On
On Tue, Dec 17, 2013 at 12:19 PM, Mark Mueller wrote:
>
>
>
> On Sat, Nov 23, 2013 at 4:10 PM, Marek Olšák wrote:
>
>> On Sat, Nov 23, 2013 at 10:23 PM, Mark Mueller
>> wrote:
>> >
>> >
>> >
&g
On Sat, Nov 23, 2013 at 4:10 PM, Marek Olšák wrote:
> On Sat, Nov 23, 2013 at 10:23 PM, Mark Mueller
> wrote:
> >
> >
> >
> > On Sat, Nov 23, 2013 at 2:26 AM, Marek Olšák wrote:
> >>
>
[...]
> >>
> >> >MESA_FORMAT_
On Mon, Dec 9, 2013 at 3:09 PM, Paul Berry wrote:
> On 7 December 2013 07:42, Francisco Jerez wrote:
>
>> Paul Berry writes:
>>
>> > On 24 November 2013 21:00, Francisco Jerez
>> wrote:
>> >
>> >> Including pack/unpack and texstore code. This texture format is a
>> >> requirement for ARB_shad
On Sat, Nov 23, 2013 at 2:26 AM, Marek Olšák wrote:
> If there is actually hardware support, it's okay to add those formats.
> See comments below.
>
> On Sat, Nov 23, 2013 at 3:59 AM, Mark Mueller
> wrote:
> > How about let's forget the whole concept of GPU loadin
On Fri, Nov 22, 2013 at 3:06 PM, Marek Olšák wrote:
> On Fri, Nov 22, 2013 at 10:45 PM, Mark Mueller
> wrote:
> >
> >
> >
> > On Fri, Nov 22, 2013 at 12:36 PM, Marek Olšák wrote:
> >>
> >> On Fri, Nov 15, 2013 at 9:58 PM, Mark Mueller
> &
On Fri, Nov 22, 2013 at 12:36 PM, Marek Olšák wrote:
> On Fri, Nov 15, 2013 at 9:58 PM, Mark Mueller
> wrote:
> >
> >
> >
> > On Fri, Nov 15, 2013 at 9:52 AM, Marek Olšák wrote:
> >>
> >> I don't understand this and I don't think this
On Fri, Nov 15, 2013 at 4:58 AM, Roland Scheidegger wrote:
> On 11/14/2013 11:53 PM, Mark Mueller wrote:
>
>> This and the subsequent patch are the first steps in adding support to
>> load textures
>> via GPU instead of CPU. This patch expands Mesa's gl_formats such
hecking and get back
> -- Chris
>
> On Fri, Nov 15, 2013 at 2:01 PM, Mark Mueller
> wrote:
> > fixed subject line
> >
> >
> > On Thu, Nov 14, 2013 at 4:15 PM, Mark Mueller
> > wrote:
> >>
> >> This patch consolidates the decision
fixed subject line
On Thu, Nov 14, 2013 at 4:15 PM, Mark Mueller wrote:
> This patch consolidates the decision about formats that blorp_blt does and
> does not support to blorp instead of leaving that decision to callers. This
> opens the door to adding more functionality to blorp,
fixes piglit generated_tests/spec/glsl-1.50/compiler/-
built-in-functions/op-div-mat4x3-float.geom.
Signed-off-by: Mark Mueller
---
src/mesa/drivers/dri/i965/brw_blorp.h | 8 +-
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 149 ++
src/mesa/drivers/dri
s are source only thus they require no
associated
Texstore functions or render targets, therefore they are added _privately_ at
the end
of the gl_formats list.
Signed-off-by: Mark Mueller
---
src/mesa/main/formats.c | 441 +-
src/mesa/main/formats.h
Hi Courtney,
I've been doing similar work but using Xenotic as the benchmark. Here is
how I've been estimating upload times: First I made a rough determination
of a texture count, like 300, as a metric. In intelTexImage I use
clock_gettime to determine the elapsed time between the loading of textur
Wow, it's not often we as developers get to attribute an unexplained
performance improvement to silicon. I'm happy to say I guessed wrong here.
Did this start specifically with Haswell and is it likely this will persist
in future gen hardware - more specifically, what's the proper test by the
driv
On Mon, Sep 16, 2013 at 1:31 AM, Chia-I Wu wrote:
> On Mon, Sep 16, 2013 at 4:12 PM, Chia-I Wu wrote:
> > On Mon, Sep 16, 2013 at 3:50 AM, Mark Mueller
> wrote:
> >>
> >>
> >>
> >> On Fri, Sep 13, 2013 at 2:15 PM, Paul Berry
> wrote:
>
On Fri, Sep 13, 2013 at 2:15 PM, Paul Berry wrote:
> On 12 September 2013 22:06, Chia-I Wu wrote:
>
>> From: Chia-I Wu
>>
>> Consider only the top-left and top-right pixels to approximate DDX in a
>> 2x2
>> subspan, unless the application or the user requests a more accurate
>> approximation.
This is a nice improvement over the explicit cast, which is how I've always
done it in the past - which is the ugly part of an otherwise great method
for flags. Also I use & a lot with enum for clearing bits.
On Fri, Aug 23, 2013 at 3:18 PM, Paul Berry wrote:
> (From a suggestion by Francisco J
When the time comes, are there any concerns with using a 64 bit type, like
portability? 64 bits for flags would be useful for something that I'm
looking into and I'm curious how much pain that could cause.
On Sun, Aug 18, 2013 at 10:58 AM, Ian Romanick wrote:
> On 08/18/2013 09:34 AM, Paul Berr
On Thu, Aug 8, 2013 at 2:19 PM, Eric Anholt wrote:
> Mark Mueller writes:
> > Signed-off-by: Mark Mueller
> > ---
> > src/mesa/drivers/dri/i965/brw_draw.c | 16 ++--
> > 1 file changed, 6 insertions(+), 10 deletions(-)
> >
> > diff --git a/s
Signed-off-by: Mark Mueller
---
src/mesa/drivers/dri/i965/brw_draw.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index 6170d07..1b5ed55 100644
--- a/src/mesa/drivers/dri/i965
On Tue, Aug 6, 2013 at 12:31 PM, Ian Romanick wrote:
> On 08/06/2013 12:10 PM, mmueller wrote:Signed-off-by: mmueller <
> markkmuel...@gmail.com>
>
>> ---
>> src/mesa/drivers/dri/i965/brw_**draw.c | 18 +-
>> 1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/sr
On Thu, Mar 10, 2011 at 12:56 PM, Brian Paul wrote:
> On 03/10/2011 12:25 PM, Marek Olšák wrote:
>
>> Hi,
>>
>> I have reviewed where we call flush() and why and some of them
>> seem unnecessary to me. Those flushes may slightly decrease
>> performance, depending on each driver, and may hide driv
Would it work to put a dummy value into the enum to assure you get the
size you want?
enum __dri_api_enum {
__DRI_API_OPENGL = 0,
#define __DRI_API_OPENGL __DRI_API_OPENGL
__DRI_API_GLES1 = 1,
#define __DRI_API_GLES1 __DRI_API_GLES1
__DRI_API_GLES2 = 2,
#define __DRI_API_GLES2
50 matches
Mail list logo
