On Sun, Apr 24, 2011 at 10:08 AM, Marek Olšák mar...@gmail.com wrote:
On Sun, Apr 24, 2011 at 1:15 AM, Dave Airlie airl...@gmail.com wrote:
Hi Brian,
st/mesa: check image size before copy_image_data_to_texture()
This causes a regression with NPOT textures in fbo-generate-mipmaps on
r600g
Hi Brian,
st/mesa: check image size before copy_image_data_to_texture()
This causes a regression with NPOT textures in fbo-generate-mipmaps on r600g.
Please don't put it into 7.10 until we can figure out why, but I'm
guessing the restrictions are too strict.
Dave.
On Tue, Apr 13, 2010 at 11:42 PM, Roland Scheidegger srol...@vmware.com wrote:
On 13.04.2010 02:52, Dave Airlie wrote:
On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul bri...@vmware.com wrote:
Dave Airlie wrote:
Just going down the r300g piglit failures and noticed fbo-drawbuffers
failed, I've
02:52, Dave Airlie wrote:
On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul bri...@vmware.com wrote:
Dave Airlie wrote:
Just going down the r300g piglit failures and noticed fbo-drawbuffers
failed, I've no idea
if this passes on Intel hw, but it appears the texenvprogram really
needs to understand
On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul bri...@vmware.com wrote:
Dave Airlie wrote:
Just going down the r300g piglit failures and noticed fbo-drawbuffers
failed, I've no idea
if this passes on Intel hw, but it appears the texenvprogram really
needs to understand the
draw buffers
(3) Should gl_FragColor be aliased to gl_FragData[0]?
RESOLUTION: No. A shader should write either gl_FragColor, or
gl_FragData[n], but not both.
Writing to gl_FragColor will write to all draw buffers specified
with DrawBuffersARB.
So I was really just masking the
So I don't understand cmake,
but there is a lot of implicit linking going on in piglit, and in
Fedora 13 our linker doesn't like that anymore.
So for example the fp-rfl test uses sqrt which means it needs to link
to libm not get libm via other links,
glx-multithread needs to link to pthread etc.
On Tue, Apr 6, 2010 at 10:47 PM, Keith Whitwell kei...@vmware.com wrote:
On Fri, 2010-04-02 at 20:43 -0700, Dave Airlie wrote:
Just going down the r300g piglit failures and noticed fbo-drawbuffers
failed, I've no idea
if this passes on Intel hw, but it appears the texenvprogram really
needs
On Mon, Apr 5, 2010 at 5:24 PM, Chia-I Wu olva...@gmail.com wrote:
On Mon, Apr 5, 2010 at 1:41 PM, Dave Airlie airl...@gmail.com wrote:
On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu olva...@gmail.com wrote:
On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie airl...@gmail.com wrote:
The attached patch
On Mon, Apr 5, 2010 at 6:06 PM, Chia-I Wu olva...@gmail.com wrote:
On Mon, Apr 5, 2010 at 3:38 PM, Dave Airlie airl...@gmail.com wrote:
On Mon, Apr 5, 2010 at 5:24 PM, Chia-I Wu olva...@gmail.com wrote:
On Mon, Apr 5, 2010 at 1:41 PM, Dave Airlie airl...@gmail.com wrote:
On Mon, Apr 5, 2010
Hey,
So I was trying to fix tfp test on r300g, and ran into an issue with
dri st I think.
So the way TFP works we get dri2_set_tex_buffer, which then validates the
attachment, but ignores the format passed in. So r300g picks up the kernel
buffer from the handle and sets up the texture + texture
On Sun, Apr 4, 2010 at 8:31 PM, Dave Airlie airl...@gmail.com wrote:
Hey,
So I was trying to fix tfp test on r300g, and ran into an issue with
dri st I think.
So the way TFP works we get dri2_set_tex_buffer, which then validates the
attachment, but ignores the format passed in. So r300g
Here's a hacky patch to demonstrate the issue, though it doesn't fix the
problem
I'm seeing with the test, just one less thing wrong.
Here's a second patch that actually fixes the piglit tfp test for me on r300g.
Dave.
0001-dri-st-add-hacky-tfp-format-override-v2.patch
Description:
Starting program: /home/airlied/mesa/progs/demos/readpix
[Thread debugging using libthread_db enabled]
GL_VERSION = 2.1 Mesa 7.9-devel
GL_RENDERER = Gallium 0.4 on RV530
Program received signal SIGSEGV, Segmentation fault.
0xb7cc13dd in _mesa_get_color_read_type (ctx=0x8086e38)
at
On Mon, Apr 5, 2010 at 12:49 PM, Chia-I Wu olva...@gmail.com wrote:
On Sun, Apr 4, 2010 at 6:31 PM, Dave Airlie airl...@gmail.com wrote:
Hey,
So I was trying to fix tfp test on r300g, and ran into an issue with
dri st I think.
So the way TFP works we get dri2_set_tex_buffer, which
On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu olva...@gmail.com wrote:
On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie airl...@gmail.com wrote:
The attached patch fixes tfp test for me (with i915g). Could you see if
r300g
passes the test with the patch?
The teximage callback has an internal_format
The piglit read-front.c test is failing and the rabbits warren that is
front buffer rendering in mesa st + dri st isn't helping me solve it.
One thing I noticed was check_create_front_buffers is called in a
number of places in the st, however it seems to never be used, as we
call
Just going down the r300g piglit failures and noticed fbo-drawbuffers
failed, I've no idea
if this passes on Intel hw, but it appears the texenvprogram really
needs to understand the
draw buffers. The attached patch fixes it here for me on r300g anyone
want to test this on Intel
with the piglit
On Tue, Mar 30, 2010 at 6:26 PM, Nicolai Haehnle nhaeh...@gmail.com wrote:
Reply to all this time...
On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák mar...@gmail.com wrote:
1) Branching and looping
This is the most important one and there are 3 things which need to be
done.
* Unrolling
I'm not even sure if its fully working, and I've done some nasty stuff
in the autoconf.in that probably doesn't belong there,
also the dri makefile change to use g++ instead of cc, not sure if
there is a cleaner way to do that either.
Dave.
0001-llvmpipe-add-initial-autoconf-support.patch
On Mon, Mar 8, 2010 at 5:51 PM, Jose Fonseca jfons...@vmware.com wrote:
Dave,
I don't oppose this new method -- it shouldn't be necessary to add fencing
just to use pb_cache --, but this method adds a new way of doing the same
thing.
Does the underlying buffer support
On Tue, Mar 23, 2010 at 11:41 PM, Luca Barbieri luca.barbi...@gmail.com wrote:
Do Radeons have a CP command to write an arbitrary value to some place
in memory?
If so, you may want to use that to implement userspace-accessible
fencing in the obvious way and then use the fenced bufmgr, which
On Sat, Mar 20, 2010 at 4:18 AM, Sedat Dilek sedat.di...@googlemail.com wrote:
Hi Marek - you are nominated for the next DRIgeller (Uri Geller) :-)
concerning my problems r300g dri/st with mesa master GIT:
THE BAD:
commit 68e58a96e80865878e6881dc4d34fcc3ec24eb19
Author: Dave Airlie airl
On Wed, Mar 10, 2010 at 6:47 AM, Keith Whitwell kei...@vmware.com wrote:
On Tue, 2010-03-09 at 12:43 -0800, Dave Airlie wrote:
On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell kei...@vmware.com wrote:
On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote:
On Tue, Mar 9, 2010 at 6:08 AM
On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell kei...@vmware.com wrote:
On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote:
On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell kei...@vmware.com wrote:
This leaves r300g as the only remaining user of
pipe_winsys/u_simple_screen - which means
On Tue, Mar 9, 2010 at 11:30 AM, Luca Barbieri luca.barbi...@gmail.com wrote:
The fencing solution isn't near as efficent from what I can see, as it
is designed around fences not buffer busy, I'll see if I can give it a try,
but I suspect it look and smell like a hack.
The problem I see is
On Sun, Mar 7, 2010 at 9:44 PM, Luca Barbieri luca.barbi...@gmail.com wrote:
I think you are supposed to do this using the fenced bufmgr over
cached along with a (ideally userspace) fencing mechanism.
If you can implement pb_busy, you should be able to implement
fence_signalled in exactly the
So in classic drivers we can hit swrast fallbacks for things like
ReadPixels where we know we aren't going to have to want to touch
textures at all. This would be useful for the r300 driver where Maciej
is working on texture tiling will allow us to avoid the untiling
overheads that mapping
I've been playing with strategies to get r300 buffer management a bit
more efficient,
I've reworked the r300g screen/winsys and create a pb_bufmgr compliant
buffer class,
and stacked the cached buffer manager on top of it.
Now I've hit a problem in that we expose buffer busy state, but the
On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt b...@zhasha.com wrote:
On Sun, 2010-02-28 at 20:25 +0100, Jerome Glisse wrote:
Hi,
I am a bit puzzled, how a pipe driver should handle
draw callback failure ? On radeon (pretty sure nouveau
or intel hit the same issue) we can only know when
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
On Wed, 2010-02-03 at 18:16 -0700, Brian Paul wrote:
Dave Airlie wrote:
Module: Mesa
Branch: master
Commit: 3584a44270a7f3a04e187bd79b5373314514d383
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=3584a44270a7f3a04e187bd79b5373314514d383
Author: Dave Airlie airl
.
If these are okay, I can look at softpipe support via translate. Not sure
exposing this extension always and using translate always makes sense as
it defeats the purpose of this extension.
Dave.
From b8ea9848a61fe2469ae87bdc8ba44ea40b25b8ef Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@linux.ie
Date: Tue
Another thing that bother me, is that gallium community is very small
but worse thing is that some of people who are working on gallium are
very hard to approach, even arrogant. This is certainly not way how to
build successful society, for sure. It looks like that they consider
themselves
Hey,
Stuck at home today minding sick (on the mend now baby) with only my 965
laptop, and someone mentioned this morning on irc that we don't do
ARB_half_float_vertex, and after reading that patent stuff doesn't apply
to this by my reckoning it didn't seem that hard to throw together.
I
This makes the r300g + X.org state tracker work a bit better, I can
start X + xterm + metacity and drag a window around now at least.
A full gnome session seems to have other issuess.
Dave.From b8f1d1cf45aa23c74b2d150058506a6a27737d25 Mon Sep 17 00:00:00 2001
From: Dave Airlie airl
So I've changed libdrm_radeon API upsteram, I'd like to fixup Mesa 7.6 +
7.7 branches to request the new API using a similiar patch I just
committed from Fabio.
Reasoning is:
a) libdrm declares the ABI as unstable, so any distro shipping it already
has agreed to burden the hassle. if they ship
Hey all,
So in mesa for swtcl cases we emit vertices to DMA, and set a driver
internal dma.flush hook, we also set
ctx-Driver.NeedFlush |= FLUSH_STORED_VERTICES;
The driver has its FlushVertices pointed at the vbo_exec_FlushVertices
call.
I'm not sure when this ever worked but I
So in mesa for swtcl cases we emit vertices to DMA, and set a driver
internal dma.flush hook, we also set
ctx-Driver.NeedFlush |= FLUSH_STORED_VERTICES;
The driver has its FlushVertices pointed at the vbo_exec_FlushVertices
call.
I'm not sure when this ever worked but I
Am Monday 21 September 2009 19:45:15 schrieb Maciej Cencora:
Hi,
I've got a fix for vbo-map-remap, fdo14575 and fdo22540 sitting in my local
tree, (the code hasn't been aligned after Brian's
92033a9516942d7272ce4bf36ecd422009bbaf60 and 822c7964819ca1fcc270880d4ca8b
patches.
Is this still being tracked down? we should probably revert the hack if
nobody is actually going to look for the proper fix.
I have replaced the intelFlush to a intel_batchbuffer_flush, then benchmark
it with ut2004 demo.
Found almost no regression.
Its not about a regresssion there
In general, adding flush() calls is not the correct way to fix bugs
(and can impact performance). This flush is probably hiding the true
cause of the bug. Unfortunately, I don't know what that would be.
I don't know exactly the reason.
It seems that some rendering is delayed to the next
Funny you should mention whitespace. I've been looking at the radeon
code a bit lately. What a mess. Within a single source file I've
seen 3 different levels of indentation (3/4 space and 8-space tabs).
I'd be happy to see the whole thing run through 'indent'.
I've been holding off,
I've been holding off, its the problem with merging code from 3 drivers
with different white space into one set of common code, you get bits
of the style of all 3 drivers.
Oh and the other problem is indent doesn't understand typedefs properly,
so anywhere you have void func(radeon_t *arg)
So I tried to run cairo-dock and ran into some really dumb insanity in it
which I'm sure isn't GL compliant but I'm not sure how I should tell it to
foad.
So it calls gtk init and this opens a display connection, it then calls
XOpenDisplay in another place, it createa context on the gtk inited
I think we've gone as far as we can with radeon-rewrite, it was starting
to outshine master in a few areas mainly thanks to Maciej (osiris) work,
We've lost support for a couple of things (hyperz/texture tiling)
temporarily but they will return once we can figure out how they work
again :)
.
I've pushed all these and fixed Michel's original vmware email address on
his one.
Dave Airlie is going to merge it soon (IIRC he said something about this
weekend or next week).
Does it perform a lot worse (compared to master branch) even without this
round of patches?
I'll probably do
Does it perform a lot worse (compared to master branch) even without this
round of patches?
I'll probably do some more comparisons on some tcl and some non-tcl hw
this week, and merge it if nothing major stands out.
on my rs690 at least, gears and ipers both get an increase with
OK, with that hint the convolutions became a little bit more clear. The
exact problem is:
drm_buffer_object_create() is called with flags=DRM_BO_FLAG_MEM_TT
(DRM_BO_FLAG_CACHED is not included because this is a AGP system)
bo-mem.flags = BO_FLAG_MEM_LOCAL | ...
I'd like to fix this at some point, but I never got to understand wtf the
blackbars were coming from, apart from it being something to do with
evicted buffers.
Aha!
So, two characteristics of the black bars I remember:
- They were 16-pixel (64-byte) horizontal stripes, 64-byte
valgrind was showing a race between the drawable getting destroyed
by the X resource freeing code, and the context getting destroyed
later and freeing the drawable.
However I've no idea if some other combination of things could cause
this code to leak.
Any one else have any ideas?
---
I'm looking at making the 7.5 release on Friday. The main objective of this
development release will be an initial milestone / roll-out of the Gallium
bits. Then, I'd like to quickly create the Mesa 7.6 branch for
stabilization. git/master will then again be open to any/all
Hey,
Just wondering what should be done, but gen-teximage.c and
gen-texsubimage.c at lesat both do
glutSwapBuffers
glFlush
glReadPixels.
Now glReadPixels defaults to reading from the backbuffer, and in theory
after a swapbuffers the contents of the backbuffer are undefined.
I'm sure the fix
Hey,
So I've been playing with radeon FBOs and have run into a problem with how
to allow apps to get an FBOs that isn't swrast fallback :-)
radeons can by default render to ARGB, ARGB, RGB565 mostly, now in
this case when the app asks for a texture format of GL_RGBA,
textures like spans?
The intel driver de-tiles in the software span accessing functions. Or
is there something I'm missing here? Do textures go through some other
path?
It detiles buffer access via spans, textures don't go via spans from what
I can see, the texstore code seems to
Hi all,
So I had to drop texture tiling when I did the radeon-rewrite but I'd like
to bring them back.
Now with traditional drivers, we have the mesa copy of the texture and the
card copy, and we usually texture from VRAM only, so we can upload to VRAM
and tile on the way, and if we hit a sw
Hi,
f9ce417aaf14c00e72e92307b910de5dbed1bb6d causes regression in some 3d apps on
my rs690 (non tcl hw).
glxgears: vbo/vbo_exec_api.c:751: vbo_exec_BeginVertices: Assertion `exec-
ctx-Driver.NeedFlush == 0' failed.
texfilt: vbo/vbo_exec_api.c:788: vbo_exec_FlushVertices: Assertion
Gallium3D currently builds on Linux userland (gcc), Windows user-space
(MSVC, MinGW, and MinGW cross-compilers) and Windows kernel-space (MSVC
only unfortunately). Mesa3D/Gallium3D scons build system supports all
those combinations, *today*.
Jose it supports building, I think Donnie's point
Compressed textures also seem to be broken, since they'll raise a FPE:
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread -1480239424 (LWP 11180)]
0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48, t=0x9909e80,
target=3553, firstLevel=0,
lastLevel=10,
Hi,
So I have a goal to get a radeon driver that works on a bufmgr and that
then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
work.
So with that in mind and not wanting to write this 3 times, I've done a
major refactoring of the radeon/r200/r300 drivers.
I've refactored
Hi,
So I have a goal to get a radeon driver that works on a bufmgr and that
then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
work.
r200 appears busted, but its wierd busted I'll blame the master merge and
fix it tomorrow.
Dave.
So with that in mind and not
r200 appears busted, but its wierd busted I'll blame the master merge and
fix it tomorrow.
Okay r200 gears is back, I think it was an artifact of not getting a clean
build, along with fixing some warnings.
Dave.
Dave.
So with that in mind and not wanting to write this 3 times,
On Mon, 9 Feb 2009, Kristian Høgsberg wrote:
On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson dbn.li...@gmail.com wrote:
On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul bri...@vmware.com wrote:
In terms of the build system, we'll initially default to the non-gallium
build. To build with gallium
We can do either:
- have some new build targets, like linux-gallium-dri etc, that
build the drivers and put them in mesa/lib/xyz_dri.so
No not the one we'd like.
or
- build both lots of drivers, and put the gallium ones in a new
directory, like mesa/lib/gallium/xyz_dri.so
I'd suspect
the following commit
1724334d7c82abe55b6506dfe369df4facae6f06
dri: fix crash in driGetConfigAttribIndex
Accessing a GLboolean via an int pointer on big-endian == bad.
breaks 3D stuff on my radeon r5xx card: GLX no longer reports visuals with
double buffering. I've
Having some incorrect visuals is better than a flat out
unconditional server crash, isn't it? :-/
It's a major regression between an -rc3 and -rc4 of a Mesa release, that
stops 3D working on a large number of x86 machinse vs a crash on some
non-x86 machines.
Ideally we find the real fix,
the GEM code. I have a feeling it might be easier for you to back-out
the GEM code, make a branch, then re-add GEM on master. Besides, your
git-fu is probably much better than mine.
The branch should be called mesa_7_2_branch. I'll make a 7.1 release
off that quickly, then designate
On Sun, Aug 17, 2008 at 12:23:06 +0200, Stefan Dirsch wrote:
Looks like dri_bufmgr.h/intel_bufmgr.h are missing in the
tarball. Could this be?
See my other reply on mesa3d-dev, they're from libdrm git master.
So I see a couple of ways to resolve this,
1) Back out GEM, release 7.1,
It falls back gracefully though (I think TTM did as well, though this API is
smaller in that it doesn't pass a huge gob of flags around), so if we think
the libdrm bufmgr interface is stable there should be no problem.
The problem is I am not that happy that the bufmgr interface is stable,
Gallium might ultimately wind up in its own repository as a stand-alone
project. Afterall, Gallium drivers could be used by APIs other than OpenGL.
The question is mainly from a distro point of view what do we need to ship
a gallium driver. The current method would mean we need a Mesa
TTM APIs.
I think the X server might also need something similiar around dri2.
Dave.
From b85269252bb38769fcdd58dbcafb2c015f60f7d4 Mon Sep 17 00:00:00 2001
From: Dave Airlie [EMAIL PROTECTED]
Date: Wed, 28 May 2008 15:55:44 +1000
Subject: [PATCH] mesa/drm/ttm: allow build against non-TTM aware
1.) can you please tell me, since Scitech drivers are based on Mesa, why
there is no mention of them on Mesa web site?
Mesa is BSD licensed, anyone can and does take it and use it, the project
may never find out or have any contact with the ppl using it...
2.) can you help me figure out,
Oh yes, and there is some magic to create a branch on the remote, right?
Am I able to do this myself or to I have to ask a grownup?
Nope.. just push the branch, like
git push origin my-new-branch:my-new-branch
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied /
Hi! In which kernel.org release will we find the updated kernel modules?
Will it be necessary to run CVS modules?
Depends on what you want, most features are in-kernel, newer things
like TTM aren't in there yet... normally there is a 2 kernel delay,
one cycle with features in -mm, then one
Sorry for the delay. I have to admit I find compressed textures really
confusing for some reason, and basically do what I can to avoid them...
Have you got an application or Mesa demo which you can point at doing
the wrong thing? It'd be easier to work from something like that.
Well I'm
Now that the merge is done I propose:
1. Finish up the glClear() parameter changes I started a week or two ago.
2. Get people to test the i915tex driver.
I setup a machine at home running my gaming machine app which is a very
heavy texture user, it uses compressed, rectangular and POT
I'm looking for an openGL setup without X11 for an embedded application.
I tried to build mesa-solo (make linux-solo) but get problems with
references to headers files like 'driver.h' and 'pciaccess.h' in file
mesa/drivers/dri/i915/server/intel_dri.c. I guess other drivers will
have similar
I'm in the process of moving DRM CVS to git, can people avoid using CVS from
now on...
When I get the last admin help the repo will be (in a few hours):
git://anongit.freedesktop.org/git/mesa/drm
I've decided to put the drm under the mesa project on fd.o as the dri project
is pretty much
http://cvsweb.xfree86.org/cvsweb/xc/lib/GL/glx/glxext.c.diff?r1=1.2r2=1.3
The commit comment just says:
3377. DRI megapatch. This moves mesa to xc/extras, updates Mesa to
version 3.2, adds full support and fifo code for 3dfx hardware,
and updates the device driver to work with
I want to sync glutSwapBuffers with vblank. I have developed an
application with double buffering that uses glutSwapBuffer to refresh
the screen. The application is getting 132 FPS and I notice some tearing
on the screen. I want to sync swapBuffer with vblank in order to get 75
FPS and
Just a quick question, i am wondering if anyone thought about moving
mesa to git ?
For the DRM I've contemplated it, I've just got a bit backed up with other
things, but I'd like to move it in the next while at some point
I'd personally like to see Mesa in git, I've locally got Mesa in
I'm guessing the corret answer if fix Mesa to use 16 instead of 8, but I'd
like Brian or Keith to verify it,
There's a bit of work to do to mesa before we double the number of texture
units, particularly to swrast, but also tnl/ doesn't support this, afaik.
For now, drivers are limited to 8
Okay I spent some time looking at the r300 span crap that no-one else was
looking at and spending more time putting stupid hacks into the r300
driver...
The problem is Mesa core defines MAX_TEXTURE_UNITS,
MAX_TEXTURE_COORD_UNITS, and MAX_TEXTURE_IMAGE_UNITS to 8, this sizes a
number of
Using CVS HEAD of xc (i.e. 6.9.0 Xorg) including bundled Mesa 6.4.1 I can
reach
1110 FPS in glxgears and 27-30 FPS in ppracer (compared to 860 FPS glxgears
and
11 FPS in ppracer using modular CVS HEAD of X.org and Mesa).
I can confirm this one of the guys here was testing X.org 7.0 vs new
I recently tried to compile the Mesa fbdev/DRI drivers. Since I do not have X
installed, this seemed to be exactly what I needed.
Although the Mesa fbdev/DRI drivers do not require X, it seems that some X
utilities and libs are at least required during the compilation process. I
encountered
efficiently done by using DrawBuffer (GL_FRONT) and CopyPixels.
I've got a first attempt at accelerating copy pixels on r200 using bitblt,
http://www.skynet.ie/~airlied/patches/dri/r200_copy_pixels_bitblt.diff
Same code would be useful in radeon and r300 so I'd like to merge it ..
However
That's odd. The dispatch routines are 16-byte aligned and the inlining
doesn't grow the size of the routine above 16-bytes. Did actual .text size
change, or just the library on-disk size?
My impression is that as caching is all that matters, the overhead of
branching to a cache hot function
New libdrm needed..
Dave.
On Thu, 9 Feb 2006, Johnson, Charles F wrote:
I'm down to trying to build the i915_dri driver and am getting:
gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver
-I../../../../../../drm/shared-core -I../../../../../include
I don't think I have CVS write access. It would be nice if you could fix
that.
You should have it now I think, ajax just added it ..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
89 matches
Mail list logo
