From: Leif D. <lde...@re...> - 2002-04-20 20:21:38
|
Jose, I added the remaining bits to copy the agp texture region info to the drm. It's not used, but the information is there in case we need it later. I hope you don't mind, but I took the liberty of converting your drm emit_state functions to use the DMA* macros, which ensures that enough fifo entries are present before doing the state reg. writes, so we avoid potential lockups. BTW, I haven't noticed any texture problems, even after disabling the UploadHWStateLocked in mach64_ioctl.c:FlushVerticesLocked (this is redundant if the kernel is emitting state). Were you seeing the problem with UploadHWStateLocked enabled? I tried UT with UploadHWStateLocked enabled and without the DMA* macros, and with UploadHWStateLocked disabled and _with_ the DMA* macros. Both of those combinations worked fine. I haven't tried with UploadHWStateLocked disabled and without the DMA* macros yet, though. -- Leif Delgass http://www.retinalburn.net |
From: José F. <j_r...@ya...> - 2002-04-20 21:19:17
|
On 2002.04.20 21:21 Leif Delgass wrote: > Jose, > > I added the remaining bits to copy the agp texture region info to the > drm. > It's not used, but the information is there in case we need it later. > > I hope you don't mind, but I took the liberty of converting your drm > emit_state functions to use the DMA* macros, which ensures that enough > fifo entries are present before doing the state reg. writes, so we avoid I don't mind at all. In fact I also did the same here, and I was about to check when I received your email, and things started to work again! *ufh* > potential lockups. BTW, I haven't noticed any texture problems, even > after disabling the UploadHWStateLocked in > mach64_ioctl.c:FlushVerticesLocked > (this is redundant if the kernel is emitting state). Were you seeing the > > problem with UploadHWStateLocked enabled? I tried UT with > UploadHWStateLocked enabled and without the DMA* macros, and with > UploadHWStateLocked disabled and _with_ the DMA* macros. Both of those > combinations worked fine. I haven't tried with UploadHWStateLocked > disabled and without the DMA* macros yet, though. > Yep. that seems to be the problem... > -- > Leif Delgass > http://www.retinalburn.net > Now I'll merge your changes with some code cleanups I did here. The question is what do next? These are some things that we could do: - check the FIFO when PseudoDMAing (as in Utah) - Texture Uploads through the DRM (blits) - DMA buffer aging (even though we don't have DMA we gonna need this I suppose ) - AGP texturing (this can be done without DMA, can't it?) - optimize the DMA buffer construction in the primitive drawings I think there are more. What do you think we (each one) should focus next? José Fonseca |
From: Leif D. <lde...@re...> - 2002-04-20 21:41:14
|
On Sat, 20 Apr 2002, Jos=E9 Fonseca wrote: > On 2002.04.20 21:21 Leif Delgass wrote: > > Jose, > >=20 > > I added the remaining bits to copy the agp texture region info to the > > drm. > > It's not used, but the information is there in case we need it later. > >=20 > > I hope you don't mind, but I took the liberty of converting your drm > > emit_state functions to use the DMA* macros, which ensures that enoug= h > > fifo entries are present before doing the state reg. writes, so we av= oid >=20 > I don't mind at all. In fact I also did the same here, and I was about = to=20 > check when I received your email, and things started to work again! *uf= h* >=20 > > potential lockups. BTW, I haven't noticed any texture problems, even > > after disabling the UploadHWStateLocked in > > mach64_ioctl.c:FlushVerticesLocked > > (this is redundant if the kernel is emitting state). Were you seeing= the > >=20 > > problem with UploadHWStateLocked enabled? I tried UT with > > UploadHWStateLocked enabled and without the DMA* macros, and with > > UploadHWStateLocked disabled and _with_ the DMA* macros. Both of tho= se > > combinations worked fine. I haven't tried with UploadHWStateLocked > > disabled and without the DMA* macros yet, though. > >=20 >=20 > Yep. that seems to be the problem... >=20 > > -- > > Leif Delgass > > http://www.retinalburn.net > >=20 >=20 > Now I'll merge your changes with some code cleanups I did here. >=20 > The question is what do next? These are some things that we could do: > - check the FIFO when PseudoDMAing (as in Utah) > - Texture Uploads through the DRM (blits) > - DMA buffer aging (even though we don't have DMA we gonna need this = I=20 > suppose ) > - AGP texturing (this can be done without DMA, can't it?) > - optimize the DMA buffer construction in the primitive drawings >=20 > I think there are more. What do you think we (each one) should focus ne= xt? >=20 > Jos=E9 Fonseca >=20 Well, I think it would be good to combine the first and last option. A=20 few small changes will enable checking the FIFO (which I see as a high=20 priority), and handling sequential register writes in a flush function fo= r=20 pseudo-DMA. For sequential writes, we need to detect where these occur i= n=20 a buffer and then increment the register address with each write, like th= e=20 utah-glx pseudo-DMA flush. I think we need this in place before we start= =20 to work on new ioctls. These changes will allow streamlining the vertex=20 buffers. Then I think we should think about how to handle the descriptor= =20 tables. I'd like to stablilize the structures, so we have everthing we'l= l=20 need there. I'm not too familiar with how the buffer aging works, I'll=20 have to look at that. I think we could put off texture blits for a while= . =20 I was thinking that it might be easiest to start off the DMA testing on=20 swaps, clears and state, and then move on to the vertex buffers, etc. I can continue looking at the AGP texturing, and I think you're right tha= t=20 almost everthing is in place for that already now. I believe we can do=20 this without blits, by just copying textures into the AGP region. What are your thoughts? --=20 Leif Delgass=20 http://www.retinalburn.net |
From: José F. <j_r...@ya...> - 2002-04-20 22:00:44
|
On 2002.04.20 22:41 Leif Delgass wrote: > On Sat, 20 Apr 2002, José Fonseca wrote: > > ... > > The question is what do next? These are some things that we could do: > > - check the FIFO when PseudoDMAing (as in Utah) > > - Texture Uploads through the DRM (blits) > > - DMA buffer aging (even though we don't have DMA we gonna need this > I > > suppose ) > > - AGP texturing (this can be done without DMA, can't it?) > > - optimize the DMA buffer construction in the primitive drawings > > > > I think there are more. What do you think we (each one) should focus > next? > > > > José Fonseca > > > > Well, I think it would be good to combine the first and last option. A > few small changes will enable checking the FIFO (which I see as a high > priority), and handling sequential register writes in a flush function I agree with the FIFO thing. > for > pseudo-DMA. For sequential writes, we need to detect where these occur > in > a buffer and then increment the register address with each write, like > the > utah-glx pseudo-DMA flush. I think we need this in place before we start I thought that my code already handled this, but I saw a bug from your description. (I'm going to commit a fix for it now). > > to work on new ioctls. These changes will allow streamlining the vertex > buffers. Then I think we should think about how to handle the descriptor > > tables. I'd like to stablilize the structures, so we have everthing > we'll I agree in that we should stabilize eveything to smooth the DMA integration. > need there. I'm not too familiar with how the buffer aging works, I'll > have to look at that. I think we could put off texture blits for a > while. > I was thinking that it might be easiest to start off the DMA testing on > swaps, clears and state, and then move on to the vertex buffers, etc. > > I can continue looking at the AGP texturing, and I think you're right > that > almost everthing is in place for that already now. I believe we can do > this without blits, by just copying textures into the AGP region. > > What are your thoughts? We pretty much agree. We must prepare the DMA work the best we can. Now is just a matter of not doing duplicate work. A good thing is that we have very different timezones, but nevertheless we should pick different subject. So, Leif, pick what're keen on and I'll pick other thing. > > -- > Leif Delgass > http://www.retinalburn.net > José Fonseca |