On Sun, Apr 24, 2011 at 10:08 AM, Marek Olšák wrote:
>
> On Sun, Apr 24, 2011 at 1:15 AM, Dave Airlie wrote:
>>
>> Hi Brian,
>>
>> st/mesa: check image size before copy_image_data_to_texture()
>>
>> This causes a regression with NPOT textures in fbo-ge
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 Wed, Apr 14, 2010 at 8:33 AM, Roland Scheidegger wrote:
> On 13.04.2010 20:28, Alex Deucher wrote:
>> On Tue, Apr 13, 2010 at 2:21 PM, Corbin Simpson
>> wrote:
>>> On Tue, Apr 13, 2010 at 6:42 AM, Roland Scheidegger
>>> wrote:
>>>> On 13.04.2010
On Tue, Apr 13, 2010 at 11:42 PM, Roland Scheidegger wrote:
> On 13.04.2010 02:52, Dave Airlie wrote:
>> On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul wrote:
>>> Dave Airlie wrote:
>>>> Just going down the r300g piglit failures and noticed fbo-drawbuffers
>>
>
> (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 maski
On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul 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
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 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 texenv
On Mon, Apr 5, 2010 at 6:06 PM, Chia-I Wu wrote:
> On Mon, Apr 5, 2010 at 3:38 PM, Dave Airlie wrote:
>> On Mon, Apr 5, 2010 at 5:24 PM, Chia-I Wu wrote:
>>> On Mon, Apr 5, 2010 at 1:41 PM, Dave Airlie wrote:
>>>> On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu wrote
On Mon, Apr 5, 2010 at 5:24 PM, Chia-I Wu wrote:
> On Mon, Apr 5, 2010 at 1:41 PM, Dave Airlie wrote:
>> On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu wrote:
>>> On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie wrote:
>>>>> The attached patch fixes tfp test for m
On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu wrote:
> On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie wrote:
>>> The attached patch fixes tfp test for me (with i915g). Could you see if
>>> r300g
>>> passes the test with the patch?
>>> The teximage callbac
On Mon, Apr 5, 2010 at 12:49 PM, Chia-I Wu wrote:
> On Sun, Apr 4, 2010 at 6:31 PM, Dave Airlie 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_s
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 main/framebu
>
> 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: B
On Sun, Apr 4, 2010 at 8:31 PM, Dave Airlie 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.
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 s
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 st_manager_add_co
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 tes
On Tue, Mar 30, 2010 at 6:26 PM, Nicolai Haehnle wrote:
> Reply to all this time...
>
> On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák wrote:
>>> > 1) Branching and looping
>>> >
>>> > This is the most important one and there are 3 things which need to be
>>> > done.
>>> > * Unrolling loops and con
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
Descr
On Tue, Mar 23, 2010 at 11:41 PM, Luca Barbieri 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 would
> do that with
On Mon, Mar 8, 2010 at 5:51 PM, Jose Fonseca 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 PIPE_BUFFER_USAGE_DONT_BLOCK? If
On Sat, Mar 20, 2010 at 4:18 AM, Sedat Dilek 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
Something in the recent statetracker and/or dri work
Here is some gdb,
I noticed this comment also:
/* DRI co-state tracker currently overrides flush_frontbuffer.
* When this is fixed, will need to pass the drawable in the
* fourth parameter here so that when Mesa calls
On Wed, Mar 10, 2010 at 6:47 AM, Keith Whitwell wrote:
> On Tue, 2010-03-09 at 12:43 -0800, Dave Airlie wrote:
>> On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell wrote:
>> > On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote:
>> >> On Tue, Mar 9, 2010 at
On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell wrote:
> On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote:
>> On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell wrote:
>> > This leaves r300g as the only remaining user of
>> > pipe_winsys/u_simple_screen - which means we can rename that code
>>
On Tue, Mar 9, 2010 at 11:30 AM, Luca Barbieri 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 that while fenced
On Sun, Mar 7, 2010 at 9:44 PM, Luca Barbieri 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 same way (making the
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
cached
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 textures
On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt 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 one
>>
>
> 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 revivi
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=3584a44270a7f3a04e187bd79b5373314514
e 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
Date: Tue, 26 Jan 20
>
> 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
> thems
>
> 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.
>
>
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 found
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
Date: Thu, 7
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
> > > 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
>
> 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 worke
> >
> > This patch series focuses on core mesa. The biggest thing missing is a
> > convension for drivers to enable extensions. I think some refactorings
> > are needed before a convension can be established.
>
> I'm actually not too enthusiastic about these patches.
>
> When we omit a feature
> 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
> On Sun, Sep 20, 2009 at 9:00 PM, Chia-I Wu wrote:
> > The attached patches fix missing symbols in meta/st and a compilation
> > error in intel dri driver.
>
> Committed. Thanks. Sorry for the screw-ups.
>
I think gallium is still broken, just doing a rebuild now,
undefined symbol: _swrast_
> >>
> >>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 regr
> >>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 delay
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 assume it did
>
> 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 *a
>
> 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 of
> > 3d drivers without rebuilding the xserver.
> Old libGL.so won't load the DRI drivers compiled with this commit. This
> is known, but I must admit that I forgot xserver counts as an old
> libGL.so...
>
> I just had a quick look at it, and I think this can be fixed by defining
> _glapi_SingleT
> >
> > 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
> > connection, then creates another context on the XOpenDisplay connection
> > passing the gtk context as a share.
> >
> > Now we don't end up
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
54f425b5cefd1e40f315a4f8747b9a3db29ab9d4
or something around then broke the enums.c
it looks like someone hand edited the file with the don't hand edit this
file on top :-)
Brian?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI
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 :)
Ho
> >
> > 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 increa
gned-off-by with my name, but you're still the patch author.
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 lo
> >
> > 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 str
>
> 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 | ...
> bo->mem.
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?
---
src/mesa/
>
> 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 develo
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,
GL_UNSIGNED_BYTE,
> > 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 t
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: As
>
> 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 p
> > 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,
> > lastL
>
> 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
> 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 n
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
> 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
On Mon, 9 Feb 2009, Kristian Høgsberg wrote:
> On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson wrote:
> > On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul wrote:
> >>
> >> In terms of the build system, we'll initially default to the non-gallium
> >> build. To build with gallium I'll add some new config
>
> 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 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'v
> 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 des
> 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
> 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
>
> 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 t
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
On Thu, 26 Jul 2007, Chase Douglas wrote:
> I see that I need libdrm 2.3.1 for i915tex, but I can't find any way to
> get libdrm 2.3.0. The latest in git is 2.3.0, and though I can find
> RPMS, I have no clue how to get it. Does anyone know where I can get it?
Git should be sufficent and I thoug
> 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 ou
> 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 / airli
> 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 cyc
>
> 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
>
> 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
> just move that to
>
> git://git.freedesktop.org/git/mesa.git
You need to move it to mesa/mesa.git as we have a meas dir already..
You probably need to regenerate the tree from scratch or have you got a
fully up-to-date authors list?
Dave.
--
David Airlie, Software Engineer
http://www.skyn
>
> 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 sim
>
> http://cvsweb.xfree86.org/cvsweb/xc/lib/GL/glx/glxext.c.diff?r1=1.2&r2=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
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 reti
>
> 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
> I still haven't used git yet myself, but it sounds pretty good.
>
> I'd be willing to look into it, perhaps after the next Mesa release. OK?
Fine by me, If you wand the virtues of git extoled, talk to keithp :-)
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlie
> 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 think Dave Airlie created a more appropriate patch for accelerating
CopyPixels.
My patch is at
http://www.skynet.ie/~airlied/patches/dri/r200_copy_pixels_bitblt.diff
However it was falling back too often for my liking so I think it is
correct, just a bit too cautious... I haven't
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 arra
On Tue, 2006-05-02 at 14:23 +0200, Lukas Hejtmanek wrote:
On Tue, May 02, 2006 at 11:51:05AM +0100, Alan Hourihane wrote:
The problem here is batchbuffers.
Due to rotation being able to shuffle memory around it wasn't possible to
support batchbuffers in agp space as the 2D driver could rip up
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
In the case of X.org, OTOH, you are *only* talking about the software
rasterizer for Indirect GLX. I don't think it's unreasonable to say that the
policy could change to make that track the Mesa stable branch or even just to
track Mesa releases.
Actually with all this talk of new extensions
The GLX proto headers are all that is required from Xorg, otherwise we end
up with two copies that can get out of sync with each other.. the GL proto
module is very small
I'm no expert on these things, but doesn't one of the header locations define
the library capabilities and the oth
It seems to me that whatever reason Xorg needs to build mesa for (I'm
guessing the indirect GLX software rasterizer) is a mistake.
If mesa is to be built, it should be built within the tree it is developed.
That might mean that Mesa should learn how to build itself in a form suitable
for use
1 - 100 of 112 matches
Mail list logo