Re: [Mesa3d-dev] [PATCH] util: fix swizzles in the format table for 8-bits-per-channel formats
On Sun, 2010-02-21 at 06:40 -0800, Marek Olšák wrote: Hi José, the attached patch fixes incorrect swizzles in u_format.csv. There are basically just 2 drivers which depend on the swizzles in this table: llvmpipe and r300g. Since r300g started supporting pretty much every texture format except SCALED ones, a few regressions have showed up. This patch resolves all issues I had, especially with the SRGB formats but I decided to clean it up all. git log: util: fix swizzles in the format table for 8-bits-per-channel formats The 8-bits-per-channel formats having the same channel order had completely different swizzles, and at the same time, the same swizzles were used for completely different channel orders of 8bpc formats. This made the whole table self-contradicting, caused headaches, and last but not least, incorrent rendering for the drivers relying on these swizzles. I hope I got it right. I didn't make a special distinction between the array and arith layouts. All I did was to make sure that if I grep e.g. A8R8G8B8, I'll get the same swizzles and not entirely different ones. Hi Marek, I'll need a bit more time to investigate this. One problem is that the interpretation of the swizzle varies with array vs arith. The ordering for array is the lowest significant word to the highest significant word (where word for 8bit formats is a byte), where for arith it goes from least significant bit to the highest significant bit. This is the same difference as array indexation and bit shifts. There is also the problem of byte order which affects the bit shift interpretation... I admit thet the current format description table is terribly underdocumented/confusing and likely broken in several ways. I wrote it to be able to code generate pixel format translation (which is wroking reasonably) and never expected people to use it for hardware drivers as well, although it is perfectly legitimate use. I have my own interpretation of these concepts, you and others hw driver writers have their own different interpretation. Furthermore in draw/translate/util modules there are some inconsistencies in these interpretations too. So I need to read the GL and DX10 specs very well, see how current drivers are using the descriptions, and come up with something that makes sense for everybody. So please hold on to your patch for a couple of days. I'd appreciate if the interested parties could take a good look to u_format.h comments, and summarize what they think the format semantics should be. Jose -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): Revert r300g: rebuild winsys/ pipe buffer handling and add buffer map
The pipebuffer library works well with purely user space suballocation of a big pinned buffer, but there are some further tweaks necessary in order to use it with kernel TTM-like memory managers. For example, one problem with pb_bufmgr_cache is that it doesn't try to check if a buffer is busy (e.g., by trying to map with PIPE_BUFFER_USAGE_DONTBLOCK) before reusing it. This worked fine so far because fencing was implemented on top of buffer suballocation and caching (ie., by the time a freed buffer was put in the cache list it was already guaranteed to have no pending fences). But this is not true if caching is used by itself on top of a kernel memory manager. Thomas also noticed the way validation lists works also needs some tweaks in order to work correctly. I don't think there's anything fundamentally broken in pipebuffer lib, just that we never had the need to make fix it so far. Jose On Sun, 2010-02-21 at 23:29 -0800, Dave Airlie wrote: Module: Mesa Branch: master Commit: b14548ea32000459f4f0c4b49f3fa11d1ee9c003 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=b14548ea32000459f4f0c4b49f3fa11d1ee9c003 Author: Dave Airlie airl...@redhat.com Date: Mon Feb 22 17:26:30 2010 +1000 Revert r300g: rebuild winsys/pipe buffer handling and add buffer map This reverts commit fff5be8e7b4557c221f2425dcafc2e7cbbba76ba. Probably went too soon with this, dileX reported OA not working for him it works here fine, but the optimisations I wanted aren't working properly yet so I'll fix that now. Signed-off-by: Dave Airlie airl...@redhat.com --- src/gallium/drivers/r300/Makefile |1 - src/gallium/drivers/r300/r300_context.c| 38 +-- src/gallium/drivers/r300/r300_context.h|9 +- src/gallium/drivers/r300/r300_cs.h | 22 +- src/gallium/drivers/r300/r300_emit.c | 54 ++-- src/gallium/drivers/r300/r300_render.c | 33 +-- src/gallium/drivers/r300/r300_screen.c | 38 +-- src/gallium/drivers/r300/r300_screen.h |2 +- src/gallium/drivers/r300/r300_screen_buffer.c | 222 src/gallium/drivers/r300/r300_screen_buffer.h | 85 - src/gallium/drivers/r300/r300_state.c | 25 +-- src/gallium/drivers/r300/r300_texture.c| 41 +-- src/gallium/drivers/r300/r300_texture.h|4 +- src/gallium/drivers/r300/r300_winsys.h | 127 +--- src/gallium/winsys/drm/i965/gem/i965_drm_winsys.h |2 + src/gallium/winsys/drm/radeon/core/Makefile|2 +- src/gallium/winsys/drm/radeon/core/radeon_buffer.h | 60 ++-- src/gallium/winsys/drm/radeon/core/radeon_drm.c| 134 +--- src/gallium/winsys/drm/radeon/core/radeon_drm.h|5 + .../winsys/drm/radeon/core/radeon_drm_buffer.c | 361 src/gallium/winsys/drm/radeon/core/radeon_r300.c | 237 -- src/gallium/winsys/drm/radeon/core/radeon_r300.h |6 +- src/gallium/winsys/drm/radeon/core/radeon_winsys.h | 86 +++-- 23 files changed, 347 insertions(+), 1247 deletions(-) Diff: http://cgit.freedesktop.org/mesa/mesa/diff/?id=b14548ea32000459f4f0c4b49f3fa11d1ee9c003 ___ mesa-commit mailing list mesa-com...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-commit -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 26692] i915g MaxCombinedTextureImageUnits 0 assersion failure
http://bugs.freedesktop.org/show_bug.cgi?id=26692 Brian Paul brian.e.p...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Brian Paul brian.e.p...@gmail.com 2010-02-22 07:15:04 PST --- Fixed with commits 98e2f6c38bede8373fbf51981ccf6b513ac3695c and 2467354842d7118efff73165ddaaf4c519b41e46. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] bin/mklib: Clear CDPATH to avoid damaging expand_archive output
On Sun, Feb 21, 2010 at 3:33 PM, Keith Packard kei...@keithp.com wrote: The bash 'cd' command tends to emit random stuff to stdout when the CDPATH variable is set, so clear it to keep extra filenames from being emitted from the expand_archive function, which would otherwise cause mklib to fail. Signed-off-by: Keith Packard kei...@keithp.com Signed-off-by: Brian Paul bri...@vmware.com Please commit to both master and mesa_7_7_branch. Thanks. -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] bin/mklib: Clear CDPATH to avoid damaging expand_archive output
On Sun, Feb 21, 2010 at 5:54 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Sun, Feb 21, 2010 at 2:33 PM, Keith Packard kei...@keithp.com wrote: The bash 'cd' command tends to emit random stuff to stdout when the CDPATH variable is set, so clear it to keep extra filenames from being emitted from the expand_archive function, which would otherwise cause mklib to fail. Signed-off-by: Keith Packard kei...@keithp.com Congratulations on wading in to mklib, it's not a friendly place. :) Heh, I guess you've never had to debug libtool then. mklib is a walk in the park by comparison. -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] st/dri: don't enable EXT_draw_buffers2 by default
On Sun, Feb 21, 2010 at 8:00 AM, Marek Olšák mar...@gmail.com wrote: Hi, the attached patch modifies st/dri to not enable EXT_draw_buffers2 by default because r300g and most probably even some other drivers can't support this extension. The drivers reporting support of PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch. Please review. Hmm, I believe the extensions listed in dri_extensions.c are those that _may_ be supported by drivers. But its the st_extensions.c code that queries the driver for various caps (such as PIPE_CAP_INDEP_BLEND_ENABLE) and then turns on the extension if applicable. Is GL_EXT_draw_buffers2 really being advertised by glxinfo with r300g? -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] st/dri: don't enable EXT_draw_buffers2 by default
Marek,
I don't particularly like that patch, because it doesn't really fix the
problem with the extension handling.
There are lots of extension listed there which should not be advertized
by default, so picking one out won't fix the others.
I think they are there because driInitExtensions definitely does more
than just set ctx-Extensions_foo_bar to enable.
Other extensions in this list which are queried by CAP bits but still
show up in the extension string regardless are the glsl ones
(ARB_fragment_shader and friends), a couple texture address modes
(mirrored_repeat, mirror_clamp), blend_equation_separate, technically
even ARB_multitexture (though we probably should skip the test for more
than 1 texture unit and always set that to true in st_extensions.c),
two-sided stencil, occlusion queries, anisotropic filtering, ycbcr
textures, packed depth stencil (there may be more that was just from a
quick look).
So if it's ok to remove them all from that list this should be done, but
I fear it's not ok and the fix needs to be a bit more complicated (see
comments in dri_init_extensions).
Roland
On 21.02.2010 16:00, Marek Olšák wrote:
Hi,
the attached patch modifies st/dri to not enable EXT_draw_buffers2 by
default because r300g and most probably even some other drivers can't
support this extension. The drivers reporting support of
PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch.
Please review.
Marek
From ddda2c19b74780263f848ffafe10809bd6385d01 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Sun, 21 Feb 2010 01:27:09 +0100
Subject: [PATCH 2/2] st/dri: don't enable EXT_draw_buffers2 by default
---
src/gallium/state_trackers/dri/dri_extensions.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri_extensions.c
b/src/gallium/state_trackers/dri/dri_extensions.c
index 1259813..7f8ceef 100644
--- a/src/gallium/state_trackers/dri/dri_extensions.c
+++ b/src/gallium/state_trackers/dri/dri_extensions.c
@@ -99,7 +99,6 @@ static const struct dri_extension card_extensions[] = {
{GL_EXT_blend_minmax, GL_EXT_blend_minmax_functions},
{GL_EXT_blend_subtract, NULL},
{GL_EXT_cull_vertex, GL_EXT_cull_vertex_functions},
- {GL_EXT_draw_buffers2, GL_EXT_draw_buffers2_functions},
{GL_EXT_fog_coord, GL_EXT_fog_coord_functions},
{GL_EXT_framebuffer_object, GL_EXT_framebuffer_object_functions},
{GL_EXT_multi_draw_arrays, GL_EXT_multi_draw_arrays_functions},
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Remove color index rendering?
On Fri, Feb 19, 2010 at 5:16 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While we're on the topic of removing dead weight, can we remove support for color index rendering? None of the hardware drivers support color index rendering, and color index rendering is deprecated in OpenGL 3.0 (and removed in 3.1). Can it please die in a fire? I think it can probably go. I haven't tested CI mode rendering in many years. Who knows if it even works any more. -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] glxinfo -l ARB prog errors
On Sat, Feb 20, 2010 at 9:32 AM, Xavier Chantry chantry.xav...@gmail.com wrote: On Sat, Feb 20, 2010 at 5:22 PM, Brian Paul brian.e.p...@gmail.com wrote: On Fri, Feb 19, 2010 at 7:34 PM, Xavier Chantry chantry.xav...@gmail.com wrote: It seems the commit below will always report an user error when glxinfo -l is called. And indeed I always get the following : $ glxinfo -l ... GL_VERTEX_PROGRAM_ARB: ... Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Should glxinfo be fixed to avoid this error ? We could just put the fragment program only parameter in its own list, and not use them when target is vertex program. Well, normally GL errors aren't reported to stderr so most people running non-debug builds won't see those. But yeah, we probably shouldn't generate the errors anyway. Feel free to write a patch to glxinfo... I only realized yesterday that non-debug was the reason other people (and some of my systems) didn't show these errors. It had been bugging me for a while :) Attached patch should fix it. Thanks. I'll commit it soon. -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] bin/mklib: Clear CDPATH to avoid damaging expand_archive output
On Mon, Feb 22, 2010 at 08:17:31AM -0700, Brian Paul wrote: On Sun, Feb 21, 2010 at 5:54 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Sun, Feb 21, 2010 at 2:33 PM, Keith Packard kei...@keithp.com wrote: The bash 'cd' command tends to emit random stuff to stdout when the CDPATH variable is set, so clear it to keep extra filenames from being emitted from the expand_archive function, which would otherwise cause mklib to fail. Signed-off-by: Keith Packard kei...@keithp.com Congratulations on wading in to mklib, it's not a friendly place. :) Heh, I guess you've never had to debug libtool then. mklib is a walk in the park by comparison. In fairness though, I haven't had to debug libtool for several years now, because it always seems to work, whereas mklib seems to encounter new and exciting failures all the time. Oh well. :) Cheers, Daniel pgpubVstqtFjL.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Remove color index rendering?
On 10-02-19 07:16 PM, Ian Romanick wrote: While we're on the topic of removing dead weight, can we remove support for color index rendering? None of the hardware drivers support color index rendering, and color index rendering is deprecated in OpenGL 3.0 (and removed in 3.1). Can it please die in a fire? As a workaround if someone really wants CI rendering, one can use VirtualGL to provide a CI visual on RGB-only hardware. -Nathan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] bin/mklib: Clear CDPATH to avoid damaging expand_archive output
On Mon, Feb 22, 2010 at 7:17 AM, Brian Paul brian.e.p...@gmail.com wrote: On Sun, Feb 21, 2010 at 5:54 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Sun, Feb 21, 2010 at 2:33 PM, Keith Packard kei...@keithp.com wrote: The bash 'cd' command tends to emit random stuff to stdout when the CDPATH variable is set, so clear it to keep extra filenames from being emitted from the expand_archive function, which would otherwise cause mklib to fail. Signed-off-by: Keith Packard kei...@keithp.com Congratulations on wading in to mklib, it's not a friendly place. :) Heh, I guess you've never had to debug libtool then. mklib is a walk in the park by comparison. Sorry, didn't mean to imply that it's simplicity is not a virtue. On the other hand, it doesn't get a ton of love, so it tends to be pretty incoherent. libtool debugging is an absolute nightmare, but thankfully it's been a long time since most people had to deal with that. -- Dan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Mesa removals
Starting a new thread on this... Here's a proposal of things to remove from the Mesa tree. GLU: glu/mini glu/mesa GLUT: glut/fbdev glut/ggi glut/directfb glut/dos glut/mini glut/os2 non-DRI drivers: drivers/allegro drivers/directfb drivers/d3d drivers/dos drivers/ggi drivers/glide drivers/svga DRI drivers: drivers/dri/fb drivers/dri/ffb drivers/dri/gamma progs/directfb progs/ggi progs/windml progs/miniglx Comments? -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa removals
Glide is a GL-glide driver, right? So it is not needed for libglide apps? Posting from a mobile, pardon my terseness. ~ C. On Feb 22, 2010 8:40 AM, Brian Paul bri...@vmware.com wrote: Starting a new thread on this... Here's a proposal of things to remove from the Mesa tree. GLU: glu/mini glu/mesa GLUT: glut/fbdev glut/ggi glut/directfb glut/dos glut/mini glut/os2 non-DRI drivers: drivers/allegro drivers/directfb drivers/d3d drivers/dos drivers/ggi drivers/glide drivers/svga DRI drivers: drivers/dri/fb drivers/dri/ffb drivers/dri/gamma progs/directfb progs/ggi progs/windml progs/miniglx Comments? -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa removals
Corbin wrote: Glide is a GL-glide driver, right? So it is not needed for libglide apps? Yes, correct. -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] bin/mklib: Clear CDPATH to avoid damaging expand_archive output
Please commit to both master and mesa_7_7_branch. Thanks. mesa_7_7_branch doesn't use 'cd' in mklib. -- keith.pack...@intel.com pgpjLL31Tv2B8.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa removals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: Starting a new thread on this... Here's a proposal of things to remove from the Mesa tree. GLU: glu/mini glu/mesa GLUT: glut/fbdev glut/ggi glut/directfb glut/dos glut/mini glut/os2 non-DRI drivers: drivers/allegro drivers/directfb drivers/d3d drivers/dos drivers/ggi drivers/glide drivers/svga DRI drivers: drivers/dri/fb drivers/dri/ffb drivers/dri/gamma progs/directfb progs/ggi progs/windml progs/miniglx Comments? That list looks good to me. I'm a little sad to see gamma go, but that's mostly sadness that it was never revived after the DRI / DRM architecture started going a different direction. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuC3xkACgkQX1gOwKyEAw/Z6wCeNvkBnT3OuCpeoHwHyILe9/TE 7jAAn3cNRz7pVgz16/xGOBJPd+J3DwsA =m62D -END PGP SIGNATURE- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] glapi: mode code generation to subdir
Hi, I put 3 patches in http://people.freedesktop.org/~gsap7/glapi/ that mv the code generation functionality in the gen subdir. Please review, regards, George. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa removals
On Mon, Feb 22, 2010 at 2:46 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: Starting a new thread on this... Here's a proposal of things to remove from the Mesa tree. GLU: glu/mini glu/mesa GLUT: glut/fbdev glut/ggi glut/directfb glut/dos glut/mini glut/os2 non-DRI drivers: drivers/allegro drivers/directfb drivers/d3d drivers/dos drivers/ggi drivers/glide drivers/svga DRI drivers: drivers/dri/fb drivers/dri/ffb drivers/dri/gamma progs/directfb progs/ggi progs/windml progs/miniglx Comments? That list looks good to me. I'm a little sad to see gamma go, but that's mostly sadness that it was never revived after the DRI / DRM architecture started going a different direction. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuC3xkACgkQX1gOwKyEAw/Z6wCeNvkBnT3OuCpeoHwHyILe9/TE 7jAAn3cNRz7pVgz16/xGOBJPd+J3DwsA =m62D -END PGP SIGNATURE- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev I'm actually in the process of gathering hardware to revive gamma (or rewrite its stack all together). So I don't know whether it should be removed or not. Certainly the mesa component of the stack won't be touched until I get a memory manager working. Matt -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa removals
I'm actually in the process of gathering hardware to revive gamma (or rewrite its stack all together). So I don't know whether it should be removed or not. Certainly the mesa component of the stack won't be touched until I get a memory manager working. I suspect any attempt at reviviing it will need a 3D driver re-write anyways. Since it heavily relies on the dma scheme it used. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa removals
-Original Message- From: Ian Romanick i...@freedesktop.org To: mesa3d-dev@lists.sourceforge.net mesa3d-dev@lists.sourceforge.net Sent: Mon, Feb 22, 2010 1:46 pm Subject: Re: [Mesa3d-dev] Mesa removals -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: Starting a new thread on this... Here's a proposal of things to remove from the Mesa tree. GLU: glu/mini glu/mesa GLUT: glut/fbdev glut/ggi glut/directfb glut/dos glut/mini glut/os2 non-DRI drivers: drivers/allegro drivers/directfb drivers/d3d drivers/dos drivers/ggi drivers/glide drivers/svga DRI drivers: drivers/dri/fb drivers/dri/ffb drivers/dri/gamma progs/directfb progs/ggi progs/windml progs/miniglx Comments? That list looks good to me. I'm a little sad to see gamma go, but that's mostly sadness that it was never revived after the DRI / DRM architecture started going a different direction. Does anyone have docs for gamma hardware? If so, I'd love to get my hands on it. I still have a gamma board that needs a bit of love! Dee Sharpe -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] glapi: mode code generation to subdir
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 George Sapountzis wrote: Hi, I put 3 patches in http://people.freedesktop.org/~gsap7/glapi/ that mv the code generation functionality in the gen subdir. Please review, I'm curious... what is the reason for these changes? I do like the addition of the MESA_DIR and MESA_GLX_DIR variables. I also like the change of GLX_DIR to XORG_GLX_DIR. Patches making those changes could probably go in right away. I'd like a little explanation of why everything should be moved to a subdirectory before doing that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuDO30ACgkQX1gOwKyEAw88fgCfTk0Y0CRTA0gphCENtx9KVbfE gP4AnRkZnRb92JNYu5ebB3wQwW3faO8j =6t7B -END PGP SIGNATURE- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Romanick wrote: Brian Paul wrote: I think we could get by with a shorter beta period. There's a few more things that would be nice to do for 7.8 which I doubt I'd get to before the 26th: Part of the reason for the long lead time is to keep my testing group happy. I don't see a problem moving the branch out a week (to 3/5). I'll check with them to be sure. I just talked to my QA team leader. Since it doesn't look like any of the proposed changes will impact testing our drivers, he's okay pushing branch creation out a week. I'll plan to make the 7.8 branch on 3/5 instead of 2/26. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuDOWEACgkQX1gOwKyEAw9VGQCgj6CwhfgV2g3IJ0qlEwjbYiw5 DfkAn11TltX3pc0sGtZDeFut6pRDgsrv =oBL7 -END PGP SIGNATURE- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] st/dri: don't enable EXT_draw_buffers2 by default
On Mon, Feb 22, 2010 at 4:23 PM, Brian Paul brian.e.p...@gmail.com wrote: On Sun, Feb 21, 2010 at 8:00 AM, Marek Olšák mar...@gmail.com wrote: Hi, the attached patch modifies st/dri to not enable EXT_draw_buffers2 by default because r300g and most probably even some other drivers can't support this extension. The drivers reporting support of PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch. Please review. Hmm, I believe the extensions listed in dri_extensions.c are those that _may_ be supported by drivers. But its the st_extensions.c code that queries the driver for various caps (such as PIPE_CAP_INDEP_BLEND_ENABLE) and then turns on the extension if applicable. I stand corrected. Is GL_EXT_draw_buffers2 really being advertised by glxinfo with r300g? Unfortunately yes, it is. -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
