Re: [Mesa-dev] [PATCH 1/3] st/vdpau: don't return a device if the screen doesn't support NPOT
Am 18.01.2014 05:58, schrieb Ilia Mirkin:
NV3x cards don't support NPOT textures. Technically this restriction
could be worked around, but since it also doesn't expose any video
decoding hw, just turn it off entirely.
Signed-off-by: Ilia Mirkin
Cc: 10.0
Actually we had a similar problem for early r300/r600 cards and because
of this there is an extra PIPE_VIDEO_CAP_NPOT_TEXTURES.
Wanting to remove that for quite a while, but if you return the correct
value when this is queried even NPOT cards should work quite fine with
the presentation part of VDPAU.
Christian.
---
src/gallium/state_trackers/vdpau/device.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/state_trackers/vdpau/device.c
b/src/gallium/state_trackers/vdpau/device.c
index fb9c68c..36ac11a 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -72,6 +72,11 @@ vdp_imp_device_create_x11(Display *display, int screen,
VdpDevice *device,
goto no_context;
}
+ if (!pscreen->get_param(pscreen, PIPE_CAP_NPOT_TEXTURES)) {
+ ret = VDP_STATUS_NO_IMPLEMENTATION;
+ goto no_context;
+ }
+
*device = vlAddDataHTAB(dev);
if (*device == 0) {
ret = VDP_STATUS_ERROR;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] st/vdpau: don't return a device if the screen doesn't support NPOT
On Sat, Jan 18, 2014 at 5:27 AM, Christian König
wrote:
> Am 18.01.2014 05:58, schrieb Ilia Mirkin:
>
>> NV3x cards don't support NPOT textures. Technically this restriction
>> could be worked around, but since it also doesn't expose any video
>> decoding hw, just turn it off entirely.
>>
>> Signed-off-by: Ilia Mirkin
>> Cc: 10.0
>
>
> Actually we had a similar problem for early r300/r600 cards and because of
> this there is an extra PIPE_VIDEO_CAP_NPOT_TEXTURES.
>
> Wanting to remove that for quite a while, but if you return the correct
> value when this is queried even NPOT cards should work quite fine with the
> presentation part of VDPAU.
There isn't a single reference to NPOT in VDPAU that I could find. Are
you thinking of the XvMC state tracker? That one does appear to have
support for the NPOT stuff. However the e.g. output surfaces being
created aren't video surfaces, they're regular surfaces, so I think
I'm checking the right PIPE_CAP. (I guess I should check both, but
that's really overkill.)
>
> Christian.
>
>
>> ---
>> src/gallium/state_trackers/vdpau/device.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/src/gallium/state_trackers/vdpau/device.c
>> b/src/gallium/state_trackers/vdpau/device.c
>> index fb9c68c..36ac11a 100644
>> --- a/src/gallium/state_trackers/vdpau/device.c
>> +++ b/src/gallium/state_trackers/vdpau/device.c
>> @@ -72,6 +72,11 @@ vdp_imp_device_create_x11(Display *display, int screen,
>> VdpDevice *device,
>> goto no_context;
>> }
>> + if (!pscreen->get_param(pscreen, PIPE_CAP_NPOT_TEXTURES)) {
>> + ret = VDP_STATUS_NO_IMPLEMENTATION;
>> + goto no_context;
>> + }
>> +
>> *device = vlAddDataHTAB(dev);
>> if (*device == 0) {
>> ret = VDP_STATUS_ERROR;
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] st/vdpau: don't return a device if the screen doesn't support NPOT
Am 18.01.2014 11:34, schrieb Ilia Mirkin:
On Sat, Jan 18, 2014 at 5:27 AM, Christian König
wrote:
Am 18.01.2014 05:58, schrieb Ilia Mirkin:
NV3x cards don't support NPOT textures. Technically this restriction
could be worked around, but since it also doesn't expose any video
decoding hw, just turn it off entirely.
Signed-off-by: Ilia Mirkin
Cc: 10.0
Actually we had a similar problem for early r300/r600 cards and because of
this there is an extra PIPE_VIDEO_CAP_NPOT_TEXTURES.
Wanting to remove that for quite a while, but if you return the correct
value when this is queried even NPOT cards should work quite fine with the
presentation part of VDPAU.
There isn't a single reference to NPOT in VDPAU that I could find. Are
you thinking of the XvMC state tracker? That one does appear to have
support for the NPOT stuff. However the e.g. output surfaces being
created aren't video surfaces, they're regular surfaces, so I think
I'm checking the right PIPE_CAP. (I guess I should check both, but
that's really overkill.)
Ah, got it. You don't support NPOT textures at all and not only for the
video buffers. Yeah, then it would be a bit complicated to get VDPAU
working.
Then the patch is: Reviewed-by: Christian König
Christian.
---
src/gallium/state_trackers/vdpau/device.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/state_trackers/vdpau/device.c
b/src/gallium/state_trackers/vdpau/device.c
index fb9c68c..36ac11a 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -72,6 +72,11 @@ vdp_imp_device_create_x11(Display *display, int screen,
VdpDevice *device,
goto no_context;
}
+ if (!pscreen->get_param(pscreen, PIPE_CAP_NPOT_TEXTURES)) {
+ ret = VDP_STATUS_NO_IMPLEMENTATION;
+ goto no_context;
+ }
+
*device = vlAddDataHTAB(dev);
if (*device == 0) {
ret = VDP_STATUS_ERROR;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] st/vdpau: check surface params before creating resources
Am 18.01.2014 06:05, schrieb Ilia Mirkin:
On Fri, Jan 17, 2014 at 11:58 PM, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
---
This seems like a function that should exist in gallium/util, but I didn't
find it. I guess the mesa/st does these checks far enough away from actual
resource creation.
src/gallium/state_trackers/vdpau/bitmap.c| 4
src/gallium/state_trackers/vdpau/output.c| 7 +++
src/gallium/state_trackers/vdpau/vdpau_private.h | 8
3 files changed, 19 insertions(+)
diff --git a/src/gallium/state_trackers/vdpau/bitmap.c
b/src/gallium/state_trackers/vdpau/bitmap.c
index 6110fc7..d316134 100644
--- a/src/gallium/state_trackers/vdpau/bitmap.c
+++ b/src/gallium/state_trackers/vdpau/bitmap.c
@@ -80,6 +80,10 @@ vlVdpBitmapSurfaceCreate(VdpDevice device,
res_tmpl.usage = frequently_accessed ? PIPE_USAGE_DYNAMIC :
PIPE_USAGE_STATIC;
pipe_mutex_lock(dev->mutex);
+
+ if (!CheckSurfaceParams(pipe->screen, &res_tmpl))
+ goto err_unlock;
Ugh, and naturally I mess this up -- there should be a ret =
VDP_STATUS_RESOURCES here. You can see the fixed version at
https://github.com/imirkin/mesa/commits/vdpau
I was just about to complain. But it seems like this is the only remark
I can find as well.
Patches are: Reviewed-by: Christian König
+
res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
if (!res) {
ret = VDP_STATUS_RESOURCES;
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index 58edd37..50036ae 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -83,6 +83,10 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
res_tmpl.usage = PIPE_USAGE_STATIC;
pipe_mutex_lock(dev->mutex);
+
+ if (!CheckSurfaceParams(pipe->screen, &res_tmpl))
+ goto err_unlock;
+
res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
if (!res)
goto err_unlock;
@@ -319,6 +323,9 @@ vlVdpOutputSurfacePutBitsIndexed(VdpOutputSurface surface,
pipe_mutex_lock(vlsurface->device->mutex);
vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL);
+ if (!CheckSurfaceParams(context->screen, &res_tmpl))
+ goto error_resource;
+
res = context->screen->resource_create(context->screen, &res_tmpl);
if (!res)
goto error_resource;
diff --git a/src/gallium/state_trackers/vdpau/vdpau_private.h
b/src/gallium/state_trackers/vdpau/vdpau_private.h
index 60196ac..6c2c019 100644
--- a/src/gallium/state_trackers/vdpau/vdpau_private.h
+++ b/src/gallium/state_trackers/vdpau/vdpau_private.h
@@ -332,6 +332,14 @@ RectToPipeBox(const VdpRect *rect, struct pipe_resource
*res)
return box;
}
+static inline bool
+CheckSurfaceParams(struct pipe_screen *screen,
+ const struct pipe_resource *templ)
+{
+ return screen->is_format_supported(
+ screen, templ->format, templ->target, templ->nr_samples, templ->bind);
+}
+
typedef struct
{
struct vl_screen *vscreen;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] st/vdpau: don't return a device if the screen doesn't support NPOT
On Sat, Jan 18, 2014 at 5:40 AM, Christian König
wrote:
> Am 18.01.2014 11:34, schrieb Ilia Mirkin:
>
>> On Sat, Jan 18, 2014 at 5:27 AM, Christian König
>> wrote:
>>>
>>> Am 18.01.2014 05:58, schrieb Ilia Mirkin:
>>>
NV3x cards don't support NPOT textures. Technically this restriction
could be worked around, but since it also doesn't expose any video
decoding hw, just turn it off entirely.
Signed-off-by: Ilia Mirkin
Cc: 10.0
>>>
>>>
>>> Actually we had a similar problem for early r300/r600 cards and because
>>> of
>>> this there is an extra PIPE_VIDEO_CAP_NPOT_TEXTURES.
>>>
>>> Wanting to remove that for quite a while, but if you return the correct
>>> value when this is queried even NPOT cards should work quite fine with
>>> the
>>> presentation part of VDPAU.
>>
>> There isn't a single reference to NPOT in VDPAU that I could find. Are
>> you thinking of the XvMC state tracker? That one does appear to have
>> support for the NPOT stuff. However the e.g. output surfaces being
>> created aren't video surfaces, they're regular surfaces, so I think
>> I'm checking the right PIPE_CAP. (I guess I should check both, but
>> that's really overkill.)
>
>
> Ah, got it. You don't support NPOT textures at all and not only for the
> video buffers. Yeah, then it would be a bit complicated to get VDPAU
> working.
Actually for video buffers, we do support them :) Lot of good that
does us though, since we can't actually display them. NV3x has a HW
overlay though, I think the idea was to use that for displaying
videos. NV4x lost the HW overlay, but gained NPOT texture support.
>
> Then the patch is: Reviewed-by: Christian König
>
>
>>> Christian.
>>>
>>>
---
src/gallium/state_trackers/vdpau/device.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/state_trackers/vdpau/device.c
b/src/gallium/state_trackers/vdpau/device.c
index fb9c68c..36ac11a 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -72,6 +72,11 @@ vdp_imp_device_create_x11(Display *display, int
screen,
VdpDevice *device,
goto no_context;
}
+ if (!pscreen->get_param(pscreen, PIPE_CAP_NPOT_TEXTURES)) {
+ ret = VDP_STATUS_NO_IMPLEMENTATION;
+ goto no_context;
+ }
+
*device = vlAddDataHTAB(dev);
if (*device == 0) {
ret = VDP_STATUS_ERROR;
>>>
>>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: munmap_chunk(): invalid pointer in libgl1-mesa-dri_9.2.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ian Romanick: > On 01/16/2014 10:42 PM, scarp wrote: >> Hi, > >> I originally posted this to dri-users and got no response. I >> thought about it further and decided it's really a bug and >> deserves to be posted to dri-devel, after all it is a crash and >> crashes are supposed to be handled. > > These days dri-* is generally for kernel related discussions. > mesa-* is the right place. I'm moving the discussion to mesa-dev. > Ah okay, I wasn't aware of this. >> Any custom configurations provided by Whonix can be found in: > >> Gateway VM that has Tor process: >> https://github.com/adrelanos/Whonix/tree/master/whonix_gateway > >> Shared, files that are used in both virtual machines >> https://github.com/adrelanos/Whonix/tree/master/whonix_shared > >> Files only used in the Workstation VM >> https://github.com/adrelanos/Whonix/tree/master/whonix_workstation > >> > >> In case this is something like a grub config option or something >> like that is why I posted these. > > >> Original Message Subject: munmap_chunk(): >> invalid pointer in libgl1-mesa-dri_9.2.1-1 Date: Thu, 26 Dec 2013 >> 07:13:45 + From: scarp To: >> dri-us...@lists.freedesktop.org > >> Hi, > >> I've been testing the privacy orientated virtual machine >> distribution Whonix http://whonix.org. It's a Debian blend >> specifically designed to be an anonymous operating system. In >> this case I am using the latest VirtualBox (4.3.6) - without >> guest utilities. > >> Recently I started having some problems with xvideo, in things >> like mplayer and vlc, and also glxinfo from mesa-utils. Where >> they would simply crash with an error and a backtrace. Exactly >> this one: (full crash attached) > >> *** Error in `glxinfo': munmap_chunk(): invalid pointer: >> 0x0138d8a0 *** === Backtrace: = >> /lib/x86_64-linux-gnu/libc.so.6(+0x7aa16)[0x7f88a36f2a16] >> /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so(+0x248688)[0x7f88a04e6688] > >> > > /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so(+0x3263a3)[0x7f88a05c43a3] >> > /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so(+0x14f412)[0x7f88a03ed412] > > > /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so(dri_destroy_context+0x38)[0x7f88a0597a58] >> > /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so(+0x450c3)[0x7f88a02e30c3] > > > /usr/lib/x86_64-linux-gnu/libGL.so.1(+0x3b34f)[0x7f88a42aa34f] >> /usr/lib/x86_64-linux-gnu/libGL.so.1(+0x1c281)[0x7f88a428b281] >> /usr/lib/x86_64-linux-gnu/libGL.so.1(+0x1c305)[0x7f88a428b305] >> /usr/lib/x86_64-linux-gnu/libX11.so.6(XCloseDisplay+0xa2)[0x7f88a3c55c02] > >> > > glxinfo[0x401c14] >> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f88a365] > >> > > glxinfo[0x401ee6] > > If this distro has "debug" packages, you should install those for > libgl1-mesa-dri. That way the backtrace can have source file > names and line numbers. You might also try running with valgrind. > I should have made this clear. Whonix doesn't use any of it's own binary packages, it's all debian testing 100%. My only guess is some configuration Whonix uses is triggering this regression, because the previous version of libgl1-mesa-dri worked perfectly. The few configuration changes such as /etc/default/grub* can be found in the github repositories however. I installed libgl1-mesa-dri-dbg gdb valgrind mesa-utils however I'm still seeing some: do I need something else? This time I ran glxinfo in gdb and ordered a backtrace: as in $ gdb glxinfo (gdb) run (gdb) bt Program received signal SIGABRT, Aborted. 0x76ac11d5 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x76ac11d5 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x76ac4388 in __GI_abort () at abort.c:90 #2 0x76afc7bb in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x76bf9368 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:199 #3 0x76b06a16 in malloc_printerr (action=3, str=0x76bf9450 "munmap_chunk(): invalid pointer", ptr=) at malloc.c:4923 #4 0x738f9688 in util_blitter_destroy (blitter=0x677530) at ../../../../../src/gallium/auxiliary/util/u_blitter.c:341 #5 0x739d73a3 in llvmpipe_destroy (pipe=0x633ae0) at ../../../../../../src/gallium/drivers/llvmpipe/lp_context.c:62 #6 0x73800412 in st_destroy_context (st=0x0) at ../../../../src/mesa/state_tracker/st_context.c:319 #7 0x739aaa58 in dri_destroy_context (cPriv=) at ../../../../../../../src/gallium/state_trackers/dri/sw/dri_context.c:203 #8 0x736f60c3 in driDestroyContext (pcp=0x632b50) at ../../../../../../src/mesa/drivers/dri/common/drisw_util.c:229 #9 0x776be34f in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1 #10 0x7769f281 in ?? () from /usr/
[Mesa-dev] [Bug 73761] New: driCreateContextAttribs uses freed memory on context recreation
https://bugs.freedesktop.org/show_bug.cgi?id=73761
Priority: medium
Bug ID: 73761
Assignee: mesa-dev@lists.freedesktop.org
Summary: driCreateContextAttribs uses freed memory on context
recreation
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: edwin+m...@etorok.net
Hardware: x86-64 (AMD64)
Status: NEW
Version: 10.0
Component: Other
Product: Mesa
Created attachment 92327
--> https://bugs.freedesktop.org/attachment.cgi?id=92327&action=edit
bug.c
If I create a debug context, have the window receive some events (for example
mouse movements), then delete the context/window, and recreate them I get a
crash here:
struct gl_context *ctx = context->driverPrivate;
if ((flags & __DRI_CTX_FLAG_FORWARD_COMPATIBLE) != 0)
ctx->Const.ContextFlags |= GL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT;
if ((flags & __DRI_CTX_FLAG_DEBUG) != 0) {
ctx->Const.ContextFlags |= GL_CONTEXT_FLAG_DEBUG_BIT;//<--- crash
ctx->Debug.DebugOutput = GL_TRUE;
}
See valgrind output below, and attached testcase. The testcase uses SDL 2.0.1.
$ gcc /tmp/bug.c `sdl2-config --cflags --libs`
$ valgrind ./a.out
==29028== Memcheck, a memory error detector
==29028== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==29028== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==29028== Command: ./a.out
==29028==
Move your mouse now to generate some events
==29028== Invalid write of size 1
==29028==at 0x53A8570: driCreateContextAttribs (dri_util.c:446)
==29028==by 0x3067840357: ??? (in
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0)
==29028==by 0x3067818461: ??? (in
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0)
==29028==by 0x4CFA37D: X11_GL_CreateContext (in
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.1.0)
==29028==by 0x4CEF2AF: SDL_GL_CreateContext (in
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.1.0)
==29028==by 0x400A50: test_window (in
/home/edwin/HDD/me/language/OpenGL/tgls-arcsynthesis/a.out)
==29028==by 0x400ACC: main (in
/home/edwin/HDD/me/language/OpenGL/tgls-arcsynthesis/a.out)
==29028== Address 0x530f701 is 52,753 bytes inside a block of size 65,536
free'd
==29028==at 0x4A0870C: free (vg_replace_malloc.c:468)
==29028==by 0x56FD463: r600_sb::sb_pool::free_all() (sb_valtable.cpp:313)
==29028==by 0x56F6291: r600_sb::shader::~shader() (sb_ir.h:89)
==29028==by 0x56D97DC: r600_sb_bytecode_process (sb_core.cpp:285)
==29028==by 0x56B237E: r600_pipe_shader_create (r600_shader.c:152)
==29028==by 0x56C4F54: r600_shader_select (r600_state_common.c:746)
==29028==by 0x56C510F: r600_create_shader_state (r600_state_common.c:793)
==29028==by 0x55D0AAE: ureg_create_shader (tgsi_ureg.c:1704)
==29028==by 0x55FDE6C: util_make_empty_fragment_shader (tgsi_ureg.h:138)
==29028==by 0x55DE91C: util_blitter_create (u_blitter.c:281)
==29028==by 0x56A3E01: r600_create_context (r600_pipe.c:316)
==29028==by 0x54DE4F1: st_api_create_context (st_manager.c:615)
$ uname -a
Linux debian 3.12.8 #39 SMP PREEMPT Thu Jan 16 10:06:30 EET 2014 x86_64
GNU/Linux
$ glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV730
OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.0.1
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.0.1
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
Note: if at first you can't reproduce it, make sure the window is receiving
some events (I guess its more about memory being allocated than the events
themselves), and try to use my command-line above exactly as is.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/1] clover: Don't crash on NULL global buffer objects.
Jan Vesely writes:
> Specs say "If the argument is a buffer object, the arg_value
> pointer can be NULL or point to a NULL value in which case a NULL
> value will be used as the value for the argument declared as a
> pointer to __global or __constant memory in the kernel."
>
> So don't crash when somebody does that.
>
> v2: Insert NULL into input buffer instead of buffer handle pair
> Fix constant_argument too
> Drop r600 driver changes
>
> v3: Fix inserting NULL pointer
>
> Signed-off-by: Jan Vesely
Looks OK to me,
Reviewed-by: Francisco Jerez
Thanks.
> ---
> src/gallium/state_trackers/clover/core/kernel.cpp | 34
> +++
> 1 file changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/core/kernel.cpp
> b/src/gallium/state_trackers/clover/core/kernel.cpp
> index 58780d6..fb826c1 100644
> --- a/src/gallium/state_trackers/clover/core/kernel.cpp
> +++ b/src/gallium/state_trackers/clover/core/kernel.cpp
> @@ -327,7 +327,7 @@ kernel::global_argument::set(size_t size, const void
> *value) {
> if (size != sizeof(cl_mem))
>throw error(CL_INVALID_ARG_SIZE);
>
> - buf = &obj(*(cl_mem *)value);
> + buf = pobj(value ? *(cl_mem *)value : NULL);
> _set = true;
> }
>
> @@ -335,8 +335,14 @@ void
> kernel::global_argument::bind(exec_context &ctx,
>const module::argument &marg) {
> align(ctx.input, marg.target_align);
> - ctx.g_handles.push_back(allocate(ctx.input, marg.target_size));
> - ctx.g_buffers.push_back(buf->resource(*ctx.q).pipe);
> +
> + if (buf) {
> + ctx.g_handles.push_back(allocate(ctx.input, marg.target_size));
> + ctx.g_buffers.push_back(buf->resource(*ctx.q).pipe);
> + } else {
> + //NULL pointer
> + allocate(ctx.input, marg.target_size);
> + }
> }
>
> void
> @@ -379,22 +385,28 @@ kernel::constant_argument::set(size_t size, const void
> *value) {
> if (size != sizeof(cl_mem))
>throw error(CL_INVALID_ARG_SIZE);
>
> - buf = &obj(*(cl_mem *)value);
> + buf = pobj(value ? *(cl_mem *)value : NULL);
> _set = true;
> }
>
> void
> kernel::constant_argument::bind(exec_context &ctx,
> const module::argument &marg) {
> - auto v = bytes(ctx.resources.size() << 24);
> -
> - extend(v, module::argument::zero_ext, marg.target_size);
> - byteswap(v, ctx.q->dev.endianness());
> align(ctx.input, marg.target_align);
> - insert(ctx.input, v);
>
> - st = buf->resource(*ctx.q).bind_surface(*ctx.q, false);
> - ctx.resources.push_back(st);
> + if (buf) {
> + auto v = bytes(ctx.resources.size() << 24);
> +
> + extend(v, module::argument::zero_ext, marg.target_size);
> + byteswap(v, ctx.q->dev.endianness());
> + insert(ctx.input, v);
> +
> + st = buf->resource(*ctx.q).bind_surface(*ctx.q, false);
> + ctx.resources.push_back(st);
> + } else {
> + //NULL pointer
> + allocate(ctx.input, marg.target_size);
> + }
> }
>
> void
> --
> 1.8.4.2
pgpeUpJkJP2wf.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] gallium: remove PIPE_CAP_SCALED_RESOLVE
From: Marek Olšák If any driver doesn't support this, it can use a blit after resolving the samples. --- src/gallium/drivers/freedreno/freedreno_screen.c | 1 - src/gallium/drivers/i915/i915_screen.c | 1 - src/gallium/drivers/ilo/ilo_screen.c | 1 - src/gallium/drivers/llvmpipe/lp_screen.c | 2 -- src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 - src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 - src/gallium/drivers/r300/r300_screen.c | 1 - src/gallium/drivers/r600/r600_pipe.c | 1 - src/gallium/drivers/radeonsi/si_pipe.c | 1 - src/gallium/drivers/softpipe/sp_screen.c | 2 -- src/gallium/drivers/svga/svga_screen.c | 1 - src/gallium/include/pipe/p_defines.h | 1 - 12 files changed, 14 deletions(-) diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index 1a7b80c..c10efd8 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -193,7 +193,6 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE: case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT: case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER: - case PIPE_CAP_SCALED_RESOLVE: case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS: case PIPE_CAP_FRAGMENT_COLOR_CLAMPED: case PIPE_CAP_VERTEX_COLOR_CLAMPED: diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 842625e..3f492f7 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -202,7 +202,6 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_SM3: case PIPE_CAP_SEAMLESS_CUBE_MAP: case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE: - case PIPE_CAP_SCALED_RESOLVE: case PIPE_CAP_FRAGMENT_COLOR_CLAMPED: case PIPE_CAP_MIXED_COLORBUFFER_FORMATS: case PIPE_CAP_CONDITIONAL_RENDER: diff --git a/src/gallium/drivers/ilo/ilo_screen.c b/src/gallium/drivers/ilo/ilo_screen.c index 2b19ad7..2c68fcd 100644 --- a/src/gallium/drivers/ilo/ilo_screen.c +++ b/src/gallium/drivers/ilo/ilo_screen.c @@ -360,7 +360,6 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap param) return true; case PIPE_CAP_SEAMLESS_CUBE_MAP: case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE: - case PIPE_CAP_SCALED_RESOLVE: return true; case PIPE_CAP_MIN_TEXEL_OFFSET: return -8; diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index 3fa9a98..e5aca16 100644 --- a/src/gallium/drivers/llvmpipe/lp_screen.c +++ b/src/gallium/drivers/llvmpipe/lp_screen.c @@ -175,8 +175,6 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_SEAMLESS_CUBE_MAP: case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE: return 1; - case PIPE_CAP_SCALED_RESOLVE: - return 0; /* this is a lie could support arbitrary large offsets */ case PIPE_CAP_MIN_TEXEL_OFFSET: return -8; diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c index ad52ddf..787802d 100644 --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c @@ -66,7 +66,6 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TWO_SIDED_STENCIL: case PIPE_CAP_ANISOTROPIC_FILTER: case PIPE_CAP_POINT_SPRITE: - case PIPE_CAP_SCALED_RESOLVE: case PIPE_CAP_OCCLUSION_QUERY: case PIPE_CAP_QUERY_TIME_ELAPSED: case PIPE_CAP_QUERY_TIMESTAMP: diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c b/src/gallium/drivers/nouveau/nv50/nv50_screen.c index 6bc03ae..f94b885 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c @@ -103,7 +103,6 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_NPOT_TEXTURES: case PIPE_CAP_MIXED_FRAMEBUFFER_SIZES: case PIPE_CAP_ANISOTROPIC_FILTER: - case PIPE_CAP_SCALED_RESOLVE: case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: return 1; case PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE: diff --git a/src/gallium/drivers/r300/r300_screen.c b/src/gallium/drivers/r300/r300_screen.c index 352fed5..4b790af 100644 --- a/src/gallium/drivers/r300/r300_screen.c +++ b/src/gallium/drivers/r300/r300_screen.c @@ -146,7 +146,6 @@ static int r300_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER: case PIPE_CAP_SEAMLESS_CUBE_MAP: case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE: -case PIPE_CAP_SCALED_RESOLVE: case PIPE_CAP_MIN_TEXEL_OFFSET: case PIPE_CAP_MAX_TEXEL_OFFSET: case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS: diff --git a/src/gallium/driver
[Mesa-dev] [PATCH 1/2] gallium: remove PIPE_CAP_MAX_COMBINED_SAMPLERS
From: Marek Olšák
This can be derived from the shader caps.
---
src/gallium/docs/source/screen.rst | 2 --
src/gallium/drivers/freedreno/freedreno_screen.c | 2 --
src/gallium/drivers/i915/i915_screen.c | 7 ---
src/gallium/drivers/ilo/ilo_screen.c | 2 --
src/gallium/drivers/llvmpipe/lp_screen.c | 2 --
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 2 --
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 --
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 --
src/gallium/drivers/r300/r300_screen.c | 2 --
src/gallium/drivers/r600/r600_pipe.c | 2 --
src/gallium/drivers/radeonsi/si_pipe.c | 2 --
src/gallium/drivers/softpipe/sp_screen.c | 2 --
src/gallium/drivers/svga/svga_screen.c | 2 --
src/gallium/include/pipe/p_defines.h | 3 ---
src/mesa/state_tracker/st_extensions.c | 10 ++
15 files changed, 6 insertions(+), 38 deletions(-)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index ce96f688..ed8e832 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -53,8 +53,6 @@ The integer capabilities:
opcodes to the Shader Model 3 specification. XXX oh god this is horrible
* ``PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS``: The maximum number of stream buffers.
* ``PIPE_CAP_PRIMITIVE_RESTART``: Whether primitive restart is supported.
-* ``PIPE_CAP_MAX_COMBINED_SAMPLERS``: The total number of samplers accessible
from
- the vertex and fragment shader, inclusive.
* ``PIPE_CAP_INDEP_BLEND_ENABLE``: Whether per-rendertarget blend enabling and
channel
masks are supported. If 0, then the first rendertarget's blend mask is
replicated across all MRTs.
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
b/src/gallium/drivers/freedreno/freedreno_screen.c
index 10c5e18..1a7b80c 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -218,8 +218,6 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
return MAX_MIP_LEVELS;
case PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS:
return 9192;
- case PIPE_CAP_MAX_COMBINED_SAMPLERS:
- return 20;
/* Render targets. */
case PIPE_CAP_MAX_RENDER_TARGETS:
diff --git a/src/gallium/drivers/i915/i915_screen.c
b/src/gallium/drivers/i915/i915_screen.c
index 8b29fc2..842625e 100644
--- a/src/gallium/drivers/i915/i915_screen.c
+++ b/src/gallium/drivers/i915/i915_screen.c
@@ -236,13 +236,6 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap
cap)
return is->debug.lie ? 1 : 0;
/* Texturing. */
- case PIPE_CAP_MAX_COMBINED_SAMPLERS:
- return i915_get_shader_param(screen,
- PIPE_SHADER_VERTEX,
- PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS) +
- i915_get_shader_param(screen,
- PIPE_SHADER_FRAGMENT,
- PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS);
case PIPE_CAP_MAX_TEXTURE_2D_LEVELS:
return I915_MAX_TEXTURE_2D_LEVELS;
case PIPE_CAP_MAX_TEXTURE_3D_LEVELS:
diff --git a/src/gallium/drivers/ilo/ilo_screen.c
b/src/gallium/drivers/ilo/ilo_screen.c
index 54fbf68..2b19ad7 100644
--- a/src/gallium/drivers/ilo/ilo_screen.c
+++ b/src/gallium/drivers/ilo/ilo_screen.c
@@ -338,8 +338,6 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap
param)
return ILO_MAX_SO_BUFFERS;
case PIPE_CAP_PRIMITIVE_RESTART:
return true;
- case PIPE_CAP_MAX_COMBINED_SAMPLERS:
- return ILO_MAX_SAMPLERS * 2;
case PIPE_CAP_INDEP_BLEND_ENABLE:
case PIPE_CAP_INDEP_BLEND_FUNC:
return true;
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index c8eb3ba..3fa9a98 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -106,8 +106,6 @@ static int
llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param)
{
switch (param) {
- case PIPE_CAP_MAX_COMBINED_SAMPLERS:
- return 2 * PIPE_MAX_SAMPLERS; /* VS + FS samplers */
case PIPE_CAP_NPOT_TEXTURES:
case PIPE_CAP_MIXED_FRAMEBUFFER_SIZES:
return 1;
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index 2610330..ad52ddf 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -60,8 +60,6 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
return 10;
case PIPE_CAP_MAX_TEXTURE_CUBE_LEVELS:
return 13;
- case PIPE_CAP_MAX_COMBINED_SAMPLERS:
- return 16;
case PIPE_CAP_GLSL_FEATURE_LEVEL:
return 120;
/* supported capabilities */
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_scre
[Mesa-dev] [Bug 73631] es2tri fragment shader did not compile AMD ARUBA
https://bugs.freedesktop.org/show_bug.cgi?id=73631 --- Comment #3 from Aaron Paden --- Yep, that solves the problem on my machine as well. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Add some informative debug when the X Server botches DRI2 GetBuffers.
We've had various bug reports over the years where miptrees are missing,
and when I screwed it up while adding DRI2 to the modesetting driver, I
figured I should put the info necessary for debug here.
---
src/mesa/drivers/dri/i965/brw_context.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 51918b9..e2d7c6d 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -1257,14 +1257,24 @@ intel_process_dri2_buffer(struct brw_context *brw,
buffer->pitch,
buffer->name,
buffer_name);
- if (!region)
+ if (!region) {
+ fprintf(stderr,
+ "Failed to make region for returned DRI2 buffer "
+ "(%dx%d, named %d).\n"
+ "This is likely a bug in the X Server that will lead to a "
+ "crash soon.\n",
+ drawable->w, drawable->h, buffer->name);
return;
+ }
rb->mt = intel_miptree_create_for_dri2_buffer(brw,
buffer->attachment,
intel_rb_format(rb),
num_samples,
region);
+
+ assert(rb->mt);
+
intel_region_release(®ion);
}
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Remove redundant check in blitter-based glBlitFramebuffer().
The intel_miptree_blit() code checks the format for us now, plus it
handles xrgb vs argb for us.
---
src/mesa/drivers/dri/i965/intel_fbo.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drivers/dri/i965/intel_fbo.c
index f094718..7323781 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -739,16 +739,6 @@ intel_blit_framebuffer_with_blitter(struct gl_context *ctx,
return mask;
}
- gl_format src_format = _mesa_get_srgb_format_linear(src_rb->Format);
- gl_format dst_format = _mesa_get_srgb_format_linear(dst_rb->Format);
- if (src_format != dst_format) {
-perf_debug("glBlitFramebuffer(): unsupported blit from %s to %s. "
- "Falling back to software rendering.\n",
- _mesa_get_format_name(src_format),
- _mesa_get_format_name(dst_format));
-return mask;
- }
-
if (!intel_miptree_blit(brw,
src_irb->mt,
src_irb->mt_level, src_irb->mt_layer,
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] glcpp: Remove unused gl_api bits.
On 01/17/2014 09:09 PM, Matt Turner wrote:
> ---
> src/glsl/glcpp/glcpp-parse.y | 1 -
> src/glsl/glcpp/glcpp.c | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
> index c774662..427fdec 100644
> --- a/src/glsl/glcpp/glcpp-parse.y
> +++ b/src/glsl/glcpp/glcpp-parse.y
> @@ -30,7 +30,6 @@
>
> #include "glcpp.h"
> #include "main/core.h" /* for struct gl_extensions */
> -#include "main/mtypes.h" /* for gl_api enum */
>
> static void
> yyerror (YYLTYPE *locp, glcpp_parser_t *parser, const char *error);
> diff --git a/src/glsl/glcpp/glcpp.c b/src/glsl/glcpp/glcpp.c
> index 6994d7b..c9c2ff2 100644
> --- a/src/glsl/glcpp/glcpp.c
> +++ b/src/glsl/glcpp/glcpp.c
> @@ -101,7 +101,6 @@ load_text_file(void *ctx, const char *filename)
> static void
> init_fake_gl_context (struct gl_context *gl_ctx)
> {
> - gl_ctx->API = API_OPENGL_COMPAT;
> gl_ctx->Const.DisableGLSLLineContinuations = false;
> }
NAK. This is definitely used.
main allocates gl_ctx and calls init_fake_gl_context, which sets up
gl_ctx->API (without your patch). It then does:
ret = glcpp_preprocess(ctx, &shader, &info_log, NULL, &gl_ctx);
The first thing glcpp_preprocess does is:
glcpp_parser_t *parser = glcpp_parser_create (extensions,
gl_ctx->API);
Then in glcpp_parser_create, we find:
if (api == API_OPENGLES2) {
parser->is_gles = true;
add_builtin_define(parser, "GL_ES", 1);
...add ES extension defines...
} else {
...add GL extension defines...
}
With this patch, the behavior would likely be undefined.
--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] code de-duplication and non-pci support v2
On 16/01/14 23:29, Kristian Høgsberg wrote: > On Sat, Jan 11, 2014 at 04:51:42PM -0500, Rob Clark wrote: >> > On Sat, Jan 11, 2014 at 11:54 AM, Emil Velikov >> > wrote: >>> > > This is an updated series of Rob's patches >>> > > >>> > > * The introduction of the util library is separated from the >>> > > de-duplication. >>> > > * Each commit targets individual part of mesa and it should >>> > > build/work regardless of build system/options. >>> > > * Handles a couple more cases of de-duplication. >>> > > * Hides the loader funcs so that they are not exported. >>> > > * Building platform_android, will correctly set the logger to >>> > > _eglLog(), which on itself is rapped around Androids (A)LOG. >>> > > * Non-pci devices support has been ripped out and is left at >>> > > the end of the series. >>> > > * automake and scons build tested, Android should after >>> > > correcting the following >>> > > defined(PIPE_OS_ANDROID) && !defined(_EGL_NO_DRM) >> > >> > Very cool, thanks for taking this and running with it. Especially the >> > other build systems which I have no clue about :-) >> > >> > I had a look at the patches, and they look good. So with the >> > disclaimer that I am certainly not expert on these parts, for the >> > series: >> > >> > Reviewed-by: Rob Clark > I'm not familiar with the other build systems either, but aside for > those two issues I pointed out > > Reviewed-by: Kristian Høgsberg > > for the series. > Thanks gents. Just pushed the series to master after addressing Kristian's comments. Stupidly I've created a loader-v4 branch as well, sorry about that. FWIW it seems that patchwork did not change the state of the following http://patchwork.freedesktop.org/patch/17793/ http://patchwork.freedesktop.org/patch/17784/ http://patchwork.freedesktop.org/patch/17788/ http://patchwork.freedesktop.org/patch/17792/ http://patchwork.freedesktop.org/patch/17811/ 1c5e296..bf70c23 master -> master Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] glcpp: Remove unused gl_api bits.
On 01/18/2014 11:13 AM, Kenneth Graunke wrote:
> On 01/17/2014 09:09 PM, Matt Turner wrote:
>> ---
>> src/glsl/glcpp/glcpp-parse.y | 1 -
>> src/glsl/glcpp/glcpp.c | 1 -
>> 2 files changed, 2 deletions(-)
>>
>> diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
>> index c774662..427fdec 100644
>> --- a/src/glsl/glcpp/glcpp-parse.y
>> +++ b/src/glsl/glcpp/glcpp-parse.y
>> @@ -30,7 +30,6 @@
>>
>> #include "glcpp.h"
>> #include "main/core.h" /* for struct gl_extensions */
>> -#include "main/mtypes.h" /* for gl_api enum */
>>
>> static void
>> yyerror (YYLTYPE *locp, glcpp_parser_t *parser, const char *error);
>> diff --git a/src/glsl/glcpp/glcpp.c b/src/glsl/glcpp/glcpp.c
>> index 6994d7b..c9c2ff2 100644
>> --- a/src/glsl/glcpp/glcpp.c
>> +++ b/src/glsl/glcpp/glcpp.c
>> @@ -101,7 +101,6 @@ load_text_file(void *ctx, const char *filename)
>> static void
>> init_fake_gl_context (struct gl_context *gl_ctx)
>> {
>> -gl_ctx->API = API_OPENGL_COMPAT;
>> gl_ctx->Const.DisableGLSLLineContinuations = false;
>> }
>
> NAK. This is definitely used.
I apologize for the bad review - please ignore it. My mail reader
scrambled the order of your patches, putting this before patch 3, where
(presumably) you remove the need for this.
--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/10] nv50: out-of-bounds access of context specific attribs
On 16/01/14 18:54, Ilia Mirkin wrote: > On Thu, Jan 16, 2014 at 1:44 PM, Emil Velikov > wrote: >> Subject: [PATCH 00/10] nv50: out-of-bounds access of context specific attribs >> In-Reply-To: >> >> So here it goes, a few serious patches and some not as much >> >> Patches 1, 2 correct the range to be within the defined boundaries >> when invalidating the textures/constbufs. Most likely a copy/paste >> typo from the nvc0 driver. >> >> Patches 3, 5, 7, 8, 9 introduce asserts which may not be stricly >> needed. I'm open to suggestions >> >> Patches 4, 6 changes the type of variables used to store the index >> to be unsigned. >> >> And patch 10 provides a small/trivial cleanup at the context_ctor >> errot path. > > Series is > > Reviewed-by: Ilia Mirkin > > Nice cleanups! And it should make future bugs a bit more obvious. > Pushed to master bf70c23..66fd505 master -> master Thanks for the review Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Build testing, wine style
On 13/01/14 18:47, Tom Stellard wrote: > On Sat, Jan 11, 2014 at 03:53:58PM +, Emil Velikov wrote: >> Hello list, >> >> While going though mesa's build systems I was wondering what it would >> take to improve the overall experience of build testing. >> >> The only thing I can think of is a more centralised solution similar to >> the one used by wine [1]. Having buildbots test every patch what is send >> to the ML [2] :) >> >> I'm sure that some companies/organisations may have similar >> infrastructure but I was thinking what is the possibility of having a >> more open/shared experience, thus one does not need to test the same >> environment/setup across multiple bots. >> >> Here are a couple of nice words for each build system that mesa has: >> >> * automake - tons of many build variations, most of which handled by >> debian/ubuntu, fedora and suse build systems. >> >> * scons - less build variations, mainly used for non-public >> state-trackers and/or drivers >> >> * android - possibly the most painful one out there (IMHO), 10GiB code >> cloned a ton of libraries build and alot more that fair rather randomly :\ >> >> Kind of wondering what it would take to have such a feature and if >> people will see benefits from it. > > Hi Emil, > > I've been playing around with buildbot, and I even had a local one doing > Mesa builds a few weeks ago. I just need to find a dedicated machine so > I can have it running full-time. > > For me, I'm mostly interested in using buildbot for piglit testing, > but I think it would also be useful to catch build breakages for the > various configurations people care about. > Indeed piglit testing would be great as well, considering it does not lockup the machine :\ My idea was "get it compiling first and then piglit test it", as the former can be done virtually any type of machine unlike the latter. > I still don't understand the whole master/slave relationship of buildbot, > so I'm not sure what kind of centralized resources would be needed, but > maybe if someone would volunteer to maintain it we could use some of the fdo > resources for hosting buildbot. > > You also may want to take a look at tinderbox.x.org, which already does > some build testing. I prefer buildbot mainly because I was unable to find > very much documentation for tinderbox, but it might be worth looking at. > To be honest I did not find much documentation about tinderbox either. What I've noticed is that openSUSE Build Service offers a "drop the distro specific build script here" approach while handling all major distributions. Scons and Android builds are still a bit of a mist though. Thanks for the input Tom, I'll need to take a look at tinderbox/buildbot/obs more closely. Emil > -Tom >> >> Cheers, >> Emil >> >> [1] http://wiki.winehq.org/BuildBot >> [2] http://source.winehq.org/patches/ >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73761] driCreateContextAttribs uses freed memory on context recreation
https://bugs.freedesktop.org/show_bug.cgi?id=73761 Ilia Mirkin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Ilia Mirkin --- Yes, I reported this very shortly before the 10.0 release, and it should be fixed by 38366c0c6e715314367b15680702e382d5c46a4a in the main tree, and db0dc5c008f3f4a475de1c6471f99f45f7c5b7d6 on the 10.0 branch, which should be in mesa-10.0.2. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73761] driCreateContextAttribs uses freed memory on context recreation
https://bugs.freedesktop.org/show_bug.cgi?id=73761 --- Comment #2 from Török Edwin --- (In reply to comment #1) > Yes, I reported this very shortly before the 10.0 release, and it should be > fixed by 38366c0c6e715314367b15680702e382d5c46a4a in the main tree, and > db0dc5c008f3f4a475de1c6471f99f45f7c5b7d6 on the 10.0 branch, which should be > in mesa-10.0.2. I must've missed the 10.0.2 release, its not listed on http://mesa3d.org/index.html, found it at ftp://freedesktop.org/pub/mesa/10.0.2/ though. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Build testing, wine style
On Sun, Jan 19, 2014 at 5:45 AM, Emil Velikov wrote: > On 13/01/14 18:47, Tom Stellard wrote: >> On Sat, Jan 11, 2014 at 03:53:58PM +, Emil Velikov wrote: >>> Hello list, >>> >>> While going though mesa's build systems I was wondering what it would >>> take to improve the overall experience of build testing. >>> >>> The only thing I can think of is a more centralised solution similar to >>> the one used by wine [1]. Having buildbots test every patch what is send >>> to the ML [2] :) >>> >>> I'm sure that some companies/organisations may have similar >>> infrastructure but I was thinking what is the possibility of having a >>> more open/shared experience, thus one does not need to test the same >>> environment/setup across multiple bots. >>> >>> Here are a couple of nice words for each build system that mesa has: >>> >>> * automake - tons of many build variations, most of which handled by >>> debian/ubuntu, fedora and suse build systems. >>> >>> * scons - less build variations, mainly used for non-public >>> state-trackers and/or drivers >>> >>> * android - possibly the most painful one out there (IMHO), 10GiB code >>> cloned a ton of libraries build and alot more that fair rather randomly :\ >>> >>> Kind of wondering what it would take to have such a feature and if >>> people will see benefits from it. >> >> Hi Emil, >> >> I've been playing around with buildbot, and I even had a local one doing >> Mesa builds a few weeks ago. I just need to find a dedicated machine so >> I can have it running full-time. >> >> For me, I'm mostly interested in using buildbot for piglit testing, >> but I think it would also be useful to catch build breakages for the >> various configurations people care about. >> > Indeed piglit testing would be great as well, considering it does not > lockup the machine :\ > My idea was "get it compiling first and then piglit test it", as the > former can be done virtually any type of machine unlike the latter. > >> I still don't understand the whole master/slave relationship of buildbot, >> so I'm not sure what kind of centralized resources would be needed, but >> maybe if someone would volunteer to maintain it we could use some of the fdo >> resources for hosting buildbot. >> >> You also may want to take a look at tinderbox.x.org, which already does >> some build testing. I prefer buildbot mainly because I was unable to find >> very much documentation for tinderbox, but it might be worth looking at. >> > To be honest I did not find much documentation about tinderbox either. > What I've noticed is that openSUSE Build Service offers a "drop the > distro specific build script here" approach while handling all major > distributions. Scons and Android builds are still a bit of a mist though. > > Thanks for the input Tom, I'll need to take a look at > tinderbox/buildbot/obs more closely. mesa master gets built in the X.org tinderbox as well, Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73776] New: NameError: name 'libloader' is not defined:
https://bugs.freedesktop.org/show_bug.cgi?id=73776
Priority: medium
Bug ID: 73776
Keywords: regression
CC: emil.l.veli...@gmail.com, i...@freedesktop.org,
k...@bitplanet.net, robcl...@freedesktop.org
Assignee: mesa-dev@lists.freedesktop.org
Summary: NameError: name 'libloader' is not defined:
Severity: blocker
Classification: Unclassified
OS: Linux (All)
Reporter: v...@freedesktop.org
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Mesa core
Product: Mesa
mesa: 66fd5057d3ee1b3a7bce484eb0856b318a8ae4a4 (master)
$ scons platform=windows toolchain=crossmingw machine=x86_64
scons: Reading SConscript files ...
Mkdir("build/windows-x86_64-debug")
Checking for X11 (x11 xext xdamage xfixes)... no
Checking for XCB (x11-xcb xcb-glx >= 1.8.1)... no
Checking for XF86VIDMODE (xxf86vm)... no
Checking for DRM (libdrm >= 2.4.24)... no
Checking for DRM_INTEL (libdrm_intel >= 2.4.30)... no
Checking for XORG (xorg-server >= 1.6.0)... no
Checking for KMS (libkms >= 2.4.24)... no
Checking for UDEV (libudev > 150)... no
Mkdir("build/linux-x86_64-debug")
Checking for X11 (x11 xext xdamage xfixes)... yes
Checking for XCB (x11-xcb xcb-glx >= 1.8.1)... yes
Checking for XF86VIDMODE (xxf86vm)... yes
Checking for DRM (libdrm >= 2.4.24)... yes
Checking for DRM_INTEL (libdrm_intel >= 2.4.30)... yes
Checking for XORG (xorg-server >= 1.6.0)... yes
Checking for KMS (libkms >= 2.4.24)... no
Checking for UDEV (libudev > 150)... yes
warning: LLVM disabled: not building llvmpipe
NameError: name 'libloader' is not defined:
File "mesa/SConstruct", line 151:
duplicate = 0 # http://www.scons.org/doc/0.97/HTML/scons-user/x2261.html
File "/usr/lib/scons/SCons/Script/SConscript.py", line 609:
return method(*args, **kw)
File "/usr/lib/scons/SCons/Script/SConscript.py", line 546:
return _SConscript(self.fs, *files, **subst_kw)
File "/usr/lib/scons/SCons/Script/SConscript.py", line 260:
exec _file_ in call_stack[-1].globals
File "mesa/src/SConscript", line 40:
SConscript('gallium/SConscript')
File "/usr/lib/scons/SCons/Script/SConscript.py", line 609:
return method(*args, **kw)
File "/usr/lib/scons/SCons/Script/SConscript.py", line 546:
return _SConscript(self.fs, *files, **subst_kw)
File "/usr/lib/scons/SCons/Script/SConscript.py", line 260:
exec _file_ in call_stack[-1].globals
File "mesa/src/gallium/SConscript", line 104:
'targets/egl-static/SConscript'
File "/usr/lib/scons/SCons/Script/SConscript.py", line 609:
return method(*args, **kw)
File "/usr/lib/scons/SCons/Script/SConscript.py", line 546:
return _SConscript(self.fs, *files, **subst_kw)
File "/usr/lib/scons/SCons/Script/SConscript.py", line 260:
exec _file_ in call_stack[-1].globals
File "mesa/src/gallium/targets/egl-static/SConscript", line 34:
libloader,
a9800242244098fddcd2b963d8f5ccda5dea8290 is the first bad commit
commit a9800242244098fddcd2b963d8f5ccda5dea8290
Author: Emil Velikov
Date: Sat Jan 11 03:12:40 2014 +
egl-static: use loader util lib
v2
* Drop the no longer used _EGL_NO_DRM from Android.mk.
Signed-off-by: Emil Velikov
Reviewed-by: Rob Clark
Reviewed-by: Kristian Høgsberg
Reviewed-by: Ian Romanick
:04 04 dd180e65eca7266da9b8ea17515d1973bb7bb0fc
ed1eafc5c7026acc4ebcfb44b0a3b8db71464b51 M src
bisect run success
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73777] New: xf86drm.h:40:17: error: drm.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=73777 Priority: medium Bug ID: 73777 Keywords: regression CC: emil.l.veli...@gmail.com, i...@freedesktop.org, robcl...@freedesktop.org Assignee: mesa-dev@lists.freedesktop.org Summary: xf86drm.h:40:17: error: drm.h: No such file or directory Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa mesa: 66fd5057d3ee1b3a7bce484eb0856b318a8ae4a4 (master) swrast build regression on Ubuntu 10.04 $ ./autogen.sh --disable-dri --disable-egl --with-dri-drivers=swrast --with-gallium-drivers= $ make [...] CC libloader_la-loader.lo In file included from loader.c:72: /usr/include/xf86drm.h:40:17: error: drm.h: No such file or directory 8c2e7fd8460750543367053b1be9368cc38e1d6a is the first bad commit commit 8c2e7fd8460750543367053b1be9368cc38e1d6a Author: Emil Velikov Date: Fri Jan 10 23:36:16 2014 + loader: introduce the loader util lib All the various window system integration layers duplicate roughly the same code for figuring out device and driver name, pci-id's, etc. Which is sad. So extract it out into a loader util lib. v2 (Emil) * Separate the introduction of libloader from the code de-duplication. * Strip out non-pci devices support. * Add scons + Android build system support. * Add VISIBILITY_CFLAGS to avoid exporting the loader funcs. v3 (Emil) * PIPE_OS_ANDROID is undefined at this scope, use ANDROID * Make sure we define _EGL_NO_DRM when building only swrast Signed-off-by: Rob Clark Signed-off-by: Emil Velikov Reviewed-by: Rob Clark Reviewed-by: Kristian Høgsberg Reviewed-by: Ian Romanick :100644 100644 c3c1f08f01d2e27a1d38cb549dcd288b013ba09d 05ed62f594188852830b9683e1f39d3b04a82405 M Android.mk :100644 100644 4da6c51d36bbdecc55952f8b3de73bb7b124ee79 9ca6704a3e13dfb2fb9d5ffe4b363850b4186e48 M configure.ac :04 04 22d3dff995203b1a74224904b5f005f4abb486ce eded964be918ba2c0ea997a455b8e868f77274c6 M include :04 04 a7b6a5e28620f308a5a74cfe8f9a8038ca8e7b0c a917e5ed832cf30906b2de09a114d0ac0b0acbc0 M src -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Only update renderbuffers on initial intelMakeCurrent
On Fri, Jan 17, 2014 at 5:49 PM, Matt Turner wrote: > On Fri, Jan 17, 2014 at 5:21 PM, Kristian Høgsberg wrote: >> We call intel_prepare_render() in intelMakeCurrent() to make sure we have >> renderbuffers before calling _mesa_make_current(). The only reason we >> do this is so that we can have valid defaults for width and height. >> If we already have buffers for the drawable we're making current, we >> don't need to do this. >> >> In itself, this is a small optimization, but it also avoids a round trip >> that could block on the display server in a unexpected place. >> >> https://bugs.freedesktop.org/show_bug.cgi?id=72540 >> https://bugs.freedesktop.org/show_bug.cgi?id=72612 >> >> Signed-off-by: Kristian Høgsberg >> Review-by: Chad Versace > > Reviewed. :) Oops, I typoed. Thanks. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] loader: ifdef libdrm specific code and include
Mesa provides the flexibility of building without the
need to have libdrm present on the system. The situation
has regressed with the recent commit
This is a regression caused by commit
commit 8c2e7fd8460750543367053b1be9368cc38e1d6a
Author: Emil Velikov
Date: Fri Jan 10 23:36:16 2014 +
loader: introduce the loader util lib
By isolating libdrm code by #ifndef __NOT_HAVE_DRM_H we
can have libdrm-less builds on across all build systems.
This patch converts Android's _EGL_NO_DRM to __NOT_HAVE_DRM_H
to provide consistency with the other cases within mesa, allows
compilation of libloader on scons and conditionally links
against libdrm if present under automake.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73776
BUgzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73777
Signed-off-by: Emil Velikov
---
configure.ac | 1 +
src/loader/Android.mk | 2 +-
src/loader/Makefile.am | 13 +++--
src/loader/SConscript | 5 +
src/loader/loader.c| 7 ++-
5 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9ca6704..d9e1896 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1935,6 +1935,7 @@ AM_CONDITIONAL(HAVE_MESA_LLVM, test x$MESA_LLVM = x1)
AC_SUBST([ELF_LIB])
AM_CONDITIONAL(DRICOMMON_NEED_LIBDRM, test "x$DRICOMMON_NEED_LIBDRM" = xyes)
+AM_CONDITIONAL(HAVE_LIBDRM, test "x$have_libdrm" = xyes)
AM_CONDITIONAL(HAVE_X11_DRIVER, test "x$enable_xlib_glx" = xyes)
AM_CONDITIONAL(HAVE_OSMESA, test "x$enable_osmesa" = xyes)
AM_CONDITIONAL(HAVE_GALLIUM_OSMESA, test "x$enable_gallium_osmesa" = xyes)
diff --git a/src/loader/Android.mk b/src/loader/Android.mk
index 01699dc..6890af4 100644
--- a/src/loader/Android.mk
+++ b/src/loader/Android.mk
@@ -35,7 +35,7 @@ LOCAL_SRC_FILES := \
# swrast only
ifeq ($(MESA_GPU_DRIVERS),swrast)
- LOCAL_CFLAGS += -D_EGL_NO_DRM
+ LOCAL_CFLAGS += -D__NOT_HAVE_DRM_H
else
LOCAL_C_INCLUDES += \
$(DRM_TOP)/include/drm \
diff --git a/src/loader/Makefile.am b/src/loader/Makefile.am
index a118fef..371dd57 100644
--- a/src/loader/Makefile.am
+++ b/src/loader/Makefile.am
@@ -27,11 +27,20 @@ libloader_la_CPPFLAGS = \
$(DEFINES) \
-I$(top_srcdir)/include \
$(VISIBILITY_CFLAGS) \
- $(LIBDRM_CFLAGS) \
$(LIBUDEV_CFLAGS)
libloader_la_LIBADD = \
- $(LIBDRM_LIBS) \
$(LIBUDEV_LIBS)
+if !HAVE_LIBDRM
+libloader_la_CPPFLAGS += \
+ -D__NOT_HAVE_DRM_H
+else
+libloader_la_CPPFLAGS += \
+ $(LIBDRM_CFLAGS)
+
+libloader_la_LIBADD += \
+ $(LIBDRM_LIBS)
+endif
+
libloader_la_SOURCES = $(LOADER_C_FILES)
diff --git a/src/loader/SConscript b/src/loader/SConscript
index 76b0871..359fc18 100644
--- a/src/loader/SConscript
+++ b/src/loader/SConscript
@@ -1,15 +1,12 @@
Import('*')
-if not env['drm']:
-Return()
-
env = env.Clone()
env.Prepend(CPPPATH = [
'#include'
])
-env.PkgUseModules('DRM')
+env.Append(CPPDEFINES = ['__NOT_HAVE_DRM_H'])
if env['udev']:
env.PkgUseModules('UDEV')
diff --git a/src/loader/loader.c b/src/loader/loader.c
index 108e444..6fe8c8f 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -69,7 +69,9 @@
#include
#include "loader.h"
+#ifndef __NOT_HAVE_DRM_H
#include
+#endif
#define __IS_LOADER
#include "pci_ids/pci_id_driver_map.h"
@@ -149,7 +151,7 @@ out:
return (*chip_id >= 0);
}
-#elif defined(ANDROID) && !defined(_EGL_NO_DRM)
+#elif defined(ANDROID) && !defined(__NOT_HAVE_DRM_H)
/* for i915 */
#include
@@ -267,6 +269,8 @@ loader_get_driver_for_fd(int fd, unsigned driver_types)
driver_types = _LOADER_GALLIUM | _LOADER_DRI;
if (!loader_get_pci_id_for_fd(fd, &vendor_id, &chip_id)) {
+
+#ifndef __NOT_HAVE_DRM_H
/* fallback to drmGetVersion(): */
drmVersionPtr version = drmGetVersion(fd);
@@ -279,6 +283,7 @@ loader_get_driver_for_fd(int fd, unsigned driver_types)
log(_LOADER_INFO, "using driver %s for %d", driver, fd);
drmFreeVersion(version);
+#endif
return driver;
}
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73777] xf86drm.h:40:17: error: drm.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=73777 --- Comment #1 from Emil Velikov --- Created attachment 92371 --> https://bugs.freedesktop.org/attachment.cgi?id=92371&action=edit handle builds whenever libdrm is not installed Nice catch Vinson, I had to move my libdrm.pc to reproduce this and the other issue (bug 73776) :) Either way this patch handles all three build system failures, so let me know if you're still having problems. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73776] NameError: name 'libloader' is not defined:
https://bugs.freedesktop.org/show_bug.cgi?id=73776 --- Comment #1 from Emil Velikov --- Created attachment 92372 --> https://bugs.freedesktop.org/attachment.cgi?id=92372&action=edit handle builds whenever libdrm is not installed As mentioned in bug 73777 I've folded all three possible fixes in a single patch, to minimise disruption, but if you prefer I can split them apart. Patch identical to the one in bug 73777 attached. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.
On 01/17/2014 01:57 PM, Chris Forbes wrote: > Ken, > > Assuming the caches don't completely derail things, you ought to be > able to make this work with pretty minimal impact: > > - Keep the low four bits of the sampler index where they are > - If the 5th bit is set: > - Force message header on > - Add 16*sizeof(sampler_state) to the copy of r0.3 in the header. Hey, thanks! I forgot we get a copy of the sampler state table pointer in the r0.3 header. With that, it's totally easy. The one sad thing is that the message header field only exists on Haswell+. It's documented in the Ivybridge PRM, but empirically the PRM appears to be flat wrong. Ah well...new features on new hardware, I guess. > We already mangle the copy of r0.2 in various ways for offsetting / > channel select so this isn't a huge change. > > With 4.0/ARB_gpu_shader5 you need to emit conditional code in some > cases since you don't always know the sampler index at compile time, > but it's still pretty manageable. > > -- Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Add some informative debug when the X Server botches DRI2 GetBuffers.
On 01/18/2014 10:27 AM, Eric Anholt wrote:
> We've had various bug reports over the years where miptrees are missing,
> and when I screwed it up while adding DRI2 to the modesetting driver, I
> figured I should put the info necessary for debug here.
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 51918b9..e2d7c6d 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -1257,14 +1257,24 @@ intel_process_dri2_buffer(struct brw_context *brw,
>buffer->pitch,
>buffer->name,
>buffer_name);
> - if (!region)
> + if (!region) {
> + fprintf(stderr,
> + "Failed to make region for returned DRI2 buffer "
> + "(%dx%d, named %d).\n"
> + "This is likely a bug in the X Server that will lead to a "
> + "crash soon.\n",
> + drawable->w, drawable->h, buffer->name);
>return;
> + }
>
> rb->mt = intel_miptree_create_for_dri2_buffer(brw,
> buffer->attachment,
> intel_rb_format(rb),
> num_samples,
> region);
> +
> + assert(rb->mt);
> +
> intel_region_release(®ion);
> }
>
>
Reviewed-by: Kenneth Graunke
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Remove redundant check in blitter-based glBlitFramebuffer().
On 01/18/2014 10:30 AM, Eric Anholt wrote:
> The intel_miptree_blit() code checks the format for us now, plus it
> handles xrgb vs argb for us.
> ---
> src/mesa/drivers/dri/i965/intel_fbo.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
> b/src/mesa/drivers/dri/i965/intel_fbo.c
> index f094718..7323781 100644
> --- a/src/mesa/drivers/dri/i965/intel_fbo.c
> +++ b/src/mesa/drivers/dri/i965/intel_fbo.c
> @@ -739,16 +739,6 @@ intel_blit_framebuffer_with_blitter(struct gl_context
> *ctx,
> return mask;
> }
>
> - gl_format src_format = _mesa_get_srgb_format_linear(src_rb->Format);
> - gl_format dst_format = _mesa_get_srgb_format_linear(dst_rb->Format);
> - if (src_format != dst_format) {
> -perf_debug("glBlitFramebuffer(): unsupported blit from %s to %s.
> "
> - "Falling back to software rendering.\n",
> - _mesa_get_format_name(src_format),
> - _mesa_get_format_name(dst_format));
> -return mask;
> - }
> -
> if (!intel_miptree_blit(brw,
> src_irb->mt,
> src_irb->mt_level, src_irb->mt_layer,
Reviewed-by: Kenneth Graunke
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] loader: ifdef libdrm specific code and include
On 01/18/2014 07:23 PM, Emil Velikov wrote:
> Mesa provides the flexibility of building without the
> need to have libdrm present on the system. The situation
> has regressed with the recent commit
>
> This is a regression caused by commit
> commit 8c2e7fd8460750543367053b1be9368cc38e1d6a
> Author: Emil Velikov
> Date: Fri Jan 10 23:36:16 2014 +
>
> loader: introduce the loader util lib
>
> By isolating libdrm code by #ifndef __NOT_HAVE_DRM_H we
> can have libdrm-less builds on across all build systems.
>
> This patch converts Android's _EGL_NO_DRM to __NOT_HAVE_DRM_H
> to provide consistency with the other cases within mesa, allows
> compilation of libloader on scons and conditionally links
> against libdrm if present under automake.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73776
> BUgzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73777
> Signed-off-by: Emil Velikov
> ---
> configure.ac | 1 +
> src/loader/Android.mk | 2 +-
> src/loader/Makefile.am | 13 +++--
> src/loader/SConscript | 5 +
> src/loader/loader.c| 7 ++-
> 5 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 9ca6704..d9e1896 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1935,6 +1935,7 @@ AM_CONDITIONAL(HAVE_MESA_LLVM, test x$MESA_LLVM = x1)
> AC_SUBST([ELF_LIB])
>
> AM_CONDITIONAL(DRICOMMON_NEED_LIBDRM, test "x$DRICOMMON_NEED_LIBDRM" = xyes)
> +AM_CONDITIONAL(HAVE_LIBDRM, test "x$have_libdrm" = xyes)
> AM_CONDITIONAL(HAVE_X11_DRIVER, test "x$enable_xlib_glx" = xyes)
> AM_CONDITIONAL(HAVE_OSMESA, test "x$enable_osmesa" = xyes)
> AM_CONDITIONAL(HAVE_GALLIUM_OSMESA, test "x$enable_gallium_osmesa" = xyes)
> diff --git a/src/loader/Android.mk b/src/loader/Android.mk
> index 01699dc..6890af4 100644
> --- a/src/loader/Android.mk
> +++ b/src/loader/Android.mk
> @@ -35,7 +35,7 @@ LOCAL_SRC_FILES := \
>
> # swrast only
> ifeq ($(MESA_GPU_DRIVERS),swrast)
> - LOCAL_CFLAGS += -D_EGL_NO_DRM
> + LOCAL_CFLAGS += -D__NOT_HAVE_DRM_H
> else
> LOCAL_C_INCLUDES += \
> $(DRM_TOP)/include/drm \
> diff --git a/src/loader/Makefile.am b/src/loader/Makefile.am
> index a118fef..371dd57 100644
> --- a/src/loader/Makefile.am
> +++ b/src/loader/Makefile.am
> @@ -27,11 +27,20 @@ libloader_la_CPPFLAGS = \
> $(DEFINES) \
> -I$(top_srcdir)/include \
> $(VISIBILITY_CFLAGS) \
> - $(LIBDRM_CFLAGS) \
> $(LIBUDEV_CFLAGS)
>
> libloader_la_LIBADD = \
> - $(LIBDRM_LIBS) \
> $(LIBUDEV_LIBS)
>
> +if !HAVE_LIBDRM
> +libloader_la_CPPFLAGS += \
> + -D__NOT_HAVE_DRM_H
> +else
> +libloader_la_CPPFLAGS += \
> + $(LIBDRM_CFLAGS)
> +
> +libloader_la_LIBADD += \
> + $(LIBDRM_LIBS)
> +endif
> +
> libloader_la_SOURCES = $(LOADER_C_FILES)
> diff --git a/src/loader/SConscript b/src/loader/SConscript
> index 76b0871..359fc18 100644
> --- a/src/loader/SConscript
> +++ b/src/loader/SConscript
> @@ -1,15 +1,12 @@
> Import('*')
>
> -if not env['drm']:
> -Return()
> -
> env = env.Clone()
>
> env.Prepend(CPPPATH = [
> '#include'
> ])
>
> -env.PkgUseModules('DRM')
> +env.Append(CPPDEFINES = ['__NOT_HAVE_DRM_H'])
>
> if env['udev']:
> env.PkgUseModules('UDEV')
> diff --git a/src/loader/loader.c b/src/loader/loader.c
> index 108e444..6fe8c8f 100644
> --- a/src/loader/loader.c
> +++ b/src/loader/loader.c
> @@ -69,7 +69,9 @@
> #include
> #include "loader.h"
>
> +#ifndef __NOT_HAVE_DRM_H
> #include
> +#endif
>
> #define __IS_LOADER
> #include "pci_ids/pci_id_driver_map.h"
> @@ -149,7 +151,7 @@ out:
> return (*chip_id >= 0);
> }
>
> -#elif defined(ANDROID) && !defined(_EGL_NO_DRM)
> +#elif defined(ANDROID) && !defined(__NOT_HAVE_DRM_H)
>
> /* for i915 */
> #include
> @@ -267,6 +269,8 @@ loader_get_driver_for_fd(int fd, unsigned driver_types)
>driver_types = _LOADER_GALLIUM | _LOADER_DRI;
>
> if (!loader_get_pci_id_for_fd(fd, &vendor_id, &chip_id)) {
> +
> +#ifndef __NOT_HAVE_DRM_H
>/* fallback to drmGetVersion(): */
>drmVersionPtr version = drmGetVersion(fd);
>
> @@ -279,6 +283,7 @@ loader_get_driver_for_fd(int fd, unsigned driver_types)
>log(_LOADER_INFO, "using driver %s for %d", driver, fd);
>
>drmFreeVersion(version);
> +#endif
>
>return driver;
> }
>
Looks reasonable to me. Thanks for cleaning up the loader stuff, Emil!
Reviewed-by: Kenneth Graunke
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/10] i965/vec4: Support arbitrarily large sampler state indices on Haswell+.
Like the scalar backend, we add an offset to the "Sampler State Pointer"
field to select a group of 16 samplers, then use the "Sampler Index"
field to select within that group.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 19 ++-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 10 --
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index d40c8d4..99f83a4 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
@@ -387,6 +387,23 @@ vec4_generator::generate_tex(vec4_instruction *inst,
brw_MOV(p, get_element_ud(header, 2),
brw_imm_ud(inst->texture_offset));
}
+
+ if (inst->sampler >= 16) {
+/* The "Sampler Index" field can only store values between 0 and
15.
+ * However, we can add an offset to the "Sampler State Pointer"
+ * field, effectively selecting a different set of 16 samplers.
+ *
+ * The "Sampler State Pointer" needs to be aligned to a 32-byte
+ * offset, and each sampler state is only 16-bytes, so we can't
+ * exclusively use the offset - we have to use both.
+ */
+assert(brw->is_haswell); /* field only exists on Haswell */
+brw_ADD(p,
+get_element_ud(header, 3),
+get_element_ud(brw_vec8_grf(0, 0), 3),
+brw_imm_ud(16 * (inst->sampler / 16) *
+ sizeof(gen7_sampler_state)));
+ }
brw_pop_insn_state(p);
}
}
@@ -415,7 +432,7 @@ vec4_generator::generate_tex(vec4_instruction *inst,
inst->base_mrf,
src,
surface_index,
- inst->sampler,
+ inst->sampler % 16,
msg_type,
1, /* response length */
inst->mlen,
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 2b6f3e9..f7e45e7 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -2370,9 +2370,15 @@ vec4_visitor::visit(ir_texture *ir)
if (ir->op == ir_tg4)
inst->texture_offset |= gather_channel(ir, sampler)<<16;
- /* Texel offsets go in the message header; Gen4 also requires headers. */
+ /* The message header is necessary for:
+* - Gen4 (always)
+* - Texel offsets
+* - Gather channel selection
+* - Sampler indices too large to fit in a 4-bit value.
+*/
inst->header_present =
- brw->gen < 5 || inst->texture_offset != 0 || ir->op == ir_tg4;
+ brw->gen < 5 || inst->texture_offset != 0 || ir->op == ir_tg4 ||
+ sampler >= 16;
inst->base_mrf = 2;
inst->mlen = inst->header_present + 1; /* always at least one */
inst->sampler = sampler;
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/10] i965: Support 32 texture image units on Haswell+.
The Intel closed source OpenGL driver recently began supporting 32
texture image units on Haswell. This makes the open source driver
support 32 as well.
Earlier generations don't have the message header field required to
support more than 16 sampler states, so we continue to advertise 16
there.
On Haswell, this causes us to advertise:
- GL_MAX_TEXTURE_IMAGE_UNITS = 32
- GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS = 32
- GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS = 96
instead of the old values of 16, 16, and 48.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.c | 9 ++---
src/mesa/drivers/dri/i965/brw_context.h | 2 +-
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 1b42751..806f3db 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -282,20 +282,23 @@ brw_initialize_context_constants(struct brw_context *brw)
{
struct gl_context *ctx = &brw->ctx;
+ unsigned max_samplers =
+ brw->gen >= 8 || brw->is_haswell ? BRW_MAX_TEX_UNIT : 16;
+
ctx->Const.QueryCounterBits.Timestamp = 36;
ctx->Const.StripTextureBorder = true;
ctx->Const.MaxDualSourceDrawBuffers = 1;
ctx->Const.MaxDrawBuffers = BRW_MAX_DRAW_BUFFERS;
- ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits =
BRW_MAX_TEX_UNIT;
+ ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits =
max_samplers;
ctx->Const.MaxTextureCoordUnits = 8; /* Mesa limit */
ctx->Const.MaxTextureUnits =
MIN2(ctx->Const.MaxTextureCoordUnits,
ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits);
- ctx->Const.Program[MESA_SHADER_VERTEX].MaxTextureImageUnits =
BRW_MAX_TEX_UNIT;
+ ctx->Const.Program[MESA_SHADER_VERTEX].MaxTextureImageUnits = max_samplers;
if (brw->gen >= 7)
- ctx->Const.Program[MESA_SHADER_GEOMETRY].MaxTextureImageUnits =
BRW_MAX_TEX_UNIT;
+ ctx->Const.Program[MESA_SHADER_GEOMETRY].MaxTextureImageUnits =
max_samplers;
else
ctx->Const.Program[MESA_SHADER_GEOMETRY].MaxTextureImageUnits = 0;
ctx->Const.MaxCombinedTextureImageUnits =
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 63dd4a0..5908659 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -650,7 +650,7 @@ struct brw_gs_prog_data
};
/** Number of texture sampler units */
-#define BRW_MAX_TEX_UNIT 16
+#define BRW_MAX_TEX_UNIT 32
/** Max number of render targets in a shader */
#define BRW_MAX_DRAW_BUFFERS 8
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/10] i965/fs: Support arbitrarily large sampler state indices on Haswell+.
The message descriptor's "Sampler Index" field is only 4 bits (on all
generations of hardware), so it can only represent indices 0 through 15.
Haswell introduced a new field in the message header - "Sampler State
Pointer". Normally, this is copied straight from g0, but we can also
add a byte offset (as long as it's a multiple of 32).
This patch uses a "Sampler State Pointer" offset to select a group of
16 sampler states, and then uses the "Sampler Index" field to select
the state within that group.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 19 ++-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 5 -
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index a228036..1d5756e 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -559,6 +559,23 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg
dst, struct brw_reg src
brw_MOV(p, get_element_ud(header_reg, 2),
brw_imm_ud(inst->texture_offset));
}
+
+ if (inst->sampler >= 16) {
+/* The "Sampler Index" field can only store values between 0 and
15.
+ * However, we can add an offset to the "Sampler State Pointer"
+ * field, effectively selecting a different set of 16 samplers.
+ *
+ * The "Sampler State Pointer" needs to be aligned to a 32-byte
+ * offset, and each sampler state is only 16-bytes, so we can't
+ * exclusively use the offset - we have to use both.
+ */
+assert(brw->is_haswell); /* field only exists on Haswell */
+brw_ADD(p,
+get_element_ud(header_reg, 3),
+get_element_ud(brw_vec8_grf(0, 0), 3),
+brw_imm_ud(16 * (inst->sampler / 16) *
+ sizeof(gen7_sampler_state)));
+ }
brw_pop_insn_state(p);
}
}
@@ -573,7 +590,7 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg
dst, struct brw_reg src
inst->base_mrf,
src,
surface_index,
- inst->sampler,
+ inst->sampler % 16,
msg_type,
rlen,
inst->mlen,
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 027e5e7..4872bf8 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1249,13 +1249,16 @@ fs_visitor::emit_texture_gen7(ir_texture *ir, fs_reg
dst, fs_reg coordinate,
fs_reg payload = fs_reg(this, glsl_type::float_type);
fs_reg next = payload;
- if (ir->op == ir_tg4 || (ir->offset && ir->op != ir_txf)) {
+ if (ir->op == ir_tg4 || (ir->offset && ir->op != ir_txf) || sampler >= 16) {
/* For general texture offsets (no txf workaround), we need a header to
* put them in. Note that for 16-wide we're making space for two actual
* hardware registers here, so the emit will have to fix up for this.
*
* * ir4_tg4 needs to place its channel select in the header,
* for interaction with ARB_texture_swizzle
+ *
+ * The sampler index is only 4-bits, so for larger sampler numbers we
+ * need to offset the Sampler State Pointer in the header.
*/
header_present = true;
next.reg_offset++;
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/10] i965/fs: Switch from BRW_MAX_TEX_UNIT to the actual limit.
BRW_MAX_TEX_UNIT is about to grow, but only Gen7+ will be able to
support the new larger value. On older platforms, we don't want to
allocate the extra space - it would just be a waste.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_wm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
b/src/mesa/drivers/dri/i965/brw_wm.c
index 6739a91..0020b5d 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -142,6 +142,7 @@ bool do_wm_prog(struct brw_context *brw,
struct brw_fragment_program *fp,
struct brw_wm_prog_key *key)
{
+ struct gl_context *ctx = &brw->ctx;
struct brw_wm_compile *c;
const GLuint *program;
struct gl_shader *fs = NULL;
@@ -163,7 +164,7 @@ bool do_wm_prog(struct brw_context *brw,
param_count = fp->program.Base.Parameters->NumParameters * 4;
}
/* The backend also sometimes adds params for texture size. */
- param_count += 2 * BRW_MAX_TEX_UNIT;
+ param_count += 2 *
ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits;
c->prog_data.param = rzalloc_array(NULL, const float *, param_count);
c->prog_data.pull_param = rzalloc_array(NULL, const float *, param_count);
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/10] i965/vec4: Refactor sampler message setup.
The next patch adds an additional case where the message header is
necessary. So we want to do the g0 copy if inst->header_present is set,
rather than inst->texture_offset.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 39 +---
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index c1ef81d..d40c8d4 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
@@ -367,23 +367,28 @@ vec4_generator::generate_tex(vec4_instruction *inst,
* to set it up explicitly and load the offset bitfield. Otherwise, we can
* use an implied move from g0 to the first message register.
*/
- if (inst->texture_offset) {
- /* Explicitly set up the message header by copying g0 to the MRF. */
- brw_push_insn_state(p);
- brw_set_mask_control(p, BRW_MASK_DISABLE);
- brw_MOV(p, retype(brw_message_reg(inst->base_mrf), BRW_REGISTER_TYPE_UD),
-retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD));
-
- /* Then set the offset bits in DWord 2. */
- brw_set_access_mode(p, BRW_ALIGN_1);
- brw_MOV(p,
- retype(brw_vec1_reg(BRW_MESSAGE_REGISTER_FILE, inst->base_mrf, 2),
-BRW_REGISTER_TYPE_UD),
- brw_imm_ud(inst->texture_offset));
- brw_pop_insn_state(p);
- } else if (inst->header_present) {
- /* Set up an implied move from g0 to the MRF. */
- src = brw_vec8_grf(0, 0);
+ if (inst->header_present) {
+ if (brw->gen < 6 && !inst->texture_offset) {
+ /* Set up an implied move from g0 to the MRF. */
+ src = brw_vec8_grf(0, 0);
+ } else {
+ struct brw_reg header =
+retype(brw_message_reg(inst->base_mrf), BRW_REGISTER_TYPE_UD);
+
+ /* Explicitly set up the message header by copying g0 to the MRF. */
+ brw_push_insn_state(p);
+ brw_set_mask_control(p, BRW_MASK_DISABLE);
+ brw_MOV(p, header, retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD));
+
+ brw_set_access_mode(p, BRW_ALIGN_1);
+
+ if (inst->texture_offset) {
+/* Set the texel offset bits in DWord 2. */
+brw_MOV(p, get_element_ud(header, 2),
+brw_imm_ud(inst->texture_offset));
+ }
+ brw_pop_insn_state(p);
+ }
}
uint32_t return_format;
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/10] i965: Use get_element_ud to shorten texture header access.
This is shorter, easier to read, and further from the 80 column limit.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 2bbf687..6fe8fcb 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -550,8 +550,7 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg
dst, struct brw_reg src
brw_MOV(p, header_reg, brw_vec8_grf(0, 0));
/* Then set the offset bits in DWord 2. */
- brw_MOV(p, retype(brw_vec1_reg(header_reg.file,
- header_reg.nr, 2), BRW_REGISTER_TYPE_UD),
+ brw_MOV(p, get_element_ud(header_reg, 2),
brw_imm_ud(inst->texture_offset));
brw_pop_insn_state(p);
} else if (inst->header_present) {
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/10] i965/vec4: Don't set header_present if texel offsets are all 0.
In theory, a shader might use textureOffset() but set all the texel offsets to zero. In that case, we don't actually need to set up the message header - zero is the implicit default. By moving the texture_offset setup before the header_present setup, we can easily only set header_present when there are non-zero texel offset values. Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index 3b8cef6..2b6f3e9 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -2363,10 +2363,16 @@ vec4_visitor::visit(ir_texture *ir) assert(!"Unrecognized tex op"); } - bool use_texture_offset = ir->offset != NULL && ir->op != ir_txf; + if (ir->offset != NULL && ir->op != ir_txf) + inst->texture_offset = brw_texture_offset(ctx, ir->offset->as_constant()); + + /* Stuff the channel select bits in the top of the texture offset */ + if (ir->op == ir_tg4) + inst->texture_offset |= gather_channel(ir, sampler)<<16; /* Texel offsets go in the message header; Gen4 also requires headers. */ - inst->header_present = use_texture_offset || brw->gen < 5 || ir->op == ir_tg4; + inst->header_present = + brw->gen < 5 || inst->texture_offset != 0 || ir->op == ir_tg4; inst->base_mrf = 2; inst->mlen = inst->header_present + 1; /* always at least one */ inst->sampler = sampler; @@ -2374,13 +2380,6 @@ vec4_visitor::visit(ir_texture *ir) inst->dst.writemask = WRITEMASK_XYZW; inst->shadow_compare = ir->shadow_comparitor != NULL; - if (use_texture_offset) - inst->texture_offset = brw_texture_offset(ctx, ir->offset->as_constant()); - - /* Stuff the channel select bits in the top of the texture offset */ - if (ir->op == ir_tg4) - inst->texture_offset |= gather_channel(ir, sampler)<<16; - /* MRF for the first parameter */ int param_base = inst->base_mrf + inst->header_present; -- 1.8.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/10] i965/fs: Plumb sampler index into emit_texture_gen7.
We'll need this in the next patch.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
src/mesa/drivers/dri/i965/brw_fs_fp.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 9bef07c..6af3117 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -354,7 +354,7 @@ public:
fs_reg sample_index);
fs_inst *emit_texture_gen7(ir_texture *ir, fs_reg dst, fs_reg coordinate,
fs_reg shadow_comp, fs_reg lod, fs_reg lod2,
- fs_reg sample_index, fs_reg mcs);
+ fs_reg sample_index, fs_reg mcs, int sampler);
fs_reg emit_mcs_fetch(ir_texture *ir, fs_reg coordinate, int sampler);
fs_reg fix_math_operand(fs_reg src);
fs_inst *emit_math(enum opcode op, fs_reg dst, fs_reg src0);
diff --git a/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
b/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
index f8577c1..1d42f6b 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
@@ -501,7 +501,7 @@ fs_visitor::emit_fragment_program_code()
fs_inst *inst;
if (brw->gen >= 7) {
-inst = emit_texture_gen7(ir, dst, coordinate, shadow_c, lod, dpdy,
sample_index, fs_reg(0u));
+inst = emit_texture_gen7(ir, dst, coordinate, shadow_c, lod, dpdy,
sample_index, fs_reg(0u), fpi->TexSrcUnit);
} else if (brw->gen >= 5) {
inst = emit_texture_gen5(ir, dst, coordinate, shadow_c, lod, dpdy,
sample_index);
} else {
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 53cd0a1..027e5e7 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1241,7 +1241,7 @@ fs_visitor::emit_texture_gen5(ir_texture *ir, fs_reg dst,
fs_reg coordinate,
fs_inst *
fs_visitor::emit_texture_gen7(ir_texture *ir, fs_reg dst, fs_reg coordinate,
fs_reg shadow_c, fs_reg lod, fs_reg lod2,
- fs_reg sample_index, fs_reg mcs)
+ fs_reg sample_index, fs_reg mcs, int sampler)
{
int reg_width = dispatch_width / 8;
bool header_present = false;
@@ -1663,7 +1663,7 @@ fs_visitor::visit(ir_texture *ir)
if (brw->gen >= 7) {
inst = emit_texture_gen7(ir, dst, coordinate, shadow_comparitor,
- lod, lod2, sample_index, mcs);
+ lod, lod2, sample_index, mcs, sampler);
} else if (brw->gen >= 5) {
inst = emit_texture_gen5(ir, dst, coordinate, shadow_comparitor,
lod, lod2, sample_index);
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/10] mesa: Bump MAX_TEXTURE_IMAGE_UNITS to 32.
This allows drivers to optionally support more than 16 texture units. Signed-off-by: Kenneth Graunke --- src/mesa/main/config.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h index ff9da77..9df4a6e 100644 --- a/src/mesa/main/config.h +++ b/src/mesa/main/config.h @@ -121,7 +121,7 @@ * Max number of texture image units. Also determines number of texture * samplers in shaders. */ -#define MAX_TEXTURE_IMAGE_UNITS 16 +#define MAX_TEXTURE_IMAGE_UNITS 32 /** * Larger of MAX_TEXTURE_COORD_UNITS and MAX_TEXTURE_IMAGE_UNITS. -- 1.8.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/10] i965/fs: Refactor sampler message header to duplicate less code.
Previously, the code to copy g0 to the message header existed in two
places - one for the texture offset case, and one for any other case.
By treating texture_offset as a special case of header_present, we can
remove this duplication and shorten the code. Future patches which add
new header fields also won't have to add additional duplication.
This also clarifies a confusing construct. The old code contained:
} else if (inst->header_present) {
if (brw->gen >= 7) {
...explicit copy from g0 to the message header...
} else {
/* Set up an implied move from g0 to the MRF. */
}
}
This looks like it might set up an implied move on Sandybridge, which
doesn't support those. However, Sandybridge only uses a message header
for texture offsets, so it would never hit this code path. The new code
avoids this implicit knowledge by only setting up an implied move on
Gen4-5.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 46 --
1 file changed, 21 insertions(+), 25 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 6fe8fcb..a228036 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -534,36 +534,32 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg
dst, struct brw_reg src
* we need to set it up explicitly and load the offset bitfield.
* Otherwise, we can use an implied move from g0 to the first message reg.
*/
- if (inst->texture_offset) {
- struct brw_reg header_reg;
-
- if (brw->gen >= 7) {
- header_reg = src;
+ if (inst->header_present) {
+ if (brw->gen < 6 && !inst->texture_offset) {
+ /* Set up an implied move from g0 to the MRF. */
+ src = retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UW);
} else {
- assert(inst->base_mrf != -1);
- header_reg = brw_message_reg(inst->base_mrf);
- }
- brw_push_insn_state(p);
- brw_set_mask_control(p, BRW_MASK_DISABLE);
- brw_set_compression_control(p, BRW_COMPRESSION_NONE);
- /* Explicitly set up the message header by copying g0 to the MRF. */
- brw_MOV(p, header_reg, brw_vec8_grf(0, 0));
-
- /* Then set the offset bits in DWord 2. */
- brw_MOV(p, get_element_ud(header_reg, 2),
- brw_imm_ud(inst->texture_offset));
- brw_pop_insn_state(p);
- } else if (inst->header_present) {
- if (brw->gen >= 7) {
- /* Explicitly set up the message header by copying g0 to the MRF. */
+ struct brw_reg header_reg;
+
+ if (brw->gen >= 7) {
+header_reg = src;
+ } else {
+assert(inst->base_mrf != -1);
+header_reg = brw_message_reg(inst->base_mrf);
+ }
+
brw_push_insn_state(p);
brw_set_mask_control(p, BRW_MASK_DISABLE);
brw_set_compression_control(p, BRW_COMPRESSION_NONE);
- brw_MOV(p, src, brw_vec8_grf(0, 0));
+ /* Explicitly set up the message header by copying g0 to the MRF. */
+ brw_MOV(p, header_reg, brw_vec8_grf(0, 0));
+
+ if (inst->texture_offset) {
+/* Set the offset bits in DWord 2. */
+brw_MOV(p, get_element_ud(header_reg, 2),
+ brw_imm_ud(inst->texture_offset));
+ }
brw_pop_insn_state(p);
- } else {
- /* Set up an implied move from g0 to the MRF. */
- src = retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UW);
}
}
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73776] NameError: name 'libloader' is not defined:
https://bugs.freedesktop.org/show_bug.cgi?id=73776
--- Comment #2 from Jos van Wolput ---
The latest git version of mesa fails to build:
-
make[3]: Entering directory
`/home/jos/src/xorg/git/mesa/src/gallium/auxiliary/pipe-loader'
CC pipe_loader_drm.lo
pipe_loader_drm.c: In function 'pipe_loader_drm_probe_fd':
pipe_loader_drm.c:120:4: error: implicit declaration of function
'loader_get_pci_id_for_fd' [-Werror=implicit-function-declaration]
if (loader_get_pci_id_for_fd(fd, &vendor_id, &chip_id)) {
^
pipe_loader_drm.c:132:4: error: implicit declaration of function
'loader_get_driver_for_fd' [-Werror=implicit-function-declaration]
ddev->base.driver_name = loader_get_driver_for_fd(fd, _LOADER_GALLIUM);
^
pipe_loader_drm.c:132:58: error: '_LOADER_GALLIUM' undeclared (first use in
this function)
ddev->base.driver_name = loader_get_driver_for_fd(fd, _LOADER_GALLIUM);
^
pipe_loader_drm.c:132:58: note: each undeclared identifier is reported only
once for each function it appears in
cc1: some warnings being treated as errors
make[3]: *** [pipe_loader_drm.lo] Error 1
make[3]: Leaving directory
`/home/jos/src/xorg/git/mesa/src/gallium/auxiliary/pipe-loader'
make[2]: *** [all-recursive] Error 1
-
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
