On Sun, Jan 20, 2013 at 2:39 PM, Sedat Dilek wrote:
> On Sun, Jan 20, 2013 at 2:30 PM, Sedat Dilek wrote:
>> Hi,
>>
>> I am here on Ubuntu/precise AMD64.
>>
>> With the attached scripts I can't use a i965_dri.so for example from
>> gles3 GIT tree.
>>
>> First, I have built libdrm-2.4.41, installe
On Sun, Jan 20, 2013 at 2:30 PM, Sedat Dilek wrote:
> Hi,
>
> I am here on Ubuntu/precise AMD64.
>
> With the attached scripts I can't use a i965_dri.so for example from
> gles3 GIT tree.
>
> First, I have built libdrm-2.4.41, installed and ldconfig-ed it before
> building mesa.
>
> I have chosen
Hi,
I am here on Ubuntu/precise AMD64.
With the attached scripts I can't use a i965_dri.so for example from
gles3 GIT tree.
First, I have built libdrm-2.4.41, installed and ldconfig-ed it before
building mesa.
I have chosen a classic XORG prefix!
[ /etc/ld.so.conf.d/xorg.conf ]
# Xorg lib con
https://bugs.freedesktop.org/show_bug.cgi?id=31598
--- Comment #2 from zephi...@gmail.com ---
On systems where 'python' is 3.x and 'python2' is 2.x, mesa's config will store
the variable PYTHON2='python2', whereas your code checks the PYTHON variable,
which is unset , and always uses 'python' (3.x
https://bugs.freedesktop.org/show_bug.cgi?id=59591
--- Comment #1 from Matt Turner ---
If make distclean ever worked, it was only by accident.
I'm working on a series that will fix make {dist,distclean,distcheck}.
--
You are receiving this mail because:
You are the assignee for the bug.
__
On 01/20/2013 05:49 PM, Ian Romanick wrote:
From: Ian Romanick
There really isn't any point. There is no resource savings, and we have
to do gymnastics in the driver to make it work.
There are also bad interactions with multisampling and OpenGL ES 3.0.
In ES3, a multisample-to-singlesample bl
From: Ian Romanick
There really isn't any point. There is no resource savings, and we have
to do gymnastics in the driver to make it work.
There are also bad interactions with multisampling and OpenGL ES 3.0.
In ES3, a multisample-to-singlesample blit must have identical source
and destination
Before, we were keeping a CPU-only buffer to accumulate the batchbuffer in,
which was an improvement over mapping the batch through the GTT directly
(since any readback or other failure to stream through write combining
correctly would hurt). However, on LLC-sharing architectures we can do better
On 01/18/2013 08:55 PM, Marek Olšák wrote:
---
src/mesa/state_tracker/st_cb_texture.c |1 +
src/mesa/state_tracker/st_extensions.c |1 +
src/mesa/state_tracker/st_format.c | 46
src/mesa/state_tracker/st_format.h |3 +++
4 files changed
On 20 January 2013 14:15, Paul Berry wrote:
> Your interaction with blorp looks good. But I think there are some bugs
> in the resolves. My rules of thumb for depth/HiZ resolves are:
>
> - Resolves take care of the mismatch in access patterns between HiZ-aware
> components (i.e. the depth buffe
On 19 January 2013 11:06, Kenneth Graunke wrote:
> The BLT engine has many limitations. Currently, it can only blit
> X-tiled buffers (since we don't have a kernel API to whack the BLT
> tiling mode register), which means all depth/stencil operations get
> punted to meta code, which can be very
https://bugs.freedesktop.org/show_bug.cgi?id=37637
--- Comment #12 from Tobias Jakobi ---
Last update for today. Current commandline is this:
g++ -fPIC -DPIC -shared -nostdlib
/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../lib/crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/crtbeginS.o .libs/targe
https://bugs.freedesktop.org/show_bug.cgi?id=37637
--- Comment #11 from Tobias Jakobi ---
Tried another approach:
llvm build normally and mesa with static llvm. I then replaced -lstdc++ by
-static-libstdc++ for building of r600g_dri.so (targets/dri-r600).
Doesn't work though:
ibGL error: dlopen
https://bugs.freedesktop.org/show_bug.cgi?id=59383
Andreas Boll changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=37637
--- Comment #10 from Tobias Jakobi ---
Created attachment 73329
--> https://bugs.freedesktop.org/attachment.cgi?id=73329&action=edit
two bts with recent mesa git master
Both crashes are due to dynamic_cast, but the calling chain is different.
https://bugs.freedesktop.org/show_bug.cgi?id=37637
--- Comment #9 from Tobias Jakobi ---
This still happens in mesa git master.
Im currently using the following setup:
(1) llvm is build with static libstdc++:
ldd doesn't show any ref to libstdc++ anymore, however nm confirm that libLLVM
is now e
https://bugs.freedesktop.org/show_bug.cgi?id=31598
Andreas Boll changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Reviewed-by: Andreas Boll
2013/1/19 Matt Turner :
> The static Makefiles used it.
> ---
> configure.ac |4
> src/gallium/targets/egl-static/Makefile.am |1 -
> 2 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
On Fre, 2013-01-18 at 21:17 +0100, Marek Olšák wrote:
> On Thu, Jan 17, 2013 at 7:34 PM, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > No piglit regressions anymore thanks to fixes in libdrm_radeon and here.
>
> FWIW, if there's an unreleased fix in libdrm_radeon, a new libdrm
> release s
On Fri, Jan 18, 2013 at 6:25 PM, Matt Turner wrote:
> On Thu, Jan 17, 2013 at 8:19 PM, Sedat Dilek wrote:
>> Hi,
>>
>> I am playing with llvm/clang v3.2 and mesa.
>>
>> It's annoying to see these hundreds of warnings...
>>
>> clang: warning: argument unused during compilation: '-fno-builtin-m
20 matches
Mail list logo
