> b) define a new packet for 8 elements, make driver use it everywhere,
> leave old code in DRM for backwards compat... (not sure this is possible,
> as it uses the register address to work things out...)
>
actually this is what I've done for the pixshader vs fragshader
instructions. which overlap
Currently the r200 driver has TFACTOR_0 packet, which takes 6 constants,
however there are actually 8 constant registers used in ATI_fs and the two
extra are just after the the other 6
So what is the best way to approach adding thse two,
a) define a new packet for just 2 elements.. makes cons
On Sun, 30 Jan 2005, Rune Petersen wrote:
Vladimir Dergachev wrote:
Lesson 20 have 3 points that causes lockups (maybe more).
They are all related.
the first is at line 258-259:
glBindTexture(GL_TEXTURE_2D, texture[3]);
glBegin(GL_QUADS);
glBegin() is causing the lockup, but only when te
Not sure if anyone else gets it... I have to take a look & see if I
undertsand why I get it.
Looks like everyone gets it - glxgears has begin/end pair with only two
vertices for a triangle primitive - maybe a bug..
I saw something like this too, when I implemented and debugged the
savage fast path
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2419
Summary: Solo crashes on ia64 on startup
Product: DRI
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2418
Summary: Lockup using linux-core on radeon
Product: DRI
Vladimir Dergachev wrote:
>> Lesson 20 have 3 points that causes lockups (maybe more).
>> They are all related.
>>
>> the first is at line 258-259:
>>glBindTexture(GL_TEXTURE_2D, texture[3]);
>>glBegin(GL_QUADS);
>> glBegin() is causing the lockup, but only when textures 1, 2, or 3.
>>
> initializer element is not constant
> /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:112: error: (near
> initialization for `driver.pci_driver')
> make[2]: *** [/usr/home/adamk/saved/source/drm/linux-core/radeon_drv.o] Error
> 1
> make[1]: *** [_module_/usr/home/adamk/saved/source/drm/l
Am Samstag, den 29.01.2005, 17:25 -0500 schrieb Vladimir Dergachev:
>
> On Sun, 30 Jan 2005, Hamie wrote:
>
> >
> > It's working...
> >
> > Mostly... I get pretty good rates on glxgears... But get a funny error
> > about
> > not enought verticies...
> >
> > [EMAIL PROTECTED]:~$ glxgears
> > r30
On Sun, 30 Jan 2005, Hamie wrote:
It's working...
Mostly... I get pretty good rates on glxgears... But get a funny error about
not enought verticies...
[EMAIL PROTECTED]:~$ glxgears
r300NewProgram, target=34336, id=0
vertex prog
r300NewProgram, target=34820, id=0
fragment prog
r300NewProgram, ta
fallback). As for lesson20 I have no idea - try commenting out drawing code
and checking which part creates a lockup.
Btw, I am getting a partial lockup with lesson20 even without
r300_dri.so (when it is absent the driver falls back to software
rendering), so it might be due to mode switchi
On Sat, 29 Jan 2005 16:58:37 -0500, Alex Deucher <[EMAIL PROTECTED]> wrote:
> On Sat, 29 Jan 2005 09:30:33 -0500, Adam K Kirchhoff <[EMAIL PROTECTED]>
> wrote:
> >
> > This morning the radeon DRM won't build for me:
> >
> > CC [M] /usr/home/adamk/saved/source/drm/linux-core/ati_pcigart.o
> >
On Sat, 29 Jan 2005 09:30:33 -0500, Adam K Kirchhoff <[EMAIL PROTECTED]> wrote:
>
> This morning the radeon DRM won't build for me:
>
> CC [M] /usr/home/adamk/saved/source/drm/linux-core/ati_pcigart.o
> CC [M] /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.o
> /usr/home/adamk/saved/
It's working...
Mostly... I get pretty good rates on glxgears... But get a funny error
about not enought verticies...
[EMAIL PROTECTED]:~$ glxgears
r300NewProgram, target=34336, id=0
vertex prog
r300NewProgram, target=34820, id=0
fragment prog
r300NewProgram, target=35104, id=0
ati fragment prog
On Fri, 2005-01-28 at 12:50 +0100, Amir Bukhari wrote:
> >Indeed, it's our driver that disables the DRI if Composite is enabled,
> > not the DRI in general. I expect that to stay the same until the two are
> > properly integrated with each other (but it's not my decision to make).
> >
> If some c
Vladimir Dergachev wrote:
Hi,
I get lockups running anything other than glxgears.
I am running the 25 jan. snapshots of Xorg & r300_driver.
Are there any simple way to locate the functions that course lockups?
I was thinking of something like simple programs or tutorials.
Try NeHe tutorial - nehe
Jacek Rosik wrote:
Hi
Dnia 29-01-2005, sob o godzinie 02:29 +0100, Stephane Marchesin
napisał(a):
Roland Scheidegger wrote:
I don't quite follow third line before last? Can someone enlighten me?
You mean the pitch & 0x20 stuff? Yeah, looks strange.
Looking at it, it seems like it ensures that each
On Fri, 28 Jan 2005, Rune Petersen wrote:
Vladimir Dergachev wrote:
On Thu, 27 Jan 2005, Rune Petersen wrote:
Hi,
I get lockups running anything other than glxgears.
I am running the 25 jan. snapshots of Xorg & r300_driver.
Are there any simple way to locate the functions that course lockups?
I w
Adam Jackson wrote:
On Saturday 29 January 2005 17:21, Hamie wrote:
This mornings cvs snapshot of Mesa using linux-dri config fails to
build. A missing drm.h file... It builds fine using linux-x86, but I
want it for the r300 stuff, so assuming I acytually need the linux-dri
build...
is there a d
On Saturday 29 January 2005 17:21, Hamie wrote:
> This mornings cvs snapshot of Mesa using linux-dri config fails to
> build. A missing drm.h file... It builds fine using linux-x86, but I
> want it for the r300 stuff, so assuming I acytually need the linux-dri
> build...
>
> is there a date tag I c
This mornings cvs snapshot of Mesa using linux-dri config fails to
build. A missing drm.h file... It builds fine using linux-x86, but I
want it for the r300 stuff, so assuming I acytually need the linux-dri
build...
is there a date tag I can use that will build?
TIA
Hamish Marson
--
On Sat, 2005-01-29 at 11:57 +0100, Martin Bouzek wrote:
> Hello,
>
> I am complete newbie to this mailing list and to programming of modern
> graphic HW, but have the following problem: I want to grab complete X
> window screen (eg. root window) reasonably fast. When I use standard way
> by XGetIm
This morning the radeon DRM won't build for me:
CC [M] /usr/home/adamk/saved/source/drm/linux-core/ati_pcigart.o
CC [M] /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.o
/usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:80: error:
`radeon_postinit' undeclared here (not in a funct
> are *completely* different from those on the R300. Now maybe the R200 has
> both a dedicated fixed function pipeline *and* a programmable processor,
> but unless that is the case, I assume fglrx on R200 tries to map ARB_vp
> onto fixed function when it can, and falls back to software otherwise.
On Saturday 29 January 2005 02:47, Dave Airlie wrote:
>
> I've noticed fglrx advertises this for the r200, and doom 3 wants it...
>
> So after I manage to beat fragment_shader into shape, going to have a look
> at how to get ARB_vp working.. r300 guys you have something going on this
> already?
Hello,
I am complete newbie to this mailing list and to programming of modern
graphic HW, but have the following problem: I want to grab complete X
window screen (eg. root window) reasonably fast. When I use standard way
by XGetImage, I am able to grab about 1.5 screen (1280x1024x32) per
second ha
Hi,
Dnia 29-01-2005, sob o godzinie 11:19 +0100, Roland Scheidegger
napisał(a):
> Jacek Rosik wrote:
> >
> > BTW: I have working solution for color but I wonder if this will work
> > with color tiling. Of course offset Would have to be aligned to the
> > closest tile. Can You take a look at it?
Jacek Rosik wrote:
Yes, I meant depthPitch. They are the same but only for resolutions
where width is multiple of 32.
That's always the case (mode validation pitchInc was
64*pScrn->bitsPerPixel without color tiling), so you don't really need
to round up to 32 for depth pitch.
Depth pitch is rounde
On Sat, Jan 29, 2005 at 01:47:22AM +, Dave Airlie wrote:
>
> I've noticed fglrx advertises this for the r200, and doom 3 wants it...
>
> So after I manage to beat fragment_shader into shape, going to have a look
> at how to get ARB_vp working.. r300 guys you have something going on this
> alr
Hi,
Dnia 28-01-2005, pią o godzinie 16:27 +0100, Roland Scheidegger
napisał(a):
> Jacek Rosik wrote:
> > Hi,
> >
> > I have some questions about r200 depth tiling. Generally I'm also
> > interested in r100 tiling too, but currently i work on r200.
> >
> > First of all in functions r200_mba_z16
Hi
Dnia 29-01-2005, sob o godzinie 02:29 +0100, Stephane Marchesin
napisał(a):
> Roland Scheidegger wrote:
>
> >>
> >> I don't quite follow third line before last? Can someone enlighten me?
> >
> > You mean the pitch & 0x20 stuff? Yeah, looks strange.
> > Looking at it, it seems like it ensures t
31 matches
Mail list logo
