Adam K Kirchhoff wrote:
For the past day or two I've been getting the following error when trying to
compile DRI from Mesa CVS:
gcc -c -I. -I../../../include -I../../../include/GL/internal
-I../../../src/mesa/main -I../../../src/mesa/glapi
-I../../../src/mesa/drivers/dri/common `pkg-config
Pedro Maia wrote:
Some of the new tests are not included in the MakeFile, and that makes it
impossible to do the make clean.
Fixed.
-Brian
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?
. Sorry.
Feel free to open a bug in the freedesktop.org bugzilla.
Correcting myself. There have been updates to the Savage driver after I
stopped working on it by Ian Romanick, Brian Paul and Eric Anholt and
maybe others. Sorry folks, I appreciate your work! Is anyone going to
look into this xmakemol
Malek wrote:
Hey guys,
Just setting up a laptop here, was compiling from CVS and hit an error.
Seems someone left an extra _ in a type definition... did a search thru
the code and the _'ed version isn't used anywhere, so I'm guessing it
was just a typo.
I'm not sure what the format you guys
Dave Airlie wrote:
If you take a look at
http://www.skynet.ie/~airlied/butns.png
you'll see the same texture being drawn in two places, however the second
one is corrupt along the triangle join line...
the only difference between the two is the glTranslate called before them
moves the centre
Thomas Hellström wrote:
Thomas Hellström wrote:
Brian Paul wrote:
Yeah, I think code at lines 204 and 566 is bogus.
In drm.h:
#if defined(__linux__)
typedef unsigned int drm_handle_t;
#else
typedef unsigned long drm_handle_t; /** To mapped regions */
#endif
But in XF86dri.c we have
Adam K Kirchhoff wrote:
FYI, I'm attaching two very small patches that get the r300 driver
working with my AGP X700 card.
Checked in.
-Brian
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?
Tomas Carnecky wrote:
x86_64-pc-linux-gnu-gcc -c -I. -I../../../include
-I../../../include/GL/internal -I../../../src/mesa/main
-I../../../src/mesa/glapi -I../../../src/mesa/drivers/dri/common
`pkg-config --cflags libdrm` -I/usr/X11R6/include -Wall -march=k8 -O2
-pipe -fPIC -m64
Dave Airlie wrote:
I'm a bit rusty on the DRM but it looks like the changes are minor so
I may do the updates unless someone beats me to it, or indicates
there's a reason for things as they are.
I'm still catching up on email from the holiday weekend, but I plan to import
a new libdrm into the
Aapo Tahkola wrote:
On Fri, 25 Nov 2005 16:16:48 -0700
Brian Paul [EMAIL PROTECTED] wrote:
I've been playing around with the EGL r200 driver. Digging through
the framebuffer allocation code I've found a few problems.
In order to support pbuffers and framebuffer objects we need to be
able
I've been poking around in the DRM code a bit. One thing I've noticed
is that the xf86drm.h file in the DRI/drm tree is a bit out of sync
with the xf86drm.h file in the X.org tree. In particular, the use of
unsigned long vs. drm_handle_t. It looks like the later (drm_handle_t
in the X.org
I've been playing around with the EGL r200 driver. Digging through
the framebuffer allocation code I've found a few problems.
In order to support pbuffers and framebuffer objects we need to be
able to work with color/depth/stencil buffers are various locations in
video memory.
The
Can you print the value of nearby local vars, such as 'texObj',
'reallyEnabled' and 'i'?
I bet a patch along the lines of what I've attached might fix the problem.
-Brian
Sergio Monteiro Basto wrote:
Hi,
with Mesa CVS no luck
just a better debug
Program received signal SIGSEGV,
Sergio Monteiro Basto wrote:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208236352 (LWP 25396)]
0x00fa4afb in run_texnorm_stage (ctx=0x8ce54e0, stage=0x8e81b58) at
savagerender.c:251
251 GLboolean normalizeS = (texObj-WrapS == GL_REPEAT);
(gdb) print
pedro.lixo wrote:
It's a just a simple txt pointing out some warnings that i have during
compilation. They should be easy to resolve...
I've checked in fixes for most of these.
-Brian
---
This SF.Net email is sponsored by the JBoss Inc.
Philipp Klaus Krause wrote:
Ian Romanick schrieb:
Here's my opinion on the matter, but I'd like to hear from Brian or Keith.
1. All drivers should expose GL_ARB_vertex_program and
GL_MESA_program_debug. I don't care either way about the NV extensions.
So you think we should announce it
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Scheidegger wrote:
Philipp Klaus Krause wrote:
3) It is a widespread extension, not a Nvidia-specific one: It is
implemented by the i915 driver, the mga driver, the tdfx driver, the
r300 driver, the non-free 3Dlabs
Benjamin Herrenschmidt wrote:
Hi !
The code that swaps ycbcr textures had a bug that would cause it to
corrupt memory by applying an incorrect stride (applying a byte offset
to a GLushort pointer). This crashes applications trying to use those
textures with DRI on ppc at least, and crashes the
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
It's been a long time since I've looked at this stuff, but I'm not sure
that __glXImageSize() is correct. Specifically, the last part of the
function:
[...]
if (imageHeight 0) {
imageSize
Alex Deucher wrote:
On 9/28/05, John Shillinglaw [EMAIL PROTECTED] wrote:
Hello,
I have a Thinkpad T20 with a Savage IX, that is running Gentoo Linux
with 2.6.14-rc2-mm1 kernel.
In order to get direct rendering working, I have followed the build from
cvs instructions on the dri wiki. Now
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm trying to get the patches attached to bug #2996 update. As part of
that, I'm generating some smaller, more trivial patchs to commit to the
tree /before/ RC1. I committed one really trivial one last night (the
EvalComputeK
Philip Prindeville wrote:
I'm seeing the following when building Mesa:
gcc -O2 -fstrict-aliasing -ansi -pedantic -Wall -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wredundant-decls
-Wnested-externs
Roland Scheidegger wrote:
Ian Romanick wrote:
Another good test would be to modify progs/demos/pixeltexl to use
ATI_fs instead of SGIS_pixel_texture.
Sounds actually not that easy. Or maybe I just don't understand the spec
there very well.
The basic idea of GL_SGIS_pixel_texture and the
I checked in updates for the remaining DRI drivers. If anyone finds
breakage, I'll try to help fix the problems.
-Brian
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA *
Alan Grimes wrote:
I'm not sure if this is on topic, but I figured out how to parameterize
GL so that it can emulate the N64's lighting unit (using vertex arrays).
While that seemed to work well enough, I noticed that in doing so, the
system was nolonger processing the color array! Is this
Matthias Hopf wrote:
find a patch attached that fixes all remaining strict-aliasing problems
when compiling Mesa with gcc 4 (at least for me).
Are you sure you've got the #ifdef logic correct?
Actually, no. And I didn't recognize what you were referring to until
today...
You are right, it
Roland Scheidegger wrote:
Brian Paul wrote:
I'm checking in the updated radeon and r200 drivers and I'll do the
mach64 and r128 drivers next. I've tested the radeon changes, but not
the r200. If someone could run the reflect demo on r200 and use the
a/s/d/f/c keys to exercise the span
Roland Scheidegger wrote:
Brian Paul wrote:
- Pageflipping is completely broken. Looks like stuff gets drawn to
the right place only every second frame or something like that (i.e.
heavy flicker).
What's the trick for enabling/testing page flipping? I thought I had
it going
Roland Scheidegger wrote:
Brian Paul wrote:
Option EnablePageFlip true
somewhere in the xorg.conf device section. It is still problematic
though, just yesterday I've noticed that detection if it has to be
disabled is pretty broken now (e.g. starting two opengl apps it
seemed to miss
I'm trying to tie up some loose ends from the
GL_EXT_framebuffer_object work I did a while back.
I previously updated the span functions so they'd take a
gl_renderbuffer pointer and now I'm making the code actually use that
parameter. The idea is to use the fields of the gl_renderbuffer
Alan Grimes wrote:
I've noticed a stream of updates for both the drm and Mesa trees.
Because it takes a certain ammount of effort to test a build of these
trees, I was wondering if there was a changelog I might use to help me
determine wheather a recient change in the source might address the
Dieter Nützel wrote:
i830_metaops.c: In function `i830TryTextureDrawPixels':
i830_metaops.c:628: error: structure has no member named `OcclusionTest'
make[6]: *** [i830_metaops.o] Fehler 1
make[6]: Leaving directory `/opt/Mesa/src/mesa/drivers/dri/i915'
-DGLX_DIRECT_RENDERING -DHAVE_ALIAS
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dieter Nützel wrote:
i830_metaops.c: In function `i830TryTextureDrawPixels':
i830_metaops.c:628: error: structure has no member named `OcclusionTest'
make[6]: *** [i830_metaops.o] Fehler 1
make[6]: Leaving directory
Michel Dänzer wrote:
On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote:
Alan Cox wrote:
The log design presents numerous opportunities for rogue processes to do
bad things. At some level, that's inherent in the nature of direct
rendering. If you don't trust the processes, don't
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
1. I'd like an allocator that can be used outside/independent of the
Xserver. Specifically, an allocator that EGL and EGL drivers can use.
2. There needs to be a way to share memory blocks between processes
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Ian Romanick wrote:
In the prototype code that I posted to the list several months ago,
these four things were handled together. Each object has an associated
region ID. The region IDs are allocated
Zack Rusin wrote:
On Sunday 14 August 2005 09:02 pm, Adam Jackson wrote:
Adam Jackson schrieb:
NV_texture_rectangle
This shouldn't be really necessary if one is
willing to waste some texture memory.
In some cases, quite a lot of memory. A 513x513 texture wastes between 1.5
and 3M of
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Whitwell wrote:
Roland Scheidegger wrote:
Try this patch here:
http://marc.theaimsgroup.com/?l=mesa3d-devm=112337787415898w=2
That should fix the issue. I believe it not only fixes it, but it's
the right thing to do,
Egbert Eich wrote:
The patch below allows 32bit builds of Mesa
on 64bit (especially x86_64) systems.
The '-m32' option for gcc/g++ should work with all
versions of gcc = 3.0 - also on ia32.
Ok, I've checked in the fix, with minor changes.
-Brian
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Egbert Eich wrote:
The patch below allows 32bit builds of Mesa
on 64bit (especially x86_64) systems.
The '-m32' option for gcc/g++ should work with all
versions of gcc = 3.0 - also on ia32.
Egbert.
Index:
Shawn Starr wrote:
Do we have a plan on doing this? It would be good to merge things since you
don't want to diverge too much?
You can put the r300 code in the Mesa tree anytime, as far as I'm
concerned.
-Brian
---
This SF.Net email is
Matthias Hopf wrote:
Hi,
find a patch attached that fixes all remaining strict-aliasing problems
when compiling Mesa with gcc 4 (at least for me).
Are you sure you've got the #ifdef logic correct?
#if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig)
typedef void *fbc_t;
#else
typedef
Matthias Hopf wrote:
On Jul 13, 05 09:16:32 -0600, Brian Paul wrote:
find a patch attached that fixes all remaining strict-aliasing problems
when compiling Mesa with gcc 4 (at least for me).
Are you sure you've got the #ifdef logic correct?
I just copied the one that was already present
Jon Smirl wrote:
On 7/12/05, Adam Jackson [EMAIL PROTECTED] wrote:
On Tuesday 12 July 2005 11:17, Jon Smirl wrote:
On 7/12/05, Adam Jackson [EMAIL PROTECTED] wrote:
On Tuesday 12 July 2005 10:03, Jon Smirl wrote:
Is there a way to build DRI exactly like X needs from the mesa tree or
can
Jon Smirl wrote:
On 7/3/05, Adam Jackson [EMAIL PROTECTED] wrote:
Why aren't the DRI drivers themselves EGL drivers? That's sort of the model I
was anticipating:
- eglChooseDisplayMESA(display/0)
- EGL translates to /dev/dri/card0, opens it
- ioctl: what's the DRI driver name for this
Philipp Klaus Krause wrote:
Rune Petersen schrieb:
Hi,
Enabling water in Scorched3D causes corruption of all textures and I
have tracked it down to interaction between glPopAttrib() and the
attributes GL_TEXTURE_GEN_S GL_TEXTURE_GEN_T.
I using the latest CVS updates of Xorg, Mesa, and
Rune Petersen wrote:
Brian Paul wrote:
Philipp Klaus Krause wrote:
Rune Petersen schrieb:
Hi,
Enabling water in Scorched3D causes corruption of all textures and I
have tracked it down to interaction between glPopAttrib() and the
attributes GL_TEXTURE_GEN_S GL_TEXTURE_GEN_T.
I using
Nicolai Haehnle wrote:
On Monday 02 May 2005 16:56, Brian Paul wrote:
This weekend I finished updating the DRI drivers to work with the new
framebuffer/renderbuffer changes. My DRI test system is terribly out
of date so I haven't run any tests. I'm tempted to just check in the
changes now
Ryan Richter wrote:
On Sun, May 15, 2005 at 11:38:28AM +0100, Dave Airlie wrote:
with XF4.3 you might need to use RADEON_NO_TCL=1 instead, I've no idea
Nevermind, it's R200_NO_TCL=1. I'll start testing this out on Monday.
By the way, what is TCL? :)
Vertex Transformation, Clipping and Lighting.
Ronny V. Vindenes wrote:
fre, 13,.05.2005 kl. 08.56 -0400, skrev David Kesselring:
I'm trying to build the software only mesa on cygwin but have a compile
error for a missing definition. Would any of you know where to look for
M_E from the following snip?
t_vp_build.c, build_fog()
case GL_EXP:
Jon Smirl wrote:
On 5/5/05, Brian Paul [EMAIL PROTECTED] wrote:
Weird. Have you tried different pixel formats? Maybe one of the span
routines is wrong (duplicating R or G or B across all components).
Though I don't see anything wrong after a quick look.
fbFillInModes wasn't quite right
Jon Smirl wrote:
On 5/6/05, Brian Paul [EMAIL PROTECTED] wrote:
In the new renderbuffer scheme, the span routines are passed a
gl_renderbuffer pointer to indicate which buffer is to be drawn to.
Previously, the driver's set_buffer() routine was called to indicate
which buffer the span routines
Jon Smirl wrote:
On 5/4/05, Brian Paul [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Can you touch up driver/dri/fb too? I was working on it as a potential
way to test the egl code.
The fixes are checked in.
I fixed up the issues with fbOrigin that you made comments on. It is
drawing the right shapes
David Kesselring wrote:
I've downloaded the latest code from cvs and built using 'make
linux-fbdev'. It does not look like progs/fbdev dir was built. Is that
expected or should it be built with the linux-fbdev option?
I think that adding
PROGRAM_DIRS = fbdev
to configs/linux-fbdev is all that's
I've checked in all my changes. Hopefully this won't be too
disruptive. I'll help fix any problems that pop up.
-Brian
---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great
Brian Paul wrote:
I've checked in all my changes. Hopefully this won't be too
disruptive. I'll help fix any problems that pop up.
Incidentally, progs/test/fbotexture.c is a demo of render-to-texture.
It'll only run with the Xlib driver right now since
GL_EXT_framebuffer_object is only
Jon Smirl wrote:
Can you touch up driver/dri/fb too? I was working on it as a potential
way to test the egl code.
Oops, I guess I only partially updated things there. I should be able
to fix that by tomorrow.
-Brian
---
This SF.Net email is
Jon Smirl wrote:
Can you touch up driver/dri/fb too? I was working on it as a potential
way to test the egl code.
The fixes are checked in.
-Brian
---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it
This weekend I finished updating the DRI drivers to work with the new
framebuffer/renderbuffer changes. My DRI test system is terribly out
of date so I haven't run any tests. I'm tempted to just check in the
changes now and help people fix any problems that arise, rather than
spend a few
Simon Toedt wrote:
Has anyone yet looked into ways to improve rendering performance? I
have noticed that glXSwapBuffers() is slow (30secs +/-5secs on a
P3/600Mhz) and mainly spends its time in PsOutImageBytes() which calls
sprintf() in a tight loop:
(gdb) where
#0 PsOut_OutImageBytes
This is basically for I18N, right?
You mention that Python and the gettext tools to run the Makefile.
Will everyone need these? I.e. is there a new dependency here?
-Brian
Felix Kühling wrote:
I haven't got any feedback on this yet. I have made a few improvements
and as far as I'm concerned
Ian Romanick wrote:
Brian Paul wrote:
Adam Jackson wrote:
Yeah, I just threw out glXGetProcAddress as a suggestion. It's
probably better to pass this table into the driver through the create
context method.
[snip]
Right. glXGetProcAddress() should not be used by libGL or the drivers
to get
Julien Lafon wrote:
On Apr 5, 2005 10:11 PM, Brian Paul [EMAIL PROTECTED] wrote:
Roland Mainz wrote:
Ian Romanick wrote:
When I look at xc/extras/Mesa/src/mesa/main/config.h I see more items on
my wishlist: Would it be possible to increase |MAX_WIDTH| and
|MAX_HEIGHT| (and the matching texture
Julien Lafon wrote:
On Apr 6, 2005 3:37 PM, Brian Paul [EMAIL PROTECTED] wrote:
Julien Lafon wrote:
On Apr 5, 2005 10:11 PM, Brian Paul [EMAIL PROTECTED] wrote:
Will increasing MAX_WIDTH/HEIGHT affect applications which run in
small windows or only those which use resolutions exceeding the 4Kx4K
Roland Mainz wrote:
Brian Paul wrote:
On Apr 5, 2005 10:11 PM, Brian Paul [EMAIL PROTECTED] wrote:
Will increasing MAX_WIDTH/HEIGHT affect applications which run in
small windows or only those which use resolutions exceeding the 4Kx4K
limit?
Increasing MAX_WIDTH/HEIGHT will result in more memory
Roland Mainz wrote:
Brian Paul wrote:
[snip]
What about making MAX_WIDTH and MAX_HEIGHT runtime-configurable - would
that be possible (for stack allocations the Mesa code then has to depend
on |alloca()|) ?
Probably do-able, but a lot of work.
Depends... if |alloca()| can safely be used on all
Roland Mainz wrote:
Ian Romanick wrote:
For X.org 6.9 / 7.0 I would like to break the existing libGL / DRI
driver interface. There is a *LOT* of crap hanging around in both libGL
and in the DRI drivers that exists *only* to maintain backwards
compatability with older versions of the interface.
Nicolai Haehnle wrote:
On Tuesday 05 April 2005 22:11, Brian Paul wrote:
If you increase MAX_WIDTH/HEIGHT too far, you'll start to see
interpolation errors in triangle rasterization (the software
routines). The full explanation is long, but basically there needs to
be enough fractional bits
Adam Jackson wrote:
On Tuesday 05 April 2005 19:03, Ian Romanick wrote:
Adam Jackson wrote:
I have another one: Hide all the functions that start with XF86DRI*, and
expose them to the driver through a function table or glXGetProcAddress
rather than by allowing the driver to call them directly.
Adam Jackson wrote:
On Tuesday 05 April 2005 16:11, Brian Paul wrote:
Roland Mainz wrote:
Another item would be to look into what's required to support visuals
beyond 24bit RGB (like 30bit TrueColor visuals) ... someone on IRC
(AFAIK ajax (if I don't mix-up the nicks again :)) said that this may
Keith Conger wrote:
Hi,
With the dri patch Paul just checked in, I'm now getting the following
when I run glxgears:
$ glxgears
Using 8 maximum texture units..
sizeof(drm_r300_cmd_header_t)=4
sizeof(drm_radeon_cmd_buffer_t)=16
Allocating 284420 bytes command buffer (max state is 11140 bytes)
Roland Scheidegger wrote:
here's a patch which mainly does 3 things:
- convert sis, mach64, and radeon to spantmp2.
The sis and mach64 drivers got a slight change, previously you could not
read back alpha values (always 0xff) and I don't think there was a good
reason for that?
IIRC, the mach64
This extension can't be easily/cleanly added to Mesa without rewriting
and changing some existing code. But ultimately, the changes will be
for the better, much in the way that GL_NV/ARB_vertex_program improved
the TNL code.
I'll assume people are familiar with GL_EXT_framebuffer_object. If
Ian Romanick wrote:
Brian Paul wrote:
I'll assume people are familiar with GL_EXT_framebuffer_object. If
not, read the spec.
If you still have questions after reading the spec, you can ask me on
#dri-devel on freenode. I try to be on there as often as I can.
The gl_renderbuffer's BaseFormat
Adam Jackson wrote:
On Thursday 03 March 2005 10:42, Brian Paul wrote:
The stencil, depth, accum, aux, etc. buffer pointers in GLframebuffer
will go away, replaced by gl_renderbuffer_attachment members.
Each of the logical buffers (such as color, depth, stencil, etc) which
form the overall
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
here's a patch which mainly does 3 things: - convert sis, mach64,
and radeon to spantmp2. The sis and mach64 drivers got a slight
change, previously you could not read back alpha values (always
0xff) and I don't think
Roland Scheidegger wrote:
Michel Dnzer wrote:
On Thu, 2005-03-03 at 20:22 +0100, Roland Scheidegger wrote:
Michel Dnzer wrote:
On Wed, 2005-03-02 at 16:11 +0100, Marcello Maggioni wrote:
When using HW TCL in Tuxracer or PPRacer (that is essentially the same
game) with my Radeon 8500 with DRI
Stephane Marchesin wrote:
Hi,
Here is a small patch to make miniglx compile on gcc 2.
Checked in.
-Brian
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which
Dave Airlie wrote:
I've synced up the glx.h in Mesa from the glx.h in Xorg, ajax suggested we
copy over the other glx header files into Mesa as well, good idea?
Sure. It should have probably been done a long time ago.
-Brian
---
SF email is
Adam Jackson wrote:
On Sunday 20 February 2005 13:20, Brian Paul wrote:
Adam Jackson wrote:
I'm working on this, actually. Right now I'm doing it as an EGL-GLX
translation layer so we can get glitz retargeted at the EGL API. Turning
that into a dispatch layer wouldn't be too tough, particularly
Mathieu Malaterre wrote:
Hello,
I am using Mesa 6.2.1 and I am getting a SIGFPE:
[Thread debugging using libthread_db enabled]
[New Thread 1100658336 (LWP 13415)]
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 1100658336 (LWP 13415)]
Brian Paul wrote:
Mathieu Malaterre wrote:
Hello,
I am using Mesa 6.2.1 and I am getting a SIGFPE:
[Thread debugging using libthread_db enabled]
[New Thread 1100658336 (LWP 13415)]
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 1100658336 (LWP 13415
Adam Jackson wrote:
On Tuesday 22 February 2005 11:48, Brian Paul wrote:
Adam Jackson wrote:
I pounded out most of the rest of the API compat today. This is good
enough to run eglinfo and return mostly correct answers (caveat is always
slow for some reason), and of the 25ish egl* entrypoints only
Vladimir Dergachev wrote:
The reason I am asking is that R300 appears to support all (or almost
all)
GL texture formats and it would not be too difficult to add this
support,
but we are using R200 switch() due to lack of understanding of
Mesa-driver interface.
Well, even if the hardware does
Dave Airlie wrote:
Hi,
Well I spent the day hacking and managed to get Xgl running on top
of Mesa solo, the solo stuff I've checked into Mesa,
Neat!
The glitz backend for miniglx and the Xserver miniglx stuff are up at
http://www.skynet.ie/~airlied/patches/xminiglx/
There is no input
Adam Jackson wrote:
On Sunday 20 February 2005 11:29, Brian Paul wrote:
Dave Airlie wrote:
building an Xserver on top of mesa solo is a bit of a nightmare in terms
of includes and defines .. as an Xserver requires all the X types to
build but solo has its own set of defines/typedefs that don't
Jerome Glisse wrote:
Hi,
I wanted to know how i can ask mesa to
give me the texture in a specified order.
i.e. actually mesa give me texture in
RGBA_REV
while i want it in RGBA
I have tried to have by specifing
GL_UNSIGNED_INT_8_8_8_8_REV
to the format parameter of glTexImage2D
This
Jerome Glisse wrote:
No. The format parameter describes the incoming format of the
user's texture image. It may or may not have any bearing on which
hardware format is chosen by the driver. More typically, the
internalFormat parameter is used by the driver to choose the
hardware texture format.
Vladimir Dergachev wrote:
in the driver (r300) i really would like
to test all texture format, so is there
a way to ask mesa to send me texture
in a specific order (REV or not)
No. The format parameter describes the incoming format of the
user's texture image. It may or may not have any
Jacek Rosik wrote:
Hi all,
Radeon and R200 drivers report GL_MAX_VIEWPORT_DIMS=4096, 4096, but I
think that hardware can maximally suport 2048, 2048. Anyway I don't
think current drivers don't even support 1, 1 if window will be placed
further from top left corner than 2048 in any direction.
So, I
Pasi Kärkkäinen wrote:
Hi list!
http://www.opengl.org/documentation/extensions/EXT_framebuffer_object.txt
Has finally been posted.. hopefully it will be implemented in Mesa soon :)
Don't hold your breath. It'll take quite a bit of work.
I think the design of GL_EXT_framebuffer_object took longer
Felix Kühling wrote:
Am Do, den 16.12.2004 schrieb Brian Paul um 16:45:
Felix Kühling wrote:
Hi,
I noticed some strange rendering artifacts with the Savage that are
caused by very large texture coordinates on GL_REPEAT'ed textures. Very
large means that it gets noticeable with texture coordinates
Stephane Marchesin wrote:
Jacek Popawski wrote:
On Thu, Dec 02, 2004 at 08:49:56AM -0500, Alex Deucher wrote:
Radeon 9000 PCI Radeon 9200se AGP
these two chips are already fully supported by xorg and the DRI.
Fully? Was HyperZ only missing feature?
There are at least 2 other features :
- pixel
Stephane Marchesin wrote:
Ok, here is a new patch.
Looks OK. Someone with a Radeon card should test this with the
Mesa/progs/demos/readpix.c demo. Drag the readpix window off the
left/right/bottom/top edges of the screen and make sure things look
OK. Be sure to test both the front and back
Dieter Ntzel wrote:
DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA-c xm_api.c
In file included from /opt/Mesa/src/mesa/main/context.h:51,
from xm_api.c:66:
/opt/Mesa/src/mesa/glapi/glapi.h:54: Warnung: function declaration isn't a
prototype
xm_api.c: In function
You're more likely to get help on the DRI list. I'm cc'ing it.
-Brian
Daniel Sperka wrote:
I'm having problems getting miniglx to render anything with my Radeon9000.
I saw a post about this from some time back, but no replies to it. I
start up simple_server and get this reponse:
[EMAIL
Stephane Marchesin wrote:
Brian Paul wrote:
I guess I'd like to see the clipping issues resolved before checking
in the patch.
Ok, I'm not sure I understood what you expect, but here is what I did :
I used the mesa window space clipping routines and then added a
dri/common/clip.h file that does
Stephane Marchesin wrote:
Brian Paul wrote:
I'll be checking in a fix for this soon.
I've replaced the _swrast_clip_pixelrect() functions with two new
functions: _mesa_clip_readpixels() and _mesa_clip_drawpixels(). The
main difference is the later one obeys the scissor rectangle.
The DRI
Brian Paul wrote:
Stephane Marchesin wrote:
Hi,
The attached patch adds readpixel acceleration to the r100 based on
what's done for the r200.
This speeds-up readpix by a factor of 2 on x86, and much more on
non-x86 systems which don't benefit from Ian's patch (like 8 times on
itanium 2).
I
Stephane Marchesin wrote:
Hi,
The attached patch adds readpixel acceleration to the r100 based on
what's done for the r200.
This speeds-up readpix by a factor of 2 on x86, and much more on non-x86
systems which don't benefit from Ian's patch (like 8 times on itanium 2).
I only glanced over the
101 - 200 of 682 matches
Mail list logo
