https://bugs.freedesktop.org/show_bug.cgi?id=74204
Emil Velikov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=74127
Emil Velikov changed:
What|Removed |Added
CC||avgd...@gmail.com
--- Comment #7 from Emi
Stéphane Marchesin writes:
> On systems without libudev, the loader_get_pci_id_for_fd() call will
> return 0, which will trigger the drmGetVersion logic. Sadly, this
> logic assumes that the kernel driver name matches the dri driver name,
> which is not the case on recent intel GPUs (for example
Note that it is OK to pass NULL pointers to this function since this commit:
mesa: modified _mesa_align_free() to accept NULL pointer
http://cgit.freedesktop.org/mesa/mesa/commit/?id=f0cc59d68a9f5231e8e2111393a1834858820735
---
src/mesa/main/bufferobj.c | 3 +--
1 file changed, 1 insertion(+), 2
On Thu, 30 Jan 2014 02:55:54 +0100
Marek Olšák wrote:
> egl_gallium also seems to have backends for Wayland, DRM, etc. I guess
> this should really be in core Mesa though.
From what I have tested, egl_gallium is also the only way to use
software rendering (llvmpipe) on Wayland. egl_dri2 simply f
On Thu, Jan 30, 2014 at 12:14 AM, Pekka Paalanen wrote:
> I suspect this is a PITA for distributions.
For Gentoo, we started enabling gallium-egl only when openvg is requested.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freede
On Thu, Jan 30, 2014 at 12:07 AM, Eric Anholt wrote:
> Stéphane Marchesin writes:
>
> > On systems without libudev, the loader_get_pci_id_for_fd() call will
> > return 0, which will trigger the drmGetVersion logic. Sadly, this
> > logic assumes that the kernel driver name matches the dri driver
On Thu, Jan 30, 2014 at 12:20 AM, Stéphane Marchesin <
stephane.marche...@gmail.com> wrote:
>
>
>
> On Thu, Jan 30, 2014 at 12:07 AM, Eric Anholt wrote:
>
>> Stéphane Marchesin writes:
>>
>> > On systems without libudev, the loader_get_pci_id_for_fd() call will
>> > return 0, which will trigger
> @@ -487,6 +486,7 @@ setup_shader_for_sampler(struct gl_context *ctx, struct
> glsl_sampler
> *sampler)
> "void main()\n"
> "{\n"
> " gl_FragColor = %s(texSampler, %s);\n"
> +
On Don, 2014-01-30 at 02:20 +0100, Marek Olšák wrote:
> This series implements GL_ARB_buffer_storage, which most importantly
> allows rendering with mapped buffers. There is a new test on the
> piglit mailing list, which should test all aspects of persistent
> buffer mappings.
>
> I used both the
On Wed, 29 Jan 2014 17:33:23 -0800
Stéphane Marchesin wrote:
> On systems without libudev, the loader_get_pci_id_for_fd() call will
> return 0, which will trigger the drmGetVersion logic. Sadly, this
> logic assumes that the kernel driver name matches the dri driver name,
> which is not the case
Reviewed-by: Marek Olšák
Marek
On Thu, Jan 30, 2014 at 9:08 AM, Siavash Eliasi wrote:
> Note that it is OK to pass NULL pointers to this function since this commit:
>
> mesa: modified _mesa_align_free() to accept NULL pointer
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=f0cc59d68a9f5231e8
https://bugs.freedesktop.org/show_bug.cgi?id=74127
--- Comment #8 from Dmitry Avgustis ---
(In reply to comment #6)
> Indeed, mesa requires libudev v151, which provides libudev.so.0.
>
> So we can either bump the minimum required version or fall-back to
> libudev.so.0.
>
> I believe that Eric w
dri2_dup_image was not copying the dri_format field.
This was causing some bugs, for example:
. we create an gbm_bo.
. we get an EGLImage from the gbm_bo.
. Bug: impossible to get again the gbm_bo from the EGLImage by importing. (gbm
dri2 backend)
Signed-off-by: Axel Davy
---
src/gallium/state
https://bugs.freedesktop.org/show_bug.cgi?id=74127
--- Comment #9 from Scott Moreau ---
(In reply to comment #8)
> (In reply to comment #6)
> > Indeed, mesa requires libudev v151, which provides libudev.so.0.
> >
> > So we can either bump the minimum required version or fall-back to
> > libudev.
On Wed, Jan 29, 2014 at 06:23:00PM +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> V_ADD_F32 with source modifier does not produce -0.0 for this. Just
> manipulate the sign bit directly instead.
>
That's strange, so does this mean we can never use these modifiers?
> Also add a pattern fo
Am 30.01.2014 02:20, schrieb Marek Olšák:
> From: Marek Olšák
>
> Required for ARB_buffer_storage.
> ---
> src/gallium/docs/source/context.rst| 22 ++
> src/gallium/docs/source/screen.rst | 3 +++
> src/gallium/drivers/trace/tr_context.c | 16
> src/
On Tue, Jan 28, 2014 at 03:04:00PM +0100, David Herrmann wrote:
> Hi Tom
>
> On Mon, Jan 27, 2014 at 5:13 PM, Tom Stellard wrote:
> > From: Tom Stellard
> >
> > v2:
> >- Add missing call to pipe_loader_drm_release()
> >- Fix render node macros
> >- Drop render-node configure option
>
Am 30.01.2014 02:20, schrieb Marek Olšák:
> From: Marek Olšák
>
> ---
> src/gallium/auxiliary/util/u_upload_mgr.c | 65
> ---
> 1 file changed, 51 insertions(+), 14 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_upload_mgr.c
> b/src/gallium/auxiliary/ut
On Mon, Jan 27, 2014 at 05:22:06PM +0100, Erik Faye-Lund wrote:
> On Mon, Jan 27, 2014 at 5:13 PM, Tom Stellard wrote:
> > From: Tom Stellard
> >
> > The caller can use this boolean to parameter to tell the pipe-loader
>
> Boolean to parameter? A superfluous "to", perhaps?
Thanks for catching t
On Thu, Jan 30, 2014 at 5:31 PM, Roland Scheidegger wrote:
> Am 30.01.2014 02:20, schrieb Marek Olšák:
>> From: Marek Olšák
>>
>> Required for ARB_buffer_storage.
>> ---
>> src/gallium/docs/source/context.rst| 22 ++
>> src/gallium/docs/source/screen.rst | 3 +++
>>
On Thu, Jan 30, 2014 at 5:33 PM, Roland Scheidegger wrote:
> Am 30.01.2014 02:20, schrieb Marek Olšák:
>> From: Marek Olšák
>>
>> ---
>> src/gallium/auxiliary/util/u_upload_mgr.c | 65
>> ---
>> 1 file changed, 51 insertions(+), 14 deletions(-)
>>
>> diff --git a/src
Am 30.01.2014 17:50, schrieb Marek Olšák:
> On Thu, Jan 30, 2014 at 5:31 PM, Roland Scheidegger
> wrote:
>> Am 30.01.2014 02:20, schrieb Marek Olšák:
>>> From: Marek Olšák
>>>
>>> Required for ARB_buffer_storage.
>>> ---
>>> src/gallium/docs/source/context.rst| 22 ++
>>>
On Thu, Jan 30, 2014 at 6:34 PM, Roland Scheidegger wrote:
> Am 30.01.2014 17:50, schrieb Marek Olšák:
>> On Thu, Jan 30, 2014 at 5:31 PM, Roland Scheidegger
>> wrote:
>>> Am 30.01.2014 02:20, schrieb Marek Olšák:
From: Marek Olšák
Required for ARB_buffer_storage.
---
On Thu, Jan 30, 2014 at 12:20 AM, Stéphane Marchesin
wrote:
>
>
>
> On Thu, Jan 30, 2014 at 12:07 AM, Eric Anholt wrote:
>>
>> Stéphane Marchesin writes:
>>
>> > On systems without libudev, the loader_get_pci_id_for_fd() call will
>> > return 0, which will trigger the drmGetVersion logic. Sadly,
I forgot to mention an extension spec bug. The spec mentions
glMemoryBarrier, but doesn't define it anywhere, nor does the spec
define dependencies on other extensions or GL versions.
glMemoryBarrier is required for non-coherent buffer mappings to be
usable. Without it, you have to always use coher
https://bugs.freedesktop.org/show_bug.cgi?id=74085
--- Comment #3 from Steffen ---
can confirm. I've a AMD Radeon HD5870 and I'm on Ubuntu 13.10 with GLX Version:
3.0 Mesa 10.1.0-devel (git-a487b4d saucy-oibaf-ppa+curaga)
--
You are receiving this mail because:
You are the assignee for the bug.
On Thursday 30 January 2014, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mesa/main/bufferobj.c | 5 -
> src/mesa/main/dd.h| 3 ---
> 2 files changed, 8 deletions(-)
>
> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
> index e305038..802c9e3 100644
> ---
Is it for all patches or just this patch?
Marek
On Thu, Jan 30, 2014 at 7:21 PM, Fredrik Höglund wrote:
> On Thursday 30 January 2014, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> ---
>> src/mesa/main/bufferobj.c | 5 -
>> src/mesa/main/dd.h| 3 ---
>> 2 files changed, 8 deletions
On Thursday 30 January 2014, Marek Olšák wrote:
> From: Marek Olšák
>
> It will be used by glBufferStorage. The parameters are chosen according
> to ARB_buffer_storage.
> ---
> src/mesa/drivers/dri/i915/intel_buffer_objects.c| 5 -
> src/mesa/drivers/dri/i965/intel_buffer_objects.c|
On Thursday 30 January 2014, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mapi/glapi/gen/gl_API.xml | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> index 193ee37..4a70542 100644
> --- a/src/map
On Thursday 30 January 2014, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mesa/main/bufferobj.c | 98
> ++
> src/mesa/main/bufferobj.h | 4 ++
> src/mesa/main/extensions.c | 1 +
> src/mesa/main/mtypes.h | 2 +
> 4 files changed, 105
The loader infrastructure for everything but DRI2 requires that udev be
present, so we can figure out an appropriate driver from the fd. We don't
have a portable solution yet, but presumably it will similar lookup based
on the device node.
It will also be even more required for krh's udev-based h
---
src/loader/loader.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/loader/loader.c b/src/loader/loader.c
index 5d25899..811f8a2 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -111,6 +111,11 @@ udev_dlopen_handle(void)
* might be ia64.
*/
As far as I know, this should be safe. If not, we have to decide whether
to have variable lookup of the functions, or just drop support for .so.0
(which is a year and a half old it looks like)
---
src/loader/loader.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/loader/loade
On Thursday 30 January 2014, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mesa/main/bufferobj.c | 46 +++---
> 1 file changed, 39 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
> index 55184f1.
Hi,
are these patches the last thing necessary to get CL programs running
without needing X permission?
I tried to test them, but got:
pci id for fd 3: 1002:675d, driver r600
pci id for fd 3: 1002:675d, driver r600
radeon: Failed to get PCI ID, error number -13
which is kind of funny combination
On Thu, Jan 30, 2014 at 01:55:40PM -0500, Jan Vesely wrote:
> Hi,
>
> are these patches the last thing necessary to get CL programs running
> without needing X permission?
You also need a 3.12 or newer kernel and you must enable render nodes
ether by adding drm.rnodes=1 to you kernel command lin
s/mised/missed/ in the commit summary
Series is
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 27/01/14 16:13, Tom Stellard wrote:
> From: Tom Stellard
>
> v2:
>- Add missing call to pipe_loader_drm_release()
>- Fix render node macros
>- Drop render-node configure option
> ---
>
> For reference, version 1 of this patch:
> http://lists.freedesktop.org/archives/mesa-dev/2013-
Matt Turner writes:
> + if (parser->version_resolved) {
> + glcpp_error(& @1, parser, "#version after
> version is resolved");
The phrasing "after version is resolved" makes a lot of sense from the
point-of-view of the implementation, but it's not ideal for guiding
On Thursday 30 January 2014, Chris Forbes wrote:
> Marek,
>
> I think there's an interaction with software primitive restart here.
>
> The primitive restart path maps the index buffer (and the indirect
> buffer, for indirect draws), and relies on these checks to guarantee
> that's possible.
>
>
On Thursday 30 January 2014, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mesa/state_tracker/st_cb_bufferobjects.c | 81
> +++
> src/mesa/state_tracker/st_cb_texturebarrier.c | 17 ++
> src/mesa/state_tracker/st_extensions.c| 1 +
> 3 files changed,
On Thursday 30 January 2014, Marek Olšák wrote:
> From: Marek Olšák
>
> All GTT memory mappings are coherent and therefore can be persistent.
As we discussed on IRC, I think there should be a comment somewhere
explaining that VRAM mappings are uncached, so the memory_barrier
implementations don'
On Thursday 30 January 2014, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=74251
Priority: medium
Bug ID: 74251
Assignee: mesa-dev@lists.freedesktop.org
Summary: Segfault in st_finalize_texture with Texture Buffer
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=74251
--- Comment #1 from Ian Milligan ---
I forgot to add that I am using the r600g driver.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@list
https://bugs.freedesktop.org/show_bug.cgi?id=74251
--- Comment #2 from Marek Olšák ---
Could you please attach the backtrace?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedeskto
https://bugs.freedesktop.org/show_bug.cgi?id=74251
--- Comment #3 from Ian Milligan ---
Oops, I meant mesa 10.0 of course. Here is the backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x726296f4 in st_finalize_texture (ctx=0x71324010, pipe=0xf1b2e0,
tObj=0xf25d70) at st
Thanks. I updated the patch here:
http://cgit.freedesktop.org/~mareko/mesa/log/?h=buffer-storage
Marek
On Thu, Jan 30, 2014 at 7:26 PM, Fredrik Höglund wrote:
> On Thursday 30 January 2014, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> It will be used by glBufferStorage. The parameters are cho
On Thursday 30 January 2014, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/auxiliary/util/u_upload_mgr.c | 65
> ---
> 1 file changed, 51 insertions(+), 14 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_upload_mgr.c
> b/src/gallium/auxili
On Thursday 30 January 2014, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/auxiliary/util/u_upload_mgr.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_upload_mgr.c
> b/src/gallium/auxiliary/util/u_upload_mgr.c
>
On Thursday 30 January 2014, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> docs/GL3.txt| 2 +-
> docs/relnotes/10.1.html | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index 6d6fe71..04edcef 100644
> --- a/docs/GL3.txt
> ++
I guess softpipe should be fine. I'm not sure about llvmpipe and its
parallelism.
Marek
On Thu, Jan 30, 2014 at 11:55 PM, Fredrik Höglund wrote:
> On Thursday 30 January 2014, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> ---
>> src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
>> src/ga
https://bugs.freedesktop.org/show_bug.cgi?id=74251
--- Comment #4 from Marek Olšák ---
Do you have a code sample how to reproduce this?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.
https://bugs.freedesktop.org/show_bug.cgi?id=74251
--- Comment #5 from Ian Milligan ---
I do but it's not written in C. Let me try to write something which can
reproduce this.
--
You are receiving this mail because:
You are the assignee for the bug.
_
Pushed, thanks.
Marek
On Sun, Jan 26, 2014 at 7:43 PM, Mark Mueller wrote:
> Signed-off-by: Mark Mueller
> ---
> src/mesa/main/format_pack.c | 7 ++-
> src/mesa/main/format_unpack.c | 12
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/form
On Friday 31 January 2014, Marek Olšák wrote:
> Thanks. I updated the patch here:
>
> http://cgit.freedesktop.org/~mareko/mesa/log/?h=buffer-storage
>
> Marek
Looks good to me.
Reviewed-by: Fredrik Höglund
___
mesa-dev mailing list
mesa-dev@lists.fr
Kenneth Graunke writes:
> The "pointer" value is relative to the base address, so if we change the
> base address, we'd better re-emit this.
I see about 50 callers of brw_state_batch, but only about 8 that flag
BRW_NEW_STATE_BASE_ADDRESS (some of which, iirc, are "things that must
be reemitted i
On Thursday 30 January 2014, Marek Olšák wrote:
> Is it for all patches or just this patch?
Probably obvious by now, but just this patch :)
I reviewed most of them though.
Fredrik
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.f
You are right. We need to support at least 2 buffer mappings: one for
the user and the other one for internal purposes.
Marek
On Thu, Jan 30, 2014 at 11:33 PM, Fredrik Höglund wrote:
> On Thursday 30 January 2014, Chris Forbes wrote:
>> Marek,
>>
>> I think there's an interaction with software p
On Thu, 2014-01-30 at 15:52 -0500, Tom Stellard wrote:
> On Thu, Jan 30, 2014 at 01:55:40PM -0500, Jan Vesely wrote:
> > Hi,
> >
> > are these patches the last thing necessary to get CL programs running
> > without needing X permission?
>
> You also need a 3.12 or newer kernel and you must enabl
On Don, 2014-01-30 at 23:46 +0100, Fredrik Höglund wrote:
> On Thursday 30 January 2014, Marek Olšák wrote:
> > From: Marek Olšák
> >
> > All GTT memory mappings are coherent and therefore can be persistent.
>
> As we discussed on IRC, I think there should be a comment somewhere
> explaining tha
https://bugs.freedesktop.org/show_bug.cgi?id=74251
--- Comment #6 from Ian Milligan ---
Created attachment 93095
--> https://bugs.freedesktop.org/attachment.cgi?id=93095&action=edit
Vertex shader using texture buffer.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=74251
--- Comment #7 from Ian Milligan ---
Created attachment 93096
--> https://bugs.freedesktop.org/attachment.cgi?id=93096&action=edit
Failing code.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=74251
--- Comment #8 from Ian Milligan ---
The segfault appears to occur when glClear is called while a vertex shader
expecting a texture buffer is loaded, but no texture is bound. This can be
reproduced simply by loading the attached vertex shader and
On Thu, Jan 30, 2014 at 10:42 AM, Dave Airlie wrote:
> From: Vadim Girlin
>
> Signed-off-by: Vadim Girlin
> Signed-off-by: Dave Airlie
This commit has a missing line in the r600 case that causes a
regression, I'll fix it up.
Dave.
___
mesa-dev maili
On Don, 2014-01-30 at 16:10 +0100, Axel Davy wrote:
> dri2_dup_image was not copying the dri_format field.
>
> This was causing some bugs, for example:
> . we create an gbm_bo.
> . we get an EGLImage from the gbm_bo.
> . Bug: impossible to get again the gbm_bo from the EGLImage by importing.
> (g
From: Vadim Girlin
v2: fix regression on r600 NOP instructions.
Signed-off-by: Vadim Girlin
Signed-off-by: Dave Airlie
Fix regression since eop moving
---
src/gallium/drivers/r600/eg_asm.c | 10 ++
src/gallium/drivers/r600/r600_asm.c| 24 +---
src/gallium
From: Dave Airlie
This is my first attempt at enabling r600/r700 geometry shaders,
the basic tests pass on both my rv770 and my rv635,
It requires this kernel patch:
http://www.spinics.net/lists/dri-devel/msg52745.html
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_asm.c
I've lightly tested this, not piglit strength yet,
and it does require the kernel patch to work.
its also available in a branch in my repo r600-geom-shaders.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/ma
softpipe has tile caches though (for textures and render targets). I'm
not sure if they'd be flushed whenever needed or if that would even be a
problem.
As for llvmpipe, there's no caches there, I'm not sure if there could be
other problems.
Roland
Am 31.01.2014 00:44, schrieb Marek Olšák:
> I gu
From: Michel Dänzer
Fixes piglit glx/GLX_ARB_create_context/current with no framebuffer.
Signed-off-by: Michel Dänzer
---
src/gallium/state_trackers/dri/common/dri_context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/dri/common/dri_contex
From: Dave Airlie
cayman has a different end of program bit, so do that properly.
fixes hangs with geom shader tests on cayman.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers
74 matches
Mail list logo
