This is based on opengles1/texture_from_pixmap.c
---
src/egl/opengles2/Makefile.am |4 +-
src/egl/opengles2/texture_from_pixmap.c | 653 +++
2 files changed, 656 insertions(+), 1 deletions(-)
create mode 100644 src/egl/opengles2/texture_from_pixmap.c
di
on gen6+, render engine PIPE_CONTROL reported time stamp is a 64 bits
value (high 32 bits MBZ on snb), toggles every 80 ns.
Signed-off-by: Zou Nan hai
---
src/mesa/drivers/dri/i965/brw_queryobj.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/sr
https://bugs.freedesktop.org/show_bug.cgi?id=36384
Fabio Pedretti changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=38716
--- Comment #13 from Chia-I Wu 2011-07-19 02:27:58 PDT ---
(In reply to comment #12)
> (In reply to comment #1)
> > The command for linking wrongly put the local library search path after the
> > system's. It should be fixed with 24137af. Pleas
https://bugs.freedesktop.org/show_bug.cgi?id=39219
Henri Verbeet changed:
What|Removed |Added
Attachment #49135|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=39219
--- Comment #6 from freewindri...@rocketmail.com 2011-07-19 04:55:29 PDT ---
new patch works on i686 Arch Linux (2.6.39.3)
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: --
LLVM 3.0svn introduced a new type system. It defines a new way to create
named structs and removes the (now not needed) LLVMInvalidateStructLayout
function.
see revision 134829 of LLVM
Only compile tested, please review and test!
Signed-off-by: Tobias Droste
---
src/gallium/auxiliary/draw/draw
Am Montag, den 18.07.2011, 00:55 -0700 schrieb Chad Versace:
> Until now, the stencil buffer was allocated as a Y tiled buffer, because
> in several locations the PRM states that it is. However, it is actually
> W tiled. From the PRM, 2011 Sandy Bridge, Volume 1, Part 2, Section
> 4.5.2.1 W-Major F
Am Montag, den 18.07.2011, 00:55 -0700 schrieb Chad Versace:
[…]
> diff --git a/src/mesa/drivers/dri/intel/intel_span.c
> b/src/mesa/drivers/dri/intel/intel_span.c
> index 153803f..d306432 100644
> --- a/src/mesa/drivers/dri/intel/intel_span.c
> +++ b/src/mesa/drivers/dri/intel/intel_span.c
> @@
Hi folks.
I wonder if there is someone here who can help me wrap my brain around
the code flow for getting Mesa to render with Gallium.
I have an embedded system with a GPU supported by a gallium driver.
I'd like to have Mesa running with hardware acceleration (OSMesa with
software rendering alr
https://bugs.freedesktop.org/show_bug.cgi?id=38716
--- Comment #14 from Jos van Wolput 2011-07-19
06:22:10 PDT ---
(In reply to comment #13)
> libEGL.so is missing. Could you switch to src/egl/main/ and "make" from that
> directory?
>
Switching to .../mesa/src/egl/main, "make" now properly bu
On Tue, Jul 19, 2011 at 3:42 AM, Marcus Comstedt wrote:
>
> Hi folks.
>
> I wonder if there is someone here who can help me wrap my brain around
> the code flow for getting Mesa to render with Gallium.
>
> I have an embedded system with a GPU supported by a gallium driver.
> I'd like to have Mesa
On Tue, Jul 19, 2011 at 8:02 AM, Marcus Comstedt wrote:
>
> Hi Brian.
>
> Thanks for your reply.
>
>
> Brian Paul writes:
>
>> The app would call eglCreateContext() or glXCreateContext() or
>> similar.
>
> It certainly wouldn't call glXCreateContext(), because there is no X.
> I'm making my own W
On Sat, Jul 16, 2011 at 11:40 AM, Tobias Droste wrote:
> LLVM 3.0svn introduced a new type system. It defines a new way to create
> named structs and removes the (now not needed) LLVMInvalidateStructLayout
> function.
>
> see revision 134829 of LLVM
>
> Only compile tested, please review and test!
Hi Brian.
Thanks for your reply.
Brian Paul writes:
> The app would call eglCreateContext() or glXCreateContext() or
> similar.
It certainly wouldn't call glXCreateContext(), because there is no X.
I'm making my own Winsys, remember? :-)
I'm not sure what egl is or whether it would help in
Hi Brian.
Brian Paul writes:
> Above all this is the GL/window system API. Examples include GLX, WGL
> and EGL. These interface provide functions for creating rendering
> contexts, binding them to drawing surfaces, etc. If you're not
> familiar with these you should probably read up on EGL.
https://bugs.freedesktop.org/show_bug.cgi?id=39375
Summary: mesa-7.11_rc1 weird colors and aliasing
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: critical
Priority
https://bugs.freedesktop.org/show_bug.cgi?id=39375
Patrizio Bassi changed:
What|Removed |Added
Summary|mesa-7.11_rc1 weird colors |mesa-7.11_rc1 weird colors
https://bugs.freedesktop.org/show_bug.cgi?id=39375
Chi-Thanh Christopher Nguyen changed:
What|Removed |Added
Component|Mesa core |Drivers/DRI/nouveau
On Mon, Jul 18, 2011 at 8:05 AM, Brian Paul wrote:
> On 07/17/2011 03:50 PM, Marty Jack wrote:
>>
>> Another problem in the RC1 tarballs appears to be src/mesa/depend. This
>> contains a pile of references to
>> /usr/lib/gcc/x86_64-redhat-linux/4.6.0/include and will fail if you are not
>> on tha
---
Makefile | 24
1 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/Makefile b/Makefile
index abdeb79..864ee5f 100644
--- a/Makefile
+++ b/Makefile
@@ -253,7 +253,6 @@ MAIN_FILES = \
$(DIRECTORY)/src/mesa/descrip.mms \
Pekka Paalanen writes:
> On Mon, 18 Jul 2011 08:09:17 -0600
> Brian Paul wrote:
>
>> On 07/15/2011 02:59 PM, Pekka Paalanen wrote:
>> > On Fri, 15 Jul 2011 12:22:41 -0600
>> > Brian Paul wrote:
>> >
>> >> On 07/15/2011 10:07 AM, Dave Airlie wrote:
>> >>> On Fri, Jul 15, 2011 at 4:10 AM, Brian
>
On Mon, 18 Jul 2011 17:00:54 -0700, Chad Versace wrote:
> On 07/18/2011 08:57 AM, Eric Anholt wrote:
> > On Mon, 18 Jul 2011 00:55:03 -0700, Chad Versace
> > wrote:
> >> diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
> >> b/src/mesa/drivers/dri/intel/intel_fbo.c
> >> index 1669af2..507cc33
On Mon, 18 Jul 2011 12:47:26 -0600, Brian Paul wrote:
> On 07/18/2011 10:33 AM, Eric Anholt wrote:
> > This cuts out a large portion of the overhead of glClear() from
> > resetting the texenv state and recomputing the fixed function
> > programs. It also means less use of fixed function internall
On Tue, Jul 19, 2011 at 11:12 AM, Francisco Jerez wrote:
> (isn't fixing up the drivers the
> responsibility of whoever changes the API?)
That's exactly why removing old drivers is being discussed.
Matt
___
mesa-dev mailing list
mesa-dev@lists.freedesk
https://bugs.freedesktop.org/show_bug.cgi?id=39338
Johannes Obermayr changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Hi all,
This isn't quite the right place for this question, but I've searched
through old standards and googled without any luck, so hopefully
somebody here knows the history behind GLubyte*.
glGetString and gluErrorString, plus maybe some other functions, return
GLubyte pointers instead of simpl
On Tue, Jul 19, 2011 at 12:20:54PM -0600, tom fogal wrote:
| glGetString and gluErrorString, plus maybe some other functions, return
| GLubyte pointers instead of simply character pointers...
| What's the rationale here?
I agree, it's odd. I don't remember the rationale, but my best guess is
that
On Mon, Jul 18, 2011 at 07:31, Fredrik Höglund wrote:
> Commit 1a339b6c71ebab6e1a64f05b2e133022d3bbcd15 made
> st_ChooseTextureFormat map GL_RGBA with type GL_UNSIGNED_BYTE
> to PIPE_FORMAT_A8B8G8R8_UNORM.
>
> The image format for ARGB pixmaps is PIPE_FORMAT_B8G8R8A8_UNORM
> however. This mismatc
SGI invented OpenGL and offered it first on their IRIX platform. SGI's
MIPSpro compiler has the "char" datatype as unsigned by default, so the
compiler would likely complain if assigning a GLbyte pointer to an
[unsigned] character pointer. Thus, to do something like
char* ext = glGetString(GL_VEND
I think you have misinterpreted my question.
Why not just have glGetString's prototype be:
const char* glGetString(GLenum);
? Then (sans the missing const :), your code below would work on *all*
platforms, MIPSpro or not, with or without a cast.
-tom
Patrick Baggett writes:
> SGI invented O
On 19 July 2011 21:39, tom fogal wrote:
> I think you have misinterpreted my question.
>
> Why not just have glGetString's prototype be:
>
> const char* glGetString(GLenum);
>
> ? Then (sans the missing const :), your code below would work on *all*
> platforms, MIPSpro or not, with or without a c
On 07/18/2011 01:20 AM, Paul Menzel wrote:
> Am Montag, den 18.07.2011, 00:55 -0700 schrieb Chad Versace:
> There are alignment/white space issues above.
>
>> + unsigned stride = irb->region->pitch;\
>> + unsigned height = 2 * irb->region->height;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/08/2011 03:30 PM, Paul Berry wrote:
> This patch adds a new build artifact, glsl_test, which can be used for
> testing optimization passes in isolation.
>
> I'm hoping that we will be able to add other useful standalone tests
> to this executabl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 02:28 PM, Paul Berry wrote:
> On 18 July 2011 11:58, Brian Paul wrote:
>> On 07/18/2011 12:37 PM, Paul Berry wrote:
>>>
>>> Several headers redundantly define the INLINE macro. Adding this
>>> guard prevents the compiler from complainin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/19/2011 08:29 AM, Brian Paul wrote:
Won't this add an extra dependency (on makedepend) in the tarballs? I
thought that was the reason for including the empty depend files in the
first place. Right?
> ---
> Makefile | 24 ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 09:33 AM, Eric Anholt wrote:
> This cuts out a large portion of the overhead of glClear() from
> resetting the texenv state and recomputing the fixed function
> programs. It also means less use of fixed function internally in our
> GLES2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 09:33 AM, Eric Anholt wrote:
> Improves glxgears performance 19.6% +/- 7.3% (second fps printout.
> n=5).
glxgearsisnotabenchmark. Is there *any* other number that could be
quoted here? This *will* bite you later. :)
> ---
> src/mesa
On 07/19/2011 02:40 PM, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/19/2011 08:29 AM, Brian Paul wrote:
Won't this add an extra dependency (on makedepend) in the tarballs? I
thought that was the reason for including the empty depend files in the
first place. Right?
https://bugs.freedesktop.org/show_bug.cgi?id=39219
--- Comment #7 from Padfoot 2011-07-19 14:55:50 PDT ---
Compiling with modified patch.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the
On 07/19/2011 01:46 PM, Ian Romanick wrote:
> On 07/18/2011 09:33 AM, Eric Anholt wrote:
>> This cuts out a large portion of the overhead of glClear() from
>> resetting the texenv state and recomputing the fixed function
>> programs. It also means less use of fixed function internally in our
>> GL
There's scary stuff going on in PIPE_CONTROL internals, and if the
BSpec says to do this to make PIPE_CONTROL work, I'll go ahead and do
it because we'll probably never be able to debug it after the fact.
---
src/mesa/drivers/dri/intel/intel_batchbuffer.c | 32 +--
1 files ch
The behavior of flushes in the hardware is a maze of twisty passages,
and strangely the VS constants appear to be loaded during a pipeline
flush instead of at the time of the packet emit according to the
simulator. On moving the STATE_BASE_ADDRESS packet to where it really
needed to live (in order
For this and occlusion queries, we're trying to avoid setting
I915_GEM_DOMAIN_RENDER for the write domain, because the data written
is definitely not going through the render cache, but we do need to
tell the kernel that the object has been written. However, with using
I915_GEM_DOMAIN_GTT, the ker
https://bugs.freedesktop.org/show_bug.cgi?id=39219
--- Comment #8 from Padfoot 2011-07-19 15:53:15 PDT ---
Confirmed.
Modified patch works on x86 & x86_64 Arch 2.6.39.3
Thankyou so much for your speedy resolution.
Cheers.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=e
On 19 July 2011 13:15, Ian Romanick wrote:
> We'll probably have to tweak the build a bit to be sure everything ends
> up in the tarballs. Since José's changes recently this may not be as
> much of a problem, but we'll at least want to test it. We can do that
> on Wednesday.
Ok, cool. Are the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mesa 7.11-rc2 has been released. This is a release candidate for the
7.11 development release.
The tag in the GIT repository for Mesa 7.11-rc2 is 'mesa-7.11-rc2'.
Mesa 7.11-rc2 is available for download at
ftp://freedesktop.org/pub/mesa/7.11/
md5su
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/19/2011 02:09 PM, Brian Paul wrote:
> On 07/19/2011 02:40 PM, Ian Romanick wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 07/19/2011 08:29 AM, Brian Paul wrote:
>>
>> Won't this add an extra dependency (on makedepend) in the
On 19 July 2011 13:15, Ian Romanick wrote:
>> src/egl/main/eglcompiler.h
>> src/gallium/include/pipe/p_compiler.h
>> src/mapi/mapi/u_compiler.h
>> src/mesa/main/compiler.h
>
> None of those headers should ever cross paths. The only one of those
> that anything under src/mesa/main or src/glsl shou
On Tue, 19 Jul 2011 15:44:11 -0700, Eric Anholt wrote:
> There's scary stuff going on in PIPE_CONTROL internals, and if the
> BSpec says to do this to make PIPE_CONTROL work, I'll go ahead and do
> it because we'll probably never be able to debug it after the fact.
For this and the following patc
On Tue, 19 Jul 2011 15:44:12 -0700, Eric Anholt wrote:
> The behavior of flushes in the hardware is a maze of twisty passages,
> and strangely the VS constants appear to be loaded during a pipeline
> flush instead of at the time of the packet emit according to the
> simulator. On moving the STATE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 06:11 PM, Marek Olšák wrote:
> ES 2.0.25 page 127 says:
>
> If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, then
> querying any other pname will generate INVALID_ENUM.
Hurray for be different just for the sake of being d
Hello list
Mesa 7.11-rc2 has been released. This is a release candidate for the
7.11 development release.
I've tried to compile this one
996aea3cca40bb34c0a9027411924879 MesaGLUT-7.11-rc2.tar.bz2
After unpacking
./configure --prefix=/opt/mesa PKG_CONFIG_PATH=/opt/mesa/lib/pkgconfig
LC_A
On 07/19/2011 03:44 PM, Eric Anholt wrote:
> There's scary stuff going on in PIPE_CONTROL internals, and if the
> BSpec says to do this to make PIPE_CONTROL work, I'll go ahead and do
> it because we'll probably never be able to debug it after the fact.
> ---
> src/mesa/drivers/dri/intel/intel_bat
On 07/19/2011 03:44 PM, Eric Anholt wrote:
> For this and occlusion queries, we're trying to avoid setting
> I915_GEM_DOMAIN_RENDER for the write domain, because the data written
> is definitely not going through the render cache, but we do need to
> tell the kernel that the object has been written
When new releaseTexBuffer function got added, the __DRI_TEX_BUFFER_VERSION
didn't update as well, which just not enable new function at all.
This bumps version to 3.
---
include/GL/internal/dri_interface.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/GL/interna
：）
Glad to see that you open this functionality.
With this, you not only need to update this macro, but also need to add the
NULL point for releaseTexBuffer to related driver.
You can update your patch refer to "
http://build.meego.com/package/view_file?file=update-__DRI_TEX_BUFFER_VERSION-to-3.p
On 2011.07.20 14:18:53 +0800, Zhao, Juan J wrote:
> ：）
> Glad to see that you open this functionality.
> With this, you not only need to update this macro, but also need to add the
> NULL point for releaseTexBuffer to related driver.
> You can update your patch refer to "
> http://build.meego.com
58 matches
Mail list logo
