Brian Paul bri...@vmware.com writes:
Of course, we _could_ do the comparison with ints but we'd have to
query the number of framebuffer alpha bits, convert the floats to ints
with the right number of bits, then compare (to match the
hardware). It seems to be a lot of extra work for no good
On 11/09/2010 09:03 PM, firos ismail wrote:
Hi all,
When comparing the buffers created by X11 and OSMesa i found
that the functions that put values to the buffers are different and
their logic is different both take different origins to put values. Is
this normal or is there any
On 11/10/2010 05:41 AM, Francisco Jerez wrote:
Brian Paulbri...@vmware.com writes:
Of course, we _could_ do the comparison with ints but we'd have to
query the number of framebuffer alpha bits, convert the floats to ints
with the right number of bits, then compare (to match the
hardware). It
On Wed, Nov 10, 2010 at 2:36 AM, Russell Shaw rjs...@netspace.net.au wrote:
Hi,
I compiled mesa from sources.
In mesa/src/driclient/src/XF86dri.c, if i use the
api to make a drawable, how can i find the buffer
pixel format?
See my other reply on the wayland mailing list but i think you are
On 11/11/10 01:36, Jerome Glisse wrote:
On Wed, Nov 10, 2010 at 2:36 AM, Russell Shawrjs...@netspace.net.au wrote:
Hi,
I compiled mesa from sources.
In mesa/src/driclient/src/XF86dri.c, if i use the
api to make a drawable, how can i find the buffer
pixel format?
See my other reply on the
Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
Looking (for the first time) at iso13818-2 I think the chroma handling
would be part of display rather than decode, though the iso does specify
how chroma is laid out for fields in 6.1.1.8.
An article that describes the issues
https://bugs.freedesktop.org/show_bug.cgi?id=31514
--- Comment #3 from Brian Paul bri...@vmware.com 2010-11-10 07:33:38 PST ---
I just ran a test with NVIDIA's driver (version 256.35) and it returns GL_TRUE
like Mesa does. I wonder what AMD's driver does?
This is one of those corner cases where
Mesa 7.9 from ftp , demos 8.0.1 from ftp
when there is no gallium egl driver , without setting EGL_DRIVER=egl_dri2:
egl/opengl/xeglgears :
./xeglgears
libEGL debug: added /usr/lib/egl/egl_dri2.so to module array
libEGL debug: added /usr/lib/egl/egl_glx.so to module array
libEGL debug: added
Brian Paul bri...@vmware.com writes:
On 11/10/2010 05:41 AM, Francisco Jerez wrote:
Brian Paulbri...@vmware.com writes:
Of course, we _could_ do the comparison with ints but we'd have to
query the number of framebuffer alpha bits, convert the floats to ints
with the right number of bits,
https://bugs.freedesktop.org/show_bug.cgi?id=31514
--- Comment #4 from Brian Paul bri...@vmware.com 2010-11-10 07:47:20 PST ---
BTW, I just added a new piglit test (isbufferobj) for this bug/issue.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
On 11/10/2010 08:44 AM, Francisco Jerez wrote:
Brian Paulbri...@vmware.com writes:
On 11/10/2010 05:41 AM, Francisco Jerez wrote:
Brian Paulbri...@vmware.com writes:
Of course, we _could_ do the comparison with ints but we'd have to
query the number of framebuffer alpha bits, convert the
On 10.11.2010 15:56, Christian König wrote:
Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
Looking (for the first time) at iso13818-2 I think the chroma handling
would be part of display rather than decode, though the iso does specify
how chroma is laid out for fields in
On Wed, Nov 10, 2010 at 11:40 PM, Clurado cl clurado1...@gmail.com wrote:
Mesa 7.9 from ftp , demos 8.0.1 from ftp
when there is no gallium egl driver , without setting EGL_DRIVER=egl_dri2:
egl/opengl/xeglgears :
./xeglgears
libEGL debug: added /usr/lib/egl/egl_dri2.so to module array
On Wed, 10 Nov 2010 08:25:19 +0800, Xiang, Haihao haihao.xi...@intel.com
wrote:
Any comment? If no problem, I will check in this fix.
This should really be part of the core -- all drivers have to flush when
changing current context.
pgp8Q4yysAmQ6.pgp
Description: PGP signature
On Wed, Nov 10, 2010 at 12:28 PM, Eric Anholt e...@anholt.net wrote:
On Wed, 10 Nov 2010 08:25:19 +0800, Xiang, Haihao haihao.xi...@intel.com
wrote:
Any comment? If no problem, I will check in this fix.
This should really be part of the core -- all drivers have to flush when
changing
ok , when i replaced my own build i915_dri.so with the orginal dri driver
xeglgears works with hw acceleration. ( i used original because with some
configs x console reports unknown pci id and clients say could not get
dobule buffered RGB ... )
but opengles1 demos still not working.
libEGL
32bit and 64bit) build perfectly. I've made a package of
32bit and 64bit MSVC binaries and uploaded to
http://people.freedesktop.org/~jrfonseca/mesademos/mesademos-20101110-windows.7z
I'd like to merge the branch and remove SCons.
On MSVC CMake generates a Visual studio project, so we could remove
On Thu, Nov 11, 2010 at 3:08 AM, Clurado cl clurado1...@gmail.com wrote:
ok , when i replaced my own build i915_dri.so with the orginal dri driver
xeglgears works with hw acceleration. ( i used original because with some
configs x console reports unknown pci id and clients say could not
Am Mittwoch, den 10.11.2010, 17:24 +0100 schrieb Roland Scheidegger:
On 10.11.2010 15:56, Christian König wrote:
Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
Looking (for the first time) at iso13818-2 I think the chroma handling
would be part of display rather than decode,
.
This is now done in the mesa/demos' cmake branch. Linux, cross MinGW,
and MSVC (both 32bit and 64bit) build perfectly. I've made a package of
32bit and 64bit MSVC binaries and uploaded to
http://people.freedesktop.org/~jrfonseca/mesademos/mesademos-20101110-windows.7z
I'd like to merge the branch
On Wed, Nov 10, 2010 at 3:56 PM, Christian König deathsim...@vodafone.dewrote:
Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
Looking (for the first time) at iso13818-2 I think the chroma handling
would be part of display rather than decode, though the iso does specify
how
Required because ATI and NVIDIA DX9 GPUs do not support indirect addressing
of temps, inputs, outputs, and consts (FS-only) or the hw support is so
limited that we cannot use it.
This should make r300g and possibly nvfx more feature complete.
Signed-off-by: Marek Olšák mar...@gmail.com
---
On Wed, Nov 10, 2010 at 9:56 AM, Christian König
deathsim...@vodafone.de wrote:
I also started to profile the performance of the code a bit, as expected
we spend far to much time deciding of how and where to draw something
compared to really drawing something. Up to 50% of the whole cpu time is
On 10.11.2010 20:31, Christian König wrote:
Am Mittwoch, den 10.11.2010, 17:24 +0100 schrieb Roland Scheidegger:
On 10.11.2010 15:56, Christian König wrote:
Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
Looking (for the first time) at iso13818-2 I think the chroma handling
On Wed, 2010-11-10 at 12:29 -0800, Marek Olšák wrote:
Required because ATI and NVIDIA DX9 GPUs do not support indirect addressing
of temps, inputs, outputs, and consts (FS-only) or the hw support is so
limited that we cannot use it.
This should make r300g and possibly nvfx more feature
On 11/10/2010 12:31 PM, Christian König wrote:
Am Mittwoch, den 10.11.2010, 17:24 +0100 schrieb Roland Scheidegger:
On 10.11.2010 15:56, Christian König wrote:
Am Montag, den 08.11.2010, 23:08 + schrieb Andy Furniss:
Looking (for the first time) at iso13818-2 I think the chroma handling
Hi
This patch was cummited on the old ml at sourceforge.net mesa3d-dev
and singned-off-by Dan Nicholson dbn.li...@gmail.com
http://marc.info/?l=mesa3d-devm=125970571528105w=2
but it still not cummited to the code.
/Magnus
---
--- configure.ac.orig 2008-11-17 23:19:38.0 +0100
+++
On Wed, Nov 10, 2010 at 9:48 PM, José Fonseca jfons...@vmware.com wrote:
On Wed, 2010-11-10 at 12:29 -0800, Marek Olšák wrote:
Required because ATI and NVIDIA DX9 GPUs do not support indirect
addressing
of temps, inputs, outputs, and consts (FS-only) or the hw support is so
limited that
On Wed, 20 Oct 2010 18:01:10 -0400, Robert Hooker sarv...@ubuntu.com wrote:
From: Robert Hooker robert.hoo...@canonical.com
Signed-off-by: Robert Hooker robert.hoo...@canonical.com
Finally pushed this. Sorry for the delay.
pgpB4JqYgtcJr.pgp
Description: PGP signature
On Wed, 2010-11-10 at 13:24 -0800, Marek Olšák wrote:
On Wed, Nov 10, 2010 at 9:48 PM, José Fonseca
jfons...@vmware.commailto:jfons...@vmware.com wrote:
On Wed, 2010-11-10 at 12:29 -0800, Marek Olšák wrote:
Required because ATI and NVIDIA DX9 GPUs do not support indirect addressing
of
Am Mittwoch, den 10.11.2010, 15:30 -0500 schrieb Younes Manton:
Keep in mind that the XvMC interface makes no guarantees about the
order in which macroblocks are submitted. Also, we're already sorting
macroblocks by I/P/B type in order to batch draw calls. Otherwise it
would be possible to
Am Mittwoch, den 10.11.2010, 14:11 -0700 schrieb Brian Paul:
Here's an idea. I may be totally off base (this is off the top of my
head) but suppose the interlaced texture is:
A B C D (even line)
e f g h (odd line)
I J K L (even line)
m n o p (odd line)
Couldn't you lie to the
Hi all
We have a bunch of redundant target helpers to wrap screens with debug drivers
and for creating the various software drivers. This series removes all but the
inline one, I picked it since it gives more flexibility for targets and maybe
more importantly is the one that is used in 20
https://bugs.freedesktop.org/show_bug.cgi?id=30192
Andy Furniss li...@andyfurniss.entadsl.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Bug 29044 depends on bug 30192, which changed state.
Bug 30192 Summary: Doom3-demo segfaults since glsl2 branch merged.
https://bugs.freedesktop.org/show_bug.cgi?id=30192
What|Old Value |New Value
On Thu, 2010-11-11 at 01:47 +0800, Jerome Glisse wrote:
On Wed, Nov 10, 2010 at 12:28 PM, Eric Anholt e...@anholt.net wrote:
On Wed, 10 Nov 2010 08:25:19 +0800, Xiang, Haihao
haihao.xi...@intel.com wrote:
Any comment? If no problem, I will check in this fix.
This should really be part
On Wed, Nov 10, 2010 at 7:40 PM, Brian Paul bri...@vmware.com wrote:
On 11/09/2010 09:03 PM, firos ismail wrote:
Hi all,
When comparing the buffers created by X11 and OSMesa i found
that the functions that put values to the buffers are different and
their logic is different both
https://bugs.freedesktop.org/show_bug.cgi?id=31544
Summary: bad format in _mesa_format_to_type_and_comps
Product: Mesa
Version: 7.9
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
38 matches
Mail list logo
